Base64 is one of those formats every developer has used but few can explain without pausing. It looks like random characters. It makes data bigger. And yet it’s the backbone of email attachments, JWT payloads, inline images in CSS, and dozens of other protocols that need to move binary data over text-only channels.
The short version: Base64 encodes arbitrary binary data as printable ASCII characters. The long version involves a 64-character alphabet, padding rules, and a few variants that trip people up in production.
Why Base64 exists
Many systems were designed to carry only text — email (SMTP), URLs, XML, JSON. If you want to send a binary file through one of those pipes, you need a way to represent bytes as characters. Base64 solves this by mapping every 3 bytes of input to 4 characters of output, using only characters that are safe in virtually every text protocol.
The trade-off: Base64 increases data size by roughly 33%. A 1KB image becomes about 1.3KB of text. For most use cases that’s fine. For high-throughput systems it matters, and you’ll see alternatives like Base85 or raw binary protocols.
The 64 characters
The alphabet is:
A-Z (26 characters)
a-z (26 characters)
0-9 (10 characters)
+ / (2 characters)That’s 64 characters total, hence the name. The = character is used for padding when the input length isn’t a multiple of 3 bytes.
Every character in the alphabet is printable ASCII, which means Base64 output can travel through email, appear in JSON strings, sit inside HTML attributes, and survive systems that might mangle raw binary.
How encoding works
Take three bytes of input. Each byte has 8 bits, so you have 24 bits total. Base64 splits those 24 bits into four 6-bit groups. Each 6-bit group maps to one character in the alphabet:
000000→A000001→B- …
111111→z
That’s it. The encoding is a simple bit-level transformation with no key, no salt, and no secret. Anyone can decode Base64 by reversing the lookup table.
Padding
If the input length isn’t a multiple of 3, padding fills the gap:
- 1 byte remaining → 2 Base64 characters +
== - 2 bytes remaining → 3 Base64 characters +
= - 0 bytes remaining → no padding
The padding characters don’t carry data. They exist so the output length is always a multiple of 4, which many parsers expect.
Variants
Not all Base64 is identical:
- Standard Base64 (
A-Za-z+/=) — the default, used in MIME emails and most protocols. - URL-safe Base64 (
A-Za-z-_) — replaces+with-and/with_, removes padding. Used in JWTs, URL parameters, and filenames. - Base64 without padding — some systems omit the
=characters. Output is shorter but some parsers choke on it.
When you’re debugging a JWT or a data URI and the decoding fails, the first thing to check is whether the encoder used URL-safe Base64 or standard Base64. A - in the middle of what you expected to be a standard Base64 string is the giveaway.
Where developers actually encounter Base64
Email attachments. MIME (RFC 2045) uses Base64 to encode binary attachments. If you’ve ever seen a .eml file with long strings of random characters, that’s Base64-encoded content.
JWT payloads. The three parts of a JWT (header, payload, signature) are each URL-safe Base64-encoded. When you decode a JWT, you’re reversing the Base64url encoding on each segment. See our JWT decode guide for more details.
Data URIs. data:image/png;base64,iVBOR... lets you inline an image directly in HTML or CSS. The image bytes are Base64-encoded so they can appear in a text attribute.
APIs. Some APIs accept or return Base64-encoded binary data (file uploads, image processing, cryptographic signatures). It’s less common now that most APIs support multipart form data, but it still shows up.
Embeddings. Machine learning models sometimes store embeddings as Base64 strings in JSON. It’s not ideal for performance, but it’s convenient for transport.
When NOT to use Base64
Don’t use it for encryption. Base64 is an encoding, not encryption. Anyone can decode it. If you’re putting sensitive data in Base64, you’re just obscuring it, not protecting it.
Don’t use it for compression. Base64 makes data bigger, not smaller. If you’re Base64-encoding already-compressed data (like a .gz file), you’re adding overhead for no benefit.
Don’t use it in performance-critical paths. The encoding/decoding adds CPU time and increases payload size. For high-frequency internal APIs, use binary protocols (protobuf, msgpack) instead.
Don’t forget the variant. If you’re generating Base64 for a URL or a JWT, use URL-safe Base64. If you’re generating for email or general transport, use standard Base64. Mixing them up causes silent data corruption.
Quick reference
| Scenario | Variant | Padding |
|---|---|---|
| JWT | URL-safe | No |
| Email / MIME | Standard | Yes |
| Data URI | Standard | Optional |
| URL parameter | URL-safe | No |
| General transport | Standard | Yes |
Try it
If you have a Base64 string you need to decode, or binary data you need to encode, use a browser-based tool so the conversion happens locally — your data doesn’t get sent to a server for something this simple.