Encode and decode Base64 text or files — fully in your browser.
Turns an image, font, or small file into a Base64 data URI you can embed directly in CSS or HTML.
Base64 is a way to represent any data — text, an image, a font — using only 64 plain characters (A–Z, a–z, 0–9, and two symbols). It exists because some channels, like email bodies, URLs, and JSON, are built for text and can mangle raw binary data. Base64 converts that binary into safe, printable text that survives the trip.
It is important to be clear: Base64 is not encryption and offers no privacy. Anyone can decode it back to the original in one step — this very tool does it. It only changes the shape of data, never its secrecy. If you need to protect something, you need real encryption, not Base64.
Base64 also costs size: the encoded form is about a third larger than the original, because it packs three bytes into four characters. That is fine for a small icon embedded in CSS, but embedding a large image as a data URI bloats your page — link to the file instead.
A tiny icon or font can be embedded directly as a Base64 data URI, saving an extra network request — the file encoder above builds one for you.
Email was designed for text, so every attachment you send is Base64-encoded behind the scenes to travel safely through mail servers.
Parts of tokens like JWTs are Base64url-encoded — decode the URL-safe variant here to read (never trust) their contents.
No. Base64 is a reversible encoding, not encryption — decoding needs no key and takes a millisecond, and this page proves it. If you need to protect data, use real encryption (AES, TLS) first, and only then Base64-encode the encrypted bytes if a text-safe form is needed.
Base64 maps every 3 bytes of input to 4 output characters, because each of its 64 symbols carries only 6 bits while a byte holds 8. The 4:3 ratio means one-third growth, plus up to two = padding characters at the end. There is no way around it — the overhead is the price of staying text-safe.
Standard Base64 uses + and /, which collide with URL syntax: + means a space in query strings and / separates paths. Base64URL replaces them with - and _ and usually drops the = padding. JWT tokens, OAuth state values, and many web APIs expect this variant — enable the toggle whenever your string will travel inside a link.
The string you pasted is valid Base64, but the bytes inside are not text — most likely an image, a PDF, or another binary format. Showing those bytes as text would produce garbled characters, so the tool reports it honestly instead. ZATCA e-invoice QR payloads, for example, often decode to binary TLV data rather than plain text.
No. Encoding, decoding, and the file-to-data-URI conversion all run in JavaScript inside your browser tab. Nothing is transmitted, logged, or stored — you can verify this by loading the page and then going offline; every feature keeps working, so confidential text and internal files are safe here.
They are padding. Base64 works in blocks of 4 characters, and when the original data is not a multiple of 3 bytes, one or two = characters fill the final block. Some systems omit them entirely — this decoder re-pads automatically, so strings with or without = decode equally well.
Dynamic QR codes let you change the destination anytime — no reprinting — and show you every scan: when, where, and on which device. Try the full QRA studio free for 14 days.