Base64 shows up everywhere on the web — in image data URIs, email attachments, JSON Web Tokens and HTTP headers — yet it is often misunderstood as a form of encryption. It is not. This guide explains what Base64 encoding actually is, how the algorithm turns bytes into text character by character, and when you should (and should not) use it.
What Base64 is and why it exists
Base64 is a binary-to-text encoding scheme. It takes arbitrary binary data — an image, a PDF, a UTF-8 string — and represents it using only 64 printable ASCII characters: the letters A–Z and a–z, the digits 0–9, plus + and /, with = used for padding at the end.
Why bother? Many channels that carry data were designed for plain text and are not "8-bit clean". Classic email (SMTP) historically passed only 7-bit ASCII; bytes with the high bit set could be mangled or stripped in transit. URLs cannot safely contain characters like +, / or raw binary at all. Embedding an image inside HTML or CSS requires text. Base64 solves all of these cases the same way: it rewrites binary as boring, universally safe text, at the cost of some extra size. The format is standardized in RFC 4648, and it descends from the MIME work in RFC 2045.
How Base64 encoding works
The algorithm processes the input three bytes (24 bits) at a time. Those 24 bits are split into four groups of 6 bits, and each 6-bit group — a number from 0 to 63 — indexes one character of the 64-character alphabet. So 3 bytes always become 4 characters.
Worked example: encoding the string Man.
| Step | Byte 1 | Byte 2 | Byte 3 |
|---|---|---|---|
| Input characters | M | a | n |
| ASCII values | 77 | 97 | 110 |
| As 8-bit binary | 01001101 | 01100001 | 01101110 |
The 24-bit stream 010011010110000101101110 is then re-cut into four 6-bit groups, and each group becomes one output character:
| 6-bit group | Decimal index | Base64 character |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
The result is TWFu. Index 19 in the alphabet (counting A as 0) is T, 22 is W, 5 is F and 46 is u.
The = padding
When the input length is not a multiple of 3, the last group is short. Base64 pads the final 6-bit group with zero bits and writes = for each missing character, so the output length stays a multiple of 4:
| Input | Leftover bytes | Base64 | Ending |
|---|---|---|---|
M | 1 | TQ== | two pad characters |
Ma | 2 | TWE= | one pad character |
Man | 0 | TWFu | no padding needed |
Decoding simply reverses the process: map each character back to its 6-bit value, concatenate the bits, and read off 8-bit bytes.
The ~33% size overhead
Base64 trades size for safety. Every 3 bytes of input become 4 characters of output — 24 real bits carried in 32 bits of text. The overhead is therefore exactly 4/3, or about 33.3%. One mebibyte (1,048,576 bytes) of binary becomes 1,398,104 Base64 characters. MIME email makes it slightly worse by wrapping lines at 76 characters, adding a line break every 76 output characters.
This is why you should not Base64-encode large assets for a website: a 500 KB image inflates to roughly 667 KB of text before compression, and it also bypasses some binary caching and streaming optimizations. Use it for small embeds where the convenience outweighs the extra bytes.
URL-safe Base64
The standard alphabet contains + and /, both of which have special meaning in URLs (+ decodes to a space in query strings, / separates path segments). The URL-safe variant, called Base64URL and defined in the same RFC 4648, swaps them:
| Standard Base64 | Base64URL |
|---|---|
+ (index 62) | - |
/ (index 63) | _ |
= padding required | padding optional, usually omitted |
Base64URL is what JSON Web Tokens use for their three dot-separated segments, and it is the right choice whenever encoded data will travel in a URL, cookie or filename.
Where you meet Base64 every day
| Place | What Base64 carries | Example |
|---|---|---|
| Data URIs | Small images or fonts embedded in HTML/CSS | data:image/png;base64,iVBORw0KGgo= starts every embedded PNG |
| Email attachments | Binary files sent over text-only SMTP (MIME) | Content-Transfer-Encoding: base64 |
| JWTs | Header, payload and signature segments | eyJhbGciOi... — the JSON header in Base64URL |
| HTTP Basic auth | username:password in the Authorization header | Authorization: Basic dXNlcjpwYXNz is Base64 of user:pass |
| APIs and config | Keys, certificates and binary blobs inside JSON or YAML | PEM certificates are Base64 between header lines |
Encoding vs encryption: Base64 is not security
This is the single most important thing to understand: Base64 is encoding, not encryption. It has no key, no secret and no randomness. Anyone who sees a Base64 string can decode it instantly — the alphabet is public and the algorithm is trivial. Encoding password as cGFzc3dvcmQ= hides it from nobody.
The consequences are practical. HTTP Basic auth sends credentials in plain Base64, which is why it must always run over HTTPS. A JWT payload is only Base64URL-encoded, so never put secrets in it — the signature guarantees integrity, not confidentiality. And if you find "obfuscated" Base64 data in logs, code or emails, treat it as plaintext wearing a costume.
To experiment safely, paste any string into the Base64 Encoder / Decoder — it encodes and decodes entirely in your browser, handles UTF-8 text correctly, and offers the URL-safe variant, so you can watch the 3-bytes-to-4-characters transform happen live.