Base64 explained: 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.

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.

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.