Developer guide
Base64 Encoding Explained: What It Is and When You Actually Need It
Base64 is everywhere — in every email attachment, every image data URI, and most API authentication headers. It also comes with a 33% size penalty and a thick load of misconceptions. This guide explains how it works, why the = padding is there, and the mistakes that break decoding.
Written by Benjamin Rotshtein
Updated
- Is Base64 secure?
- No. It's an encoding, not encryption. Decoding takes milliseconds and any decoder works. Never rely on Base64 to hide secrets.
- How much does it bloat my data?
- Exactly 33% larger, give or take padding: 3 bytes become 4 characters. A 1 MB file becomes roughly 1.34 MB of Base64 text.
- What is the = for?
- Padding. When the last group of input bytes is short, = fills it so the encoded length stays a multiple of 4. Some decoders are lenient, but most expect correct padding.
How Base64 works
Base64 maps binary bytes onto an alphabet of 64 safe characters. Each output character represents 6 bits of the input, and the encoder processes input in groups of 3 bytes (24 bits) that become 4 characters (4 × 6 = 24 bits):
"Man" -> 0x4D 0x61 0x6E -> 011011 010110 000101 101110 -> TWFu
The alphabet covers A-Z a-z 0-9 + / — 64 characters that survive email, JSON and URLs without escaping. That's the whole trick: it trades 33% more characters for a guarantee that nothing will be mangled in transit.
Why the padding (=) exists
Not every input length is a multiple of 3. When the final group is short, Base64 pads it:
"Ma" -> 0x4D 0x61 -> TWE= "M" -> 0x4D -> TQ==
One = means 2 bytes in the last group; two mean 1 byte. The padding also guarantees the total encoded length is always a multiple of 4, which decoders rely on. You can usually strip the padding when embedding in a URL (using the URL-safe variant), but the bytes on disk should keep it.
The 33% size cost, made concrete
| Input | Base64 output | Overhead |
|---|---|---|
| 1 KB text | ~1.37 KB | ~37% (rounding) |
| 1 MB image | ~1.34 MB | 33% |
| 10 MB payload | ~13.4 MB | 33% |
When you actually need Base64
- Email attachments: MIME wraps every binary attachment in Base64 so it survives 7-bit email transport.
- Image data URIs:
data:image/png;base64,...embeds small images directly in HTML or CSS. - JSON binary fields: JSON is text, so binary blobs must be encoded before being stored in a JSON document.
- HTTP headers: tokens like Basic auth use
base64(user:pass)because headers only carry safe characters. - Config values: encode a value so it survives copy-paste, environment files and shell quoting intact.
The mistakes that break decoding
Most Base64 failures are not bugs in the encoder. They are:
- Wrong encoding on decode: bytes only become text through a charset. Decode UTF-8 as Latin-1 and you get mojibake.
- URL-safe vs standard:
+and/are reserved in URLs, so URL-safe encoding swaps in-and_. Mixing the two breaks decoding. - Broken or missing padding: a string whose length isn't a multiple of 4 fails in strict decoders.
- Decoding text that was never Base64: not every safe-looking string is valid Base64 — the decoder will simply fail.
Encoding and decoding, safely
The Base64 encoder and Base64 decoder on this site handle Unicode correctly (emoji, Hebrew, Arabic), validate padding, and run entirely in your browser — your tokens and payloads never leave your machine.
Frequently asked questions
What exactly does Base64 do?
It maps arbitrary binary data to a safe ASCII alphabet of 64 characters (A-Z, a-z, 0-9, +, /), plus '=' for padding. That lets binary data travel through channels designed for text — email, JSON, URLs, HTTP headers — without corruption.
Why does Base64 add '=' padding at the end?
Base64 encodes 3 input bytes into 4 output characters. If the input length isn't a multiple of 3, the last group is short and the encoder pads it with '=' so the total length stays a multiple of 4. One '=' means 2 bytes left, two mean 1 byte.
How much bigger is Base64 than the original data?
Always 33% larger, minus a rounding effect: 3 bytes become 4 characters, and padding replaces some of them. So 10 MB of binary becomes about 13.4 MB of Base64 text. There is no way to encode more efficiently with this alphabet.
Is Base64 encryption or compression?
Neither. Base64 is an encoding for safe transport, not secrecy and not size. Anyone can decode it in seconds, and it makes data 33% bigger. Never use it to protect sensitive values — that's what encryption is for.
When do I actually need Base64?
When binary must live in a text-only channel: email attachments (MIME), image data URIs in HTML/CSS, JSON fields holding binary, Authorization header tokens, and config values that need to survive copy-paste without corruption.
Why does my decoded text show mojibake like �?
Base64 decodes to bytes, and bytes only become readable text when you interpret them with the right character encoding. If the original was UTF-8 and you decode as Latin-1 (or vice versa), you get mojibake. Always decode as the same encoding that was used to encode.