Base64 Explained: What It Is, What It Isn't, and When to Use It
Why Base64 exists, how the encoding actually works, why it isn't encryption, and the real-world cases where you'd use it — or shouldn't.
You've seen Base64 even if you didn't know its name — those long strings ending in == inside URLs, emails, and API payloads. It's one of the most-used encodings on the internet, and one of the most misunderstood. Let's fix that.
The problem Base64 solves
Lots of systems were built for text: email, JSON, XML, HTML, URLs. Binary data — images, files, encrypted bytes — contains byte values these systems mangle or forbid. Base64 solves this by representing any binary data using just 64 safe, printable characters: A–Z, a–z, 0–9, + and /.
How it works (in one paragraph)
Take the input 3 bytes (24 bits) at a time, slice those 24 bits into four 6-bit chunks, and map each chunk (a number 0–63) to one of the 64 characters. If the input length isn't a multiple of 3, pad the output with = signs — that's why Base64 strings so often end in = or ==. The padding also explains the size cost: every 3 bytes become 4 characters, so encoded data is ~33% larger than the original.
Example: Hi! → SGkh. Try your own text in the Base64 Encoder and reverse it with the Decoder.
The most important fact: it's not encryption
Base64 requires no key and hides nothing. Decoding is instant and universal — every language, every browser console, every CLI can do it. Yet "protected" credentials in Base64 still turn up constantly in breached configs and mobile apps.
If you remember one thing: Base64 provides zero secrecy. Anything sensitive needs actual encryption; Base64 is merely the envelope that lets encrypted (or any binary) bytes travel through text systems safely.
Where you'll actually meet it
- JWTs — the header and payload of every JSON Web Token are Base64url-encoded JSON. That's why anyone can read a token's contents in our JWT Decoder — and why you never put secrets in one.
- Data URLs — small images embedded directly in HTML/CSS as
data:image/png;base64,..., saving an HTTP request. Our Image to Base64 tool does this conversion. Rule of thumb: sensible for icons under a few KB, wasteful for anything bigger (remember the +33%). - Email attachments — every attachment you've ever sent traveled as Base64 (MIME encoding).
- HTTP Basic Auth — the
Authorization: Basic ...header is justusername:passwordin Base64. This is exactly why Basic Auth is only acceptable over HTTPS. - API payloads — binary blobs (signatures, file uploads, crypto keys) inside JSON.
Base64 vs. its variant: Base64url
Standard Base64 uses + and /, which have special meanings in URLs. The URL-safe variant swaps them for - and _ and usually drops padding. JWTs use this variant — if a decoder rejects your string, a variant mismatch is the usual reason.
When not to use it
- To hide anything (it doesn't)
- For large files in JSON APIs — the 33% overhead and memory cost add up; use multipart uploads or object storage links
- As a substitute for proper escaping — for HTML contexts use the HTML Escape tool, for URLs use the URL Encoder; each context has its own correct encoding
Try it
Round-trip some text through the encoder and decoder, then decode the middle segment of any JWT you have lying around — seeing your own session data in plain sight is the fastest way to internalize what Base64 does and doesn't protect.