Encoding, not encryption
Base64 is everywhere in modern software — in data URLs, email attachments, JSON Web Tokens, API payloads and configuration files — yet it is widely misunderstood. The single most important fact to get straight is this: Base64 is an encoding, not encryption. It provides zero security. Anyone can decode it in a second. What it does is solve a completely different problem: safely moving binary data through systems that were only ever designed to handle text.
The problem it solves
Computers store everything — images, audio, executables — as raw bytes, where each byte can be any of 256 values. Many older and text-based channels, though, only reliably carry a limited set of printable characters. Email, URLs, XML and JSON can all choke on, strip, or mangle arbitrary bytes: a stray null byte or control character can break the message. Base64 sidesteps this by re-expressing any binary data using only 64 safe, printable characters that survive transit everywhere.
Those 64 characters are the uppercase letters, the lowercase letters, the digits 0–9, plus + and / — with = used for padding.
How the conversion works
Base64 works by regrouping bits. Binary data is a stream of 8-bit bytes; Base64 slices it into 6-bit chunks instead, because 2⁶ = 64 maps neatly onto its 64-character alphabet. Three bytes (24 bits) become exactly four Base64 characters:
- The word
Manis three bytes: 77, 97, 110. - As bits that is
01001101 01100001 01101110. - Regrouped into 6-bit pieces:
010011 010110 000101 101110→ 19, 22, 5, 46. - Those indices map to the alphabet as
TWFu.
When the input length is not a multiple of three, Base64 pads the output with one or two = signs so the result is always a multiple of four characters. This regrouping is also why Base64 is larger than the original — every 3 bytes become 4 characters, a 33% size increase.
When you should — and shouldn't — use it
| Good fit | Poor fit |
|---|---|
| Embedding a small icon in CSS as a data URL | Storing or transmitting large files |
| Putting binary data inside JSON or XML | Anything needing actual security |
| Encoding email attachments (MIME) | Hashing or password storage |
| Carrying a token through a URL safely | Compressing data (it grows, not shrinks) |
The classic mistake is reaching for Base64 to “hide” something — an API key, a password, a token's contents. Because decoding is trivial and reversible, this offers no protection at all. If you need confidentiality, you need encryption (and for passwords, hashing). Base64 is about compatibility, never secrecy.
URL-safe Base64
The standard + and / characters have special meanings inside URLs, so a variant called URL-safe Base64 swaps them for - and _ and often drops the padding. This is what you see in JSON Web Tokens and many API keys. It encodes the same data — just with an alphabet that will not be corrupted when placed in a web address.
You can try all of this hands-on with our Base64 encoder & decoder, and when the decoded result is structured data, the JSON tools will format and validate it for you.