Base64 Encode & Decode

The problem Base64 was invented to solve

Base64 exists for one narrow reason: some channels only carry text, and you need to push binary through them anyway. Email bodies, JSON payloads, XML documents, HTML attributes and URLs all expect printable characters. The raw bytes inside a PNG or a ZIP archive include control codes, null bytes and values above 127 that those channels will strip, reinterpret or reject outright.

Base64 rewrites arbitrary bytes using a 64 character alphabet that survives almost anything: A to Z, a to z, 0 to 9, plus and slash. Nothing in that set means anything special to a mail server or a JSON parser, so the data arrives on the other end exactly as it left.

Why the output is about a third longer

The encoder reads your data three bytes at a time. Three bytes is 24 bits, which divides evenly into four groups of 6 bits, and each 6 bit group (a value from 0 to 63) becomes one output character. Four characters out for every three bytes in, so an encoded string runs to roughly 133 per cent of the original size.

When the input length is not a multiple of three, the last group is short. The encoder pads the missing bits with zeros and then appends one or two = characters so the decoder knows how many real bytes to recover. One = means the final group held two bytes; two = means it held one. That is why a 1 MB image becomes roughly a 1.37 MB data URI, and why inlining large images in CSS often costs more than it saves.

A worked example you can check

Type Hi into the plain text box and encode it. You get SGk=. Here is the arithmetic. H is code point 72, or 01001000. i is 105, or 01101001. Together that is 16 bits. Regrouped into sixes: 010010, 000110, then 1001 with two zero bits added to fill it out, giving 100100. Those three values are 18, 6 and 36. In the Base64 alphabet, 18 is S, 6 is G and 36 is k. One group was incomplete, so a single = closes the string.

Try café next and you get Y2Fmw6k=. Eight characters for a four letter word, because the accented é is not one byte. The text panel runs your input through UTF-8 first, and é encodes as the two bytes C3 A9. Five bytes in, eight characters out.

Encoding is not encryption

This is the single most common misunderstanding about Base64, and it matters. There is no key, no secret and no protection. Anybody who sees SGk= can decode it in a second, in this tool or in a one line command. Base64 obscures data from casual glance and nothing more.

If you need to verify that a file has not been altered, you want a checksum instead: the Hash Generator produces MD5, SHA-1 and SHA-256 digests. If you want to hide a puzzle answer for an escape room rather than protect real data, the classical ciphers in the Cipher Decoder are more fun and just as unserious.

Working with files and data URIs

The File tab reads whatever you drop on it through the browser's own FileReader and hands back the Base64 payload. Tick "Output as data URI" and the MIME type is prefixed for you, producing something like data:image/png;base64,iVBORw0KG.... That string can go straight into an img src, a CSS background-image, or an @font-face rule with no separate network request. Images also render in the preview panel so you can confirm you grabbed the right file.

Going the other way, paste a Base64 string or a full data URI into the decode box, set a filename, and the tool rebuilds the bytes and triggers a download. If the input was a data URI, the MIME type is read from the prefix and applied to the downloaded blob. Whitespace and line breaks in the pasted string are ignored, which is useful because mail systems often wrap Base64 at 76 characters.

URL-safe Base64

The standard alphabet includes + and /, and both already mean something in a URL path or query string. A widely used variant swaps them for - and _, and often drops the = padding as well. This tool produces the standard alphabet. If a system asks for the URL-safe form, do those two substitutions on the copied string yourself; the underlying bytes are identical.

Questions people actually ask

Why does my decoded text come out as strange symbols?

Almost always because the original bytes were not UTF-8 text. The text panel decodes bytes as UTF-8, so a Base64 string that actually holds a JPEG or a Windows-1252 document will produce replacement characters and noise. If the source was a file, use the File tab and download it instead.

Why does the decoder reject my string?

Base64 strings only contain the 64 alphabet characters plus =. A stray quote mark, a curly apostrophe pasted from a word processor, or a truncated string with a length that is not a multiple of four will all fail. Check the start and end of what you pasted before assuming the data is corrupt.

Is there a size limit on files?

Only your device's memory. The whole file is held in the tab while it encodes, so multi-hundred-megabyte files can make the browser struggle. A data URI that large is not practical to use anyway.

Does anything get uploaded?

No. Everything runs in your browser, so your files never leave your device. You can disconnect from the network and the page will keep encoding and decoding.