What is Base64? What it's for, and what it is not

Base64 represents arbitrary binary data using 64 printable characters. It exists because a great deal of infrastructure was built assuming text, and binary data pushed through it gets corrupted. It provides no secrecy of any kind.

How Base64 works, in one example

Base64 takes the input three bytes at a time. Those 24 bits are split into four groups of six, and each group of six bits (a number from 0 to 63) is written as one character from a fixed alphabet: A–Z, a–z, 0–9, then + and /. The word Man is three bytes, and it encodes to TWFu.

When the input doesn't divide evenly into threes, the last group is padded with zero bits and the output ends in one or two = signs to keep its length a multiple of four. So Ma becomes TWE= and M becomes TQ==. The equals signs carry no data, which is why a Base64 string so often ends in them and why some variants leave them out.

It is not encryption, and treating it as such is a real bug

Base64 requires no key, so anyone can reverse it instantly. A password, API key or personal detail that is merely Base64 encoded is, for every practical purpose, stored in plain text. This turns up in production code often enough to be worth stating plainly.

It is not compression either. Base64 represents three bytes using four characters, so encoded data is roughly 33% larger than the original, before any padding.

The URL-safe variant

Standard Base64 uses + and /, both of which mean something else in a URL, plus = padding that is awkward in a query string. The URL-safe variant substitutes - and _ and usually drops the padding entirely.

JSON Web Tokens use this variant, which is why a JWT never contains a plus or a slash. Decoding URL-safe data with a standard decoder produces garbage or an error, and it is a common cause of a token that 'looks fine' but will not parse.

Decoding Base64, and why the result is sometimes gibberish

Decoding reverses the process exactly: every four characters become three bytes again. If those bytes were text to begin with, you get the text back. If they were an image, a PDF or a zip file, you get raw binary, and a text box shows it as a jumble of symbols. That isn't a failed decode. The data just isn't text.

When a decoder refuses the input outright, the usual causes are few and quick to check.

• It's URL-safe Base64 (it contains - or _), being read by a standard decoder. Switch alphabets.
• Characters were lost or added in transit. The length should be a multiple of four once padding is restored, and line breaks or spaces pasted in from an email need removing.
• It isn't Base64 at all. Hex strings, hashes and encrypted blobs can look similar, but they don't decode into anything meaningful.
• Accented letters or emoji come out mangled, because the text was decoded as Latin-1 rather than UTF-8. Base64 carries bytes, not characters, so both sides have to agree on the text encoding.

Converting an image to Base64

To put an image inside HTML, CSS or JSON, you encode the file's bytes and prefix them with its type: data:image/png;base64, followed by the string. That complete data URI works anywhere a URL does, in an <img> tag's src or in CSS url(), so the image arrives with the document instead of in a separate request.

Email templates and single-file exports are where this is most useful, since external images there are often blocked or unavailable. On an ordinary web page it's usually the wrong choice, for the reasons in the next section.

When a data URI is worth it

Embedding an image as a data: URI removes a network request, which can be worth it for a tiny icon that appears on every page. Beyond that it is usually a loss.

The data is a third larger, it cannot be cached separately from the document that contains it, and it inflates the HTML or CSS that must arrive before anything renders. A small file fetched in parallel usually beats a large document that blocks.