Base64 shows up constantly — in JWTs, email attachments, data URIs, API keys — but the actual mechanism behind it rarely gets explained. It's not encryption, it's not compression; it's a way to represent arbitrary binary data using only the 64 characters that are safe to put in plain text.
The problem it solves
A lot of systems — email (originally 7-bit ASCII only), URLs, JSON strings, XML — were designed to carry text, not arbitrary bytes. Binary data (an image, a compressed file, a cryptographic key) can contain any byte value from 0–255, including bytes that those text-only systems would mangle, truncate, or misinterpret as control characters. Base64 sidesteps the problem entirely by re-encoding binary data as a string built only from letters, digits, and two symbols — characters every text-safe system can carry unmodified.
How the encoding actually works
Base64 takes your data 3 bytes (24 bits) at a time and repackages those 24 bits into four 6-bit chunks. Since 6 bits can represent 64 distinct values (2⁶ = 64), each chunk maps to one of 64 printable characters — A–Z, a–z, 0–9, plus + and /:
Input bytes (3 bytes = 24 bits):
01001000 01101001 00100001 ("Hi!" in ASCII)
Regrouped into four 6-bit chunks:
010010 000110 100100 100001
Each chunk mapped to the Base64 alphabet:
010010 = 18 → 'S'
000110 = 6 → 'G'
100100 = 36 → 'k'
100001 = 33 → 'h'
Result: "SGkh"That's the entire algorithm. No key, no randomness, no secret — the same input always produces the same output, and it's fully reversible by anyone, which is the important part for the next section.
Why it's about 33% bigger
3 bytes of input become 4 characters of output — a 4:3 ratio, or roughly 33% larger. This is the direct cost of using only 6 of every 8 bits per output byte to stay inside a 64-character alphabet. When the input length isn't a multiple of 3, the encoding pads the output with = characters so the length still comes out even.
What Base64 is not
- It's not encryption. There's no key involved, and decoding requires no secret — anyone can reverse it instantly, including with our own Base64 Decoder. Never use it to protect sensitive data.
- It's not compression. The output is larger than the input, not smaller — the goal is text-safety, not size reduction.
- It's not hashing. Hashing is one-way and produces a fixed-length digest; Base64 is two-way and its output length scales directly with input length.
Where you'll actually run into it
- The header and payload segments of a JWT (using the URL-safe variant).
- Data URIs for inlining small images directly into HTML/CSS (
data:image/png;base64,...). - Email attachments (MIME), a holdover from the ASCII-only-transport era.
- Basic HTTP authentication headers (
Authorization: Basic <base64>). - Embedding binary blobs inside JSON, which has no native binary type.
Our Base64 Encode tool runs this exact algorithm entirely in your browser — nothing you encode is ever sent anywhere, which matters if what you're encoding is a credential or another sensitive value.