What is Base64 encoding and when to use it?

Base64 is one of those tools that sounds cryptic until you know it, and then suddenly you see it everywhere. It’s in the URLs of images embedded in websites, in the tokens that authenticate your API calls, in the attachments of every email that has ever existed, and in the QR codes you scan at restaurants.

Despite being used pervasively, Base64 is often misunderstood. People think it’s encryption — it isn’t. People think it makes data smaller — it makes it bigger. People think it’s a compression format — it’s the opposite. Here’s what Base64 actually is, the problem it solves, and when you should reach for it.

What Base64 actually does

Base64 is a way of representing binary data as a string of safe, printable text characters.

That’s it. It doesn’t compress, encrypt, obfuscate, or secure anything. It just converts from a format that’s fragile (binary bytes) to a format that’s robust (ASCII text).

The problem Base64 solves

Computers store everything as binary — sequences of bits, grouped into bytes. A byte can be any value from 0 to 255. Most of those values don’t correspond to printable characters; many of them mean something special to various systems. Byte 0 is a “null” character that terminates strings in C. Byte 10 is a newline. Byte 13 is a carriage return. Bytes 128-255 are not ASCII at all — they’re interpreted differently by different encodings.

If you try to send raw binary data through a system that expects text — an email body, a JSON string, a URL, an XML attribute, a line of SQL — something will get mangled. A byte value of 13 gets interpreted as a newline, a byte of 0 truncates your string, a byte above 127 gets converted to an unexpected character.

Base64 solves this by using only 64 “safe” characters: uppercase A-Z, lowercase a-z, digits 0-9, and the symbols + and / (plus = for padding at the end). Every possible byte combination can be encoded using only these characters. The output is guaranteed to pass through any text-based system untouched.

How it works (briefly)

Base64 takes binary data 3 bytes at a time and converts each 3-byte chunk into 4 Base64 characters. Each character represents 6 bits of data (since 2⁶ = 64).

3 bytes (24 bits) → 4 base64 characters (24 bits)

The conversion is a simple lookup:

1. Split the 24 input bits into four 6-bit groups
2. Map each group to a Base64 character using the alphabet

If the input isn’t divisible by 3, the last chunk is padded with = characters so the output is always a multiple of 4.

This is why Base64 grows the data by exactly 33%. Every 3 bytes of input becomes 4 bytes of output. A 1000-byte file becomes ~1334 bytes in Base64.

Where you’ll encounter Base64 in practice

Email attachments

Email was originally designed to carry 7-bit ASCII text only. When you attach a photo to an email, the email system encodes that photo in Base64 so it can survive the journey through legacy servers. This is handled automatically by your email client — you never see the encoding — but under the hood, every image, PDF, and ZIP you’ve ever emailed has been Base64-encoded.

Data URIs in HTML/CSS

A data URI embeds a file directly into an HTML or CSS document as a Base64 string:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAA..." />

.icon {
  background: url('data:image/svg+xml;base64,PHN2Zy...');
}

The browser decodes the Base64 and renders the image as if it had been loaded from a file. This saves an HTTP round-trip for small assets — useful for tiny icons, 1×1 tracking pixels, and inline font data.

JSON with binary payloads

JSON is text-only — you can’t put raw binary bytes into a JSON string. So when an API needs to include binary data (an image, a certificate, a signature), it Base64-encodes the data first:

{
  "filename": "avatar.png",
  "content": "iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAAC..."
}

The API consumer decodes the Base64 back to bytes. This is common in REST APIs for file uploads, webhooks that transmit files, and services that handle images, certificates, or cryptographic keys.

Authentication tokens

JWTs (JSON Web Tokens), OAuth bearer tokens, and various API keys are Base64-encoded. You’ll recognise them by the combination of letters, numbers, and + / / / = characters.

Example JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJS...

Each segment between the dots is separately Base64-encoded. The first segment decodes to {"alg":"HS256","typ":"JWT"}.

URLs

A variant called “Base64 URL-safe” replaces + and / (which have special meanings in URLs) with - and _. This lets Base64 data be embedded in URLs without encoding — used extensively for short URLs, sharing tokens, and compact IDs.

Binary file transfer over text protocols

Any time you’re transferring a binary file through a text-only medium — FTP in ASCII mode, old IRC protocols, pasting a file into a chat — Base64 is the standard way to do it. Decode it on the other side and you get the original file back.

What Base64 is NOT

Not encryption

Base64 is reversible by anyone, instantly, with no key. It’s a public encoding scheme — the algorithm is public and deterministic. If you “encrypt” sensitive data by Base64-encoding it, anyone who intercepts the string can decode it in milliseconds. Base64 is encoding, not encryption. The difference is crucial.

Not compression

Base64 increases data size by 33%. If size matters, you’d typically compress first (gzip, brotli), then Base64 the result — the Base64 overhead applies to the already-compressed size.

Not obfuscation

A Base64-encoded password is a plaintext password with a trivial extra step. Any security mechanism that relies on Base64 as a “layer of protection” is broken by design.

When to use Base64

Reach for Base64 when you need to transmit or store binary data through a text-only channel (JSON, email, URL, XML), when you’re embedding small files directly in HTML or CSS (data URIs), when you’re working with a system that requires a specific Base64-encoded input (JWT, OAuth, certificates), or when you need to share binary data via copy-paste.

Don’t use Base64 when you want to protect data (use encryption), when you want to save bytes (use compression), when you have a binary-safe channel available (just send the bytes directly), or when you’re passing data between two systems that could just use a shared filesystem or object storage.

A quick cheatsheet

Need	Solution
Embed an image in HTML with no separate request	Base64-encoded data URI
Send a binary file in a JSON API	Base64-encode the file, put the string in a JSON field
Decode a JWT to see its claims	Base64-decode each segment
Share a small binary file over chat	Base64-encode, paste, the recipient decodes
Hide data from users	Encryption, not Base64
Make files smaller	Compression, not Base64

---

Base64 is a translator, not a vault. It converts binary data into text so it can travel through text-only systems — nothing more. Once you understand that, you’ll spot it everywhere, and you’ll know exactly when to use it. The full decode-and-encode workflow takes about 10 seconds per file in the Base64 tool, and since everything runs locally, you can confidently encode sensitive material without worrying about where the string ends up.