What Is Base64? Encoding, Not Encryption, Explained

Base64 shows up everywhere — inside every JWT, in Authorization: Basic headers, in data URIs, in email attachments, and stapled onto source maps — and because it looks like gibberish, people assume it does something it doesn't. Base64 is not encryption, it's not compression, and it's not obfuscation worth relying on. It is a reversible encoding for representing arbitrary bytes with a restricted set of printable characters, and once you understand that one job, most of the confusion around it disappears.

What Base64 actually does

It rewrites bytes using a 64-character alphabet. The standard alphabet is the letters A through Z, the letters a through z, the digits 0 through 9, plus + and /, with = used as padding at the end. Every Base64 character encodes 6 bits, so three input bytes (24 bits) become four output characters. That fixed ratio is why a Base64 string is always about a third longer than the raw bytes it represents — the encoding inflates size deliberately, in exchange for safety.

The reason that tradeoff exists: many systems and protocols were designed around text. Email (SMTP), URLs, HTML, JSON, and XML all choke on or mangle raw binary — null bytes, control characters, and byte sequences outside ASCII get corrupted or truncated in transit. Base64 gives you a way to ship binary data through a text-only channel intact, because every character it emits is a safe, printable ASCII character.

Here is the same idea in code:

// Encode: text -> bytes -> Base64
const encoded = btoa("hello, world");
// "aGVsbG8sIHdvcmxk"

// Decode is trivial and lossless — no key required
atob("aGVsbG8sIHdvcmxk");
// "hello, world"

Decoding is trivial and lossless. Anyone with the Base64 string can recover the original bytes — no key, no secret, no work. That is the single most important fact about Base64, and it is why treating it as a form of protection is a category error.

Encoding is not encryption

This comes up constantly: a developer Base64-encodes a token or an API key, drops it into a client-side script or a config file, and treats it as "hidden." It isn't. Base64 is fully reversible by design, and every browser, every language standard library, and every attacker on the planet can decode it in one line:

atob("c2VjcmV0LWFwaS1rZXk="); // "secret-api-key"

If you need confidentiality, use encryption (AES-GCM for symmetric data, or a library like libsodium's secretbox), and keep the key on a server you control. If you need integrity, use a signed HMAC or a proper JWT signature. Base64 gives you neither — it only solves the transport problem of moving binary through a text channel.

The two flavors: standard vs. Base64URL

The standard alphabet uses + and /, both of which are problematic inside URLs (where + can be decoded as a space and / splits path segments). For data that needs to live in a URL or a filename, there is a URL-safe variant, Base64URL, which swaps those two characters for - and _ and typically drops the = padding.

JWTs use Base64URL for all three segments — header, payload, and signature. If you have ever decoded a JWT by hand and noticed missing padding or hyphens where you expected plus signs, that is why. The Base64 Encode/Decode tool handles both variants, and the JWT Decoder does the Base64URL decoding for you automatically when inspecting a token.

Where you will actually meet Base64

A few places it shows up in everyday development work:

• Data URIs for inlining small images or fonts directly into HTML or CSS, prefixed with a MIME type.

• HTTP Basic auth, where the Authorization header carries the Base64 of user:pass:

  Authorization: Basic dXNlcjpwYXNz
  

  Readable by anyone on the path, so it must always go over HTTPS, and it asserts nothing more than "these credentials are present."

• Email attachments via MIME, the original use case the encoding was designed for — getting binary files through mail servers that only understood ASCII.

• Source maps and small assets bundled into JavaScript, where binary data needs to survive being part of a text file.

When to reach for it (and when not to)

Reach for Base64 when you need to embed or transport binary data through a text-only medium and you don't care that it is recoverable — data URIs, inlined assets, packing a small binary blob into JSON. Skip it when you are tempted to use it as a hiding mechanism, when the size inflation matters (it adds roughly 33 percent to the payload, which adds up fast on large assets), or when the data is already plain text and you just want it to look scrambled. For that last case, what you actually want is real encryption or an HMAC — and URL Encode/Decode is the right tool when the problem is "this string breaks my URL," not "this string needs to be secret."