Why Base64 Exists
Base64 was invented to solve a specific problem: moving binary data through systems designed to handle only text. Email protocols (SMTP), HTTP headers, and many storage systems were built to handle printable ASCII characters. Binary data — images, executables, certificates — contains byte values that these systems misinterpret as control characters, line endings, or null terminators.
Base64 encodes any binary data using only 64 printable characters: A–Z, a–z, 0–9, +, and /. The result is always safe to embed in text-based formats.
How It Works
Base64 takes 3 bytes of input (24 bits) and converts them into 4 characters. Each character represents 6 bits of the original data.
M= 77 = 01001101a= 97 = 01100001n= 110 = 01101110
Combined: 010011010110000101101110
Split into 6-bit groups: 010011 | 010110 | 000101 | 101110
Each group maps to a character in the Base64 alphabet: T, W, F, u → TWFu
Because 3 bytes become 4 characters, Base64 increases data size by approximately 33%.
The Padding Character
If the input isn't divisible by 3, Base64 pads the output with = characters. One padding character means the last group had 2 input bytes; two padding characters means it had 1 input byte.
Man → TWFu (no padding needed)
Ma → TWE= (one padding)
M → TQ== (two padding)
URL-Safe Base64
Standard Base64 uses + and /, which are special characters in URLs. URL-safe Base64 replaces them with - and _ respectively, and usually omits padding. You'll see this variant in JWTs, OAuth tokens, and anything meant to appear in a URL query string.
When to Use Base64
- Embedding images in HTML or CSS as data URIs:
src="data:image/png;base64,iVBOR..." - Encoding binary data in JSON payloads (JSON has no binary type)
- Transmitting file attachments via email (MIME encoding)
- Storing cryptographic keys and certificates in PEM format
- Encoding the header and payload sections of JWTs
- As a form of encryption or obfuscation — Base64 is trivially reversible by anyone
- To "hide" API keys in client-side code — they're still readable
- As a URL shortener or password encoding — use proper hashing instead
Common Mistakes
**Mistake 1: Treating Base64 as encryption.** It isn't. Anyone can decode a Base64 string in seconds. It's encoding, not encryption.
**Mistake 2: Double-encoding.** If you Base64-encode a string that's already Base64, you get garbage. Always check the input before encoding.
**Mistake 3: Using standard Base64 in URLs.** The + and / characters will be misinterpreted. Use URL-safe Base64 or percent-encode the output.
**Mistake 4: Ignoring the 33% size overhead.** Embedding large images as data URIs inflates page size significantly. For images above a few kilobytes, external files with proper caching are almost always better.
Decoding Base64 in Practice
NoxaKit's Base64 Encoder & Decoder handles both encoding and decoding instantly in the browser — useful for inspecting JWTs, debugging API responses, or checking what's inside a PEM certificate. The Base64 Image Viewer decodes base64-encoded images so you can see what's actually stored in a data URI.