Base64 shows up in JWTs, data: URIs, basic auth headers, and half the email attachments in the world. Yet it's one of the most misunderstood techniques out there: plenty of people think Base64 is a form of encryption. It isn't.
What it actually does
Base64 turns binary data into printable text, using 64 safe characters (A-Z, a-z, 0-9, +, /). It doesn't compress or hide anything — it's a reversible encoding by design, reversible enough that you could decode it by hand if you memorized the table. Its only job is making sure arbitrary bytes survive intact through channels built for text (JSON, XML, forms, email).
The cost: 33% more size
Every 3 bytes of original data becomes 4 Base64 characters — a fixed 33% overhead, always. That's why embedding an image as data:image/png;base64,... inside HTML or CSS only pays off for very small icons (a few KB): you save an HTTP request, but you pay in extra weight and lose the file's independent caching.
Where it genuinely makes sense
- JSON Web Tokens (JWT): the header and payload are Base64URL-encoded (a variant using
-and_instead of+and/, with no=padding, so it fits in a URL without escaping). Authorization: Basicheaders: username and password concatenated and encoded — which is why HTTP Basic Auth requires HTTPS, since decoding Base64 is trivial.- Embedding binaries in JSON: when you can't use
multipart/form-data, Base64 is the standard way to fit an image or PDF into a text field.
The mistake to avoid
If you need to hide something (a password, a secret token in transit), Base64 protects nothing — it's encoding, not encryption. For that, use TLS in transit and, if you need real encryption at rest, something like AES via our AES-256 encryption tool, which does require a password and can't be reversed without it.
You can encode and decode text or images with the Base64 converter (including the URL-safe variant), or convert an image directly to a data: URI with the image to Base64 converter — all in your browser, nothing uploaded anywhere.