Skip to main content

What is Base64 encoding, and when should you use it?

6 min read

Base64 turns binary data into plain text so it survives systems built for text. Here's how it works, when it helps, and when it doesn't.

Base64 encoding is a way to represent binary data (any sequence of bytes) using just 64 plain-text characters: A–Z, a–z, 0–9, and + and /. Its job is to let data that isn’t text survive travel through systems that only expect text. It is not encryption, and it does not compress. In fact it makes data slightly larger.

How it works

Computers store everything as bytes (8 bits each). Base64 regroups those bits into chunks of 6, because 6 bits have exactly 64 possible values, one for each character in the alphabet. Three bytes (24 bits) become four Base64 characters (4 × 6 = 24 bits). When the input length isn’t a multiple of three, the output is padded with = signs to keep that 4-character alignment.

Text:    M         a         n
ASCII:   77        97        110
Bits:    01001101  01100001  01101110
Regroup: 010011  010110  000101  101110
Base64:  T       W       F       u
Result:  "Man" → "TWFu"

Because roughly every 3 bytes become 4 characters, Base64 output is about 33% larger than the original. That overhead is the price of making binary data text-safe.

When to use it (and when not to)

Base64 earns its keep when binary data has to live inside text:

  • Data URIs, embedding a small icon directly in HTML or CSS: data:image/png;base64,iVBORw0KGgo…
  • JSON and XML fields, carrying a file or raw bytes in a payload that only allows text.
  • HTTP Basic Auth, where the Authorization header sends user:password Base64-encoded (which is why Basic Auth requires HTTPS, since the encoding is trivially reversible).
  • Email attachments, where MIME has used Base64 for decades to send files through a text-based protocol.

Avoid it for large files. The 33% bloat and the encode/decode cost make it a poor fit for anything sizeable, so send those as raw binary instead.

It is not encryption

This is the single most important thing to understand: Base64 offers no security. There is no key, and decoding is instant and universal. If you see a Base64 string, treat its contents as fully readable. To protect data, encrypt it; Base64 only changes how the bytes are written down.

Base64 vs. URL encoding

They are often confused because both make data “safe”, but for different channels. URL (percent) encoding escapes characters that are special inside a URL, so a space becomes %20. Base64 converts arbitrary bytes to text. The catch: standard Base64 uses + and /, which themselves have meaning in a URL, so a URL-safe Base64 variant substitutes - and _.

To encode or decode Base64 without touching a command line, use our free Base64 encoder (and the matching decoder). Everything runs in your browser, so the data never leaves your device.

Frequently asked questions

What is Base64 encoding?
Base64 is a way to represent binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, + and /). It lets bytes that would otherwise be unsafe or unprintable travel through systems designed for text, such as email bodies, JSON fields and URLs.
Is Base64 encryption?
No. Base64 provides no security whatsoever: anyone can decode it instantly, with no key. It only changes the representation of data, not its secrecy. Never use it to hide passwords or sensitive data.
When should I use Base64?
Use it when binary data must pass through a text-only channel: embedding a small image in HTML or CSS as a data URI, putting a file in a JSON field, or encoding credentials in an HTTP Basic Auth header. Avoid it for large files, where it wastes about a third of the size.
What is the difference between Base64 and URL encoding?
They solve different problems. Base64 turns arbitrary bytes into text. URL (percent) encoding escapes characters that have special meaning in a URL, like spaces or &. There is also a 'URL-safe' Base64 variant that swaps + and / for - and _ so the result can sit in a URL without further escaping.