What Base64 is for
Base64 exists to move binary data through channels that were built for text. Email, JSON, XML, HTML attributes, environment variables and HTTP headers all expect printable characters, and many of them break on raw bytes such as null, line feeds or values above 127. Base64 rewrites any sequence of bytes using only 64 safe symbols: A–Z, a–z, 0–9, + and /, with = as padding.
Typical places you meet it:
- HTTP Basic authentication, where
user:passwordis sent asdXNlcjpwYXNzd29yZA==. - JSON Web Tokens, whose three dot-separated parts are URL-safe Base64.
- Email attachments, which travel as Base64 inside MIME messages.
- Data URIs that embed a small icon or font straight into HTML or CSS.
- API payloads and config files that need to carry a certificate, key or small binary blob as a string.
Base64 is an encoding, not encryption. Anyone can decode it in a second, so a Base64 string in a config file protects nothing. If you need to check that data was not altered, use a hash instead.
How the encoding works
The encoder takes the input three bytes at a time, which is 24 bits, and splits them into four groups of 6 bits. Each 6-bit value from 0 to 63 picks one character from the alphabet. Three bytes in, four characters out, which is why Base64 output is always about 33% larger than the input: a 30 KB image becomes roughly 40 KB of text.
When the input length is not a multiple of three, the last group is short. The encoder fills it and marks the gap with one or two = signs. That is why Man encodes to TWFu, Ma to TWE= and M to TQ==.
Text has to become bytes before it can be encoded, and this tool always uses UTF-8 for that step. The word café is five bytes in UTF-8 (the é takes two), and an emoji takes four. Decoding interprets the bytes as UTF-8 again, so text in any script round-trips unchanged.
The URL-safe variant
Two characters of the standard alphabet cause trouble outside plain text. In a URL, + can be read as a space and / as a path separator; in a file name, / is not allowed at all. The URL-safe alphabet defined in RFC 4648 swaps them for - and _.
With the URL-safe box ticked, the tool makes that swap and also removes the trailing = padding, which is how JWTs and most web APIs expect it. The decoder accepts both forms: it converts - and _ back and restores missing padding automatically, so you can paste a JWT segment directly and read its JSON. If that JSON comes out as one long line, the JSON formatter will make it readable.
Encoding files as data URIs
Encode a file… reads the file in your browser and produces a complete data URI such as data:image/png;base64,iVBORw0KGgo…. The MIME type comes from what the browser reports for the file; when it cannot tell, the generic application/octet-stream is used. You can paste the result into an <img src>, a CSS background-image: url(...) or an @font-face rule.
Data URIs make sense for small assets: an SVG icon, a 1–2 KB placeholder image, a logo in an HTML email signature. For anything larger they work against you. The text is a third bigger than the original file, it cannot be cached separately from the page that contains it, and it bloats the HTML or CSS that has to load before anything renders. A practical ceiling is a few kilobytes per asset.
The whole file is read into memory and converted in one go, so very large files can make the tab slow or run out of memory. The file is not uploaded anywhere.
When decoding fails
The decoder shows "Not valid Base64" when the input contains characters outside the alphabet or has an impossible length. Common causes:
- A data URI prefix. Remove everything up to and including the comma in
data:image/png;base64,before decoding. - Line breaks inside the string. MIME encoders wrap Base64 at 76 characters. If decoding fails on wrapped text, join it into a single line first.
- Copy errors. A missing last character or a stray quote from a JSON string is enough to break it.
The decoder always turns the result into text. If the original data was a binary file such as an image or a ZIP archive, the output will look like random symbols and question marks; that is expected, because those bytes were never text.