How Base64 encoding works (and when to use it)
Base64 appears everywhere — in data URIs, JWT tokens, email attachments, and API payloads — yet it is often mistaken for encryption. This guide explains what it actually does, why encoded data is a third bigger than the original, and the few cases where reaching for it is the right call.
01 — The core idea
64 safe characters for any bytes
Some channels — email, URLs, JSON strings — were built for text and mangle raw binary. Base64 solves this by re-encoding any data using just 64 characters that survive every text channel: A–Z, a–z, 0–9, + and / (with = as padding).
The algorithm reads the input 3 bytes (24 bits) at a time and splits them into four 6-bit chunks. Each chunk — values 0 to 63 — maps to one character of the alphabet. That is the entire trick.
Input bytes: | 101010 | 110101 | (3 bytes = 24 bits, split into 4 × 6 bits)
Alphabet: A-Z a-z 0-9 + / → each 6-bit value picks one characterBase64 is encoding, not encryption. Anyone can decode it instantly — never use it to hide passwords, keys, or secrets.
02 — The size cost
Why Base64 is 33% bigger
Three bytes become four characters, so the output is exactly 4/3 the size — about 33% larger — before counting the optional padding = characters. For the word Mme (3 bytes) you get TW1l (4 characters); larger data follows the same ratio.
This is why embedding big images as Base64 is usually a mistake: a 500 KB photo becomes roughly 667 KB of text, travels inside your HTML or CSS, and loses cacheability. Small icons and logos are fine; anything over ~10 KB should stay a separate file.
03 — Everyday uses
Where you will actually meet it
| Use | Example | Note |
|---|---|---|
| Data URIs | data:image/png;base64,… in CSS/HTML | Best for small images; saves an HTTP request |
| JWT tokens | Header and payload are Base64URL-encoded | URL-safe variant: - and _ replace + and / |
| Email attachments | MIME base64 transfer encoding | The reason attachments are ~33% larger |
| API payloads | Binary fields inside JSON | JSON cannot carry raw bytes |
04 — Variants
Standard vs URL-safe Base64
Standard Base64 uses + and /, which have special meaning in URLs. The URL-safe variant swaps them for - and _ and usually drops the padding. They are otherwise identical — when decoding a token that fails, try converting -→+, _→/ and re-adding = padding. JWTs use the URL-safe form.
FAQ
Frequently asked questions
Is Base64 encryption?
No. Encryption protects data with a key; Base64 is a reversible, key-free text encoding. "Decoding" takes one line of code in any language.
Why does the encoded string end with = signs?
Padding. The algorithm works on 3-byte groups, and leftover bytes are padded with = so the output length is always a multiple of 4. One = means 2 leftover bytes; two means 1.
Does Base64 compress data?
The opposite — it inflates data by ~33%. If you need smaller payloads, compress first (gzip), then Base64 the compressed bytes.
Keep reading