← Back to Blog

What Is Base64 Encoding? When and Why You Should Use It

March 25, 2026 · 6 min read

You've probably seen Base64 without knowing it. That long string of seemingly random letters in an email source. The data:image/png;base64,... block in a CSS file. The garbled middle section of a JWT. All Base64-encoded data. So what is Base64, and why does it exist?

The Problem Base64 Solves

Many protocols and data formats were designed to carry text, not arbitrary binary data. SMTP (email), JSON, XML, HTML attributes, URL query strings: they all expect printable ASCII characters. If you try to shove raw binary bytes (a JPEG image, a TLS certificate) directly into an email body, certain bytes get interpreted as control characters and the data gets mangled in transit.

Base64 fixes that. It takes any sequence of bytes and re-encodes it using 64 "safe" ASCII characters: A-Z, a-z, 0-9, +, and /, plus = for padding. The output is a text string that survives any text-only channel intact.

How Base64 Works, Step by Step

The encoding process is straightforward:

  1. Take 3 bytes (24 bits) of input data.
  2. Split them into 4 groups of 6 bits. Each group has a value from 0 to 63.
  3. Map each value to a character in the Base64 alphabet. Value 0 = A, value 25 = Z, value 26 = a, value 51 = z, value 52 = 0, value 62 = +, value 63 = /.
  4. If the input isn't a multiple of 3 bytes, pad the output with = characters. One leftover byte produces two Base64 characters plus ==. Two leftover bytes produce three characters plus =.

I find it helps to trace through a short example. Take the string "Hi" (two bytes: 0x48 0x69):

Binary:  01001000 01101001
Grouped: 010010 000110 1001xx
Values:  18     6      36 (padded)
Base64:  S      G      k=

Result:  "SGk="

Decoding is the exact reverse: map characters back to 6-bit values, concatenate, and extract the original bytes.

Where Base64 Shows Up in Practice

Email Attachments (MIME)

When you attach a PDF to an email, your mail client Base64-encodes the file and embeds it in the MIME body with a Content-Transfer-Encoding: base64 header. The recipient's client decodes it. This has been the standard approach since RFC 2045 in 1996.

Data URIs in HTML and CSS

Small images and fonts can be inlined directly into HTML or CSS to save an HTTP request:

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

Works well for icons under a few KB. For larger images it's counterproductive, since Base64 adds 33% overhead and defeats browser caching.

JSON Web Tokens (JWT)

A JWT is three Base64url-encoded segments separated by dots. The header and payload are JSON objects; the third segment is the signature. Base64url replaces + with - and / with _ to make the token URL-safe. More on that in the JWT deep dive.

API Payloads

APIs that accept file uploads via JSON often require the file to be Base64-encoded, since JSON can't carry raw binary. GitHub's Contents API is a typical example: you send file content as a Base64 string.

Certificates and Keys

PEM-encoded certificates (the ones starting with -----BEGIN CERTIFICATE-----) wrap Base64-encoded DER binary data. SSH public keys and PGP keys use the same approach.

Base64 Is NOT Encryption

This deserves its own heading because I still see people get it wrong. Base64 provides zero security. It's a reversible encoding, not encryption. Anyone can decode a Base64 string without a key. Don't use Base64 to "protect" passwords, tokens, or sensitive data. If you need confidentiality, use actual encryption (AES-256-GCM, ChaCha20-Poly1305). If you need to verify integrity, use a cryptographic hash function.

The 33% Size Overhead

Because 3 input bytes become 4 output characters, Base64 inflates data by about 33%. A 1 MB image becomes ~1.33 MB as Base64 text. For small payloads like icons or short certificates, that's fine. For large files, just use binary protocols: HTTP multipart, gRPC streams, or a plain file upload endpoint.

Variants of Base64

There are a few variants you'll run into. Standard Base64 (RFC 4648) uses the alphabet A-Za-z0-9+/ with = padding. Base64url swaps + for - and / for _, which makes it safe for URLs, JWTs, and filenames. MIME Base64 (RFC 2045) uses the standard alphabet but inserts line breaks every 76 characters for email compatibility.

Need to encode or decode a Base64 string? Supports standard and URL-safe variants, runs entirely in your browser.

Base64 Encoder/Decoder

Quick Reference: Base64 in Code

# Python
import base64
encoded = base64.b64encode(b"Hello").decode()  # "SGVsbG8="
decoded = base64.b64decode("SGVsbG8=")         # b"Hello"

// JavaScript (browser)
btoa("Hello")     // "SGVsbG8="
atob("SGVsbG8=")  // "Hello"

// Node.js
Buffer.from("Hello").toString("base64")           // "SGVsbG8="
Buffer.from("SGVsbG8=", "base64").toString()      // "Hello"

Frequently Asked Questions

Is Base64 encryption?

No. Base64 is an encoding scheme, not encryption. It is fully reversible by anyone without a key. It provides zero security. If you need to protect data, use encryption (AES, ChaCha20) or hashing (SHA-256). Base64 is only for encoding binary data into a text-safe format.

Why does Base64 make data about 33% larger?

Base64 represents every 3 bytes of input as 4 ASCII characters. Each character uses 6 bits of information but takes up 8 bits in the encoded output. The ratio 4/3 = 1.333, meaning a ~33% size increase. Padding characters (=) may add a few extra bytes at the end.

When should I use Base64 encoding?

Use Base64 when you need to embed binary data (images, files, certificates) inside a text-only context: JSON payloads, HTML data URIs, email attachments (MIME), XML documents, or environment variables. Avoid it when you can transmit binary data directly, since Base64 adds a 33% size overhead.