Base64 Encoding: What Every Developer Should Know
Base64 is everywhere — email attachments, JWTs, data URIs, API auth headers. Here's a no-fluff explanation of what it actually does and when you should (and shouldn't) use it.
The short version
Base64 takes binary data — bytes — and encodes it as a string of 64 printable ASCII characters. That's it. It's not encryption. It's not compression. It's just a way to represent binary as text so it can travel safely through systems that only handle text.
Why does this exist?
Old email systems (and a lot of other protocols) were built to handle plain ASCII text. They choked on binary data — images, executables, anything with bytes outside the standard printable range. Base64 was the fix: take the binary, encode it as a safe ASCII string, send it through the text-only system, decode it on the other end.
Emails still work this way. When you attach an image to an email, your client Base64-encodes it before sending. The receiving client decodes it. You never see any of this.
Where you'll actually run into it as a developer
Base64 shows up in a lot of places that aren't immediately obvious:
- HTTP Basic Auth — credentials are sent as
Authorization: Basic <base64(username:password)>. The encoding is Base64, not encryption. Anyone who captures the header can decode it instantly. - JWTs— JSON Web Tokens use Base64URL (a variant) for the header and payload sections. That's why you can decode a JWT without any secret key — the payload isn't encrypted, just encoded.
- Data URIs — embedding images directly in CSS or HTML:
src="data:image/png;base64,iVBOR...". The entire image file, encoded as a string. - API payloads — any API that needs to send binary data (file uploads, thumbnails, certificates) in a JSON body uses Base64.
- Environment variables — secrets like private keys and certificates are often Base64-encoded to avoid newline/whitespace issues when stored in env vars.
How it actually works
Base64 takes every 3 bytes of input and maps them to 4 characters from a 64-character alphabet (A–Z, a–z, 0–9, +, /). If the input isn't divisible by 3, it pads with = characters.
In practice: Base64 output is always about 33% larger than the input. A 100KB image becomes ~133KB in Base64. Worth it for transport, not worth it for storage.
| Input | Base64 Output |
|---|---|
Man | TWFu |
Hello | SGVsbG8= |
{ | ew== |
BuiltItDev | QnVpbHRJdERldg== |
Base64 vs Base64URL
Standard Base64 uses + and / characters, which have special meaning in URLs. Base64URL swaps them for - and _to make the output URL-safe. JWTs use Base64URL. When you're dealing with tokens or anything that goes into a URL, make sure you're using the right variant.
Decoding a JWT right now
Copy any JWT and split it at the dots. You get three Base64URL-encoded parts: header, payload, signature. Decode the first two and you'll see the raw JSON. The signature part is cryptographically signed — you can't forge it without the secret key — but the payload is just encoded, not encrypted.
Our Base64 Encoder/Decoder handles both standard and URL-safe variants. Paste anything in, get the encoded or decoded output instantly, no server involved — your data stays in your browser.
Once you understand what Base64 actually is — just binary-to-text encoding, nothing magical — a lot of things in web development start making more sense. Why JWTs look the way they do. Why auth headers look base64ish. Why images in CSS sometimes look like a wall of random characters.
Try it free