What Is Base64 and Why Is It Everywhere? (It Is Not Encryption)
Base64 explained simply: how it turns binary data into text, where it is used, why it makes data 33% bigger, and why it must never be used to hide secrets.
If you have looked at the source of an email, a JSON Web Token or a web page with embedded images, you have seen long strings like SGVsbG8gd29ybGQ=. That is Base64. It looks cryptic, but it is one of the simplest and most widely used encodings on the internet.
The problem Base64 solves
Many systems were designed to carry text, not arbitrary bytes. Early email, for example, could only safely transport plain ASCII characters. Binary data such as images or PDF attachments contains bytes that such systems might change, strip or misinterpret. Base64 represents any data using only 64 safe characters: A-Z, a-z, 0-9, + and /, with = for padding.
How it works
Base64 takes the input three bytes at a time, which is 24 bits, and splits them into four groups of six bits. Each six-bit group is a number from 0 to 63 and is written as one of the 64 characters. Three bytes in, four characters out. If the input length is not a multiple of three, the output is padded with one or two = signs.
That is also why Base64 is always about 33 percent larger than the original. Embedding a 300 KB image as Base64 adds about 100 KB.
Where you meet Base64
- Email attachments: every file attached to an email is Base64-encoded inside the message (the MIME standard).
- Data URLs: small images embedded directly in HTML or CSS, such as
data:image/png;base64,iVBORw0.... - JSON Web Tokens (JWT): the header and payload of a login token are Base64URL-encoded JSON.
- HTTP Basic authentication: the
Authorization: Basicheader containsusername:passwordin Base64. - APIs that need to send files inside JSON.
- Certificates and keys in PEM format, the blocks starting with
-----BEGIN CERTIFICATE-----.
Base64 is not encryption
This is the most important point. Anyone can decode Base64 instantly, with no key. Paste a Basic authentication header into a Base64 decoder and you see the username and password in plain text. That is why Basic authentication must only be used over HTTPS, and why you should never “protect” passwords, API keys or personal data by Base64-encoding them in code, config files or URLs.
The same applies to JWTs: the payload is readable by anyone. A JWT is signed to prevent tampering, not encrypted to prevent reading. Do not put secrets in it.
Standard vs URL-safe Base64
The characters + and / have special meaning in URLs and file names. The URL-safe variant, called Base64URL, replaces them with - and _ and usually drops the = padding. JWTs use this variant. Our decoder accepts both, and the encoder has a URL-safe option.
Text, bytes and UTF-8
Base64 encodes bytes, not characters. Text has to be turned into bytes first, and the standard way is UTF-8. A common bug in JavaScript is using btoa() directly on text with accented letters or emoji, which throws an error. Proper tools encode text as UTF-8 first. If you decode Base64 and get garbled characters, the original was probably encoded with a different character set, or it is not text at all but an image or a ZIP file.
When to use it, and when not
- Good: embedding a tiny icon in CSS, sending a small file through a JSON API, storing binary data in a text-only field.
- Bad: embedding large images in web pages (bigger files and no caching), hiding secrets, or storing files in a database just because it is convenient.
Our take
Base64 is plumbing: essential, boring and invisible when it works. Learn to recognise it, because decoding a suspicious string often tells you a lot, whether it is a token in a URL, an attachment in a raw email or a credential someone thought was hidden. And if you ever see Base64 used as “security”, treat it as a bug.