What Is Base64 Encoding? (And When to Use It)

Base64 is one of those technologies most people use a hundred times a day without realizing it. It's how email attachments get transmitted, how images get embedded in HTML, how API tokens get carried in headers, how SSH keys get stored in text files. Despite being everywhere, the core idea is simple: take any binary data, represent it as ASCII text using only characters that survive every system in between.

The problem Base64 solves

Computers handle binary data natively — sequences of bytes, each one of 256 possible values (0x00 to 0xFF). Some systems don't, though. Email was originally designed for plain ASCII text. URLs can't contain certain characters. Some databases reject non-printable bytes. Most config file formats expect human-readable text.

If you have binary data (an image, a key, a serialized object) and need to put it into one of these text-only systems, you can't just paste the raw bytes — they'll get corrupted, truncated, or rejected.

Base64 is the workaround: encode the binary into a sequence of ASCII characters that can survive any text-based system. The recipient decodes it back to the original binary.

How Base64 works (the actual algorithm)

Base64 takes 3 bytes of binary input (24 bits total) and represents them as 4 ASCII characters from a 64-character alphabet. The alphabet is A-Z (26 characters), a-z (26 characters), 0-9 (10 characters), and two extras (+ and /), totaling 64. Each character represents 6 bits (since 2^6 = 64), so 4 characters cover 24 bits.

When the input length isn't a multiple of 3 bytes, Base64 pads the output with = characters so the length is always a multiple of 4. This is why Base64 strings often end with = or ==.

The trade-off: Base64 output is about 33% larger than the input. 100 bytes of binary becomes ~133 bytes of Base64 text. This is the price you pay for ASCII-safety.

Where Base64 shows up

Email attachments (MIME)

Every email attachment is Base64-encoded. The email body looks like:

Content-Type: image/png
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR4nGNgYAAAAAMAASsJTYQAAAAASUVORK5CYII=

That's a 1×1 black PNG, Base64-encoded. The full image is ~95 bytes; the Base64 representation is ~140 bytes.

Data URLs in HTML

You can embed a small image directly in HTML/CSS using a data URL:

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

The browser decodes the Base64, gets the image bytes, and renders it. Useful for inlining tiny images (icons, fonts) to avoid an extra HTTP request, at the cost of bigger HTML files.

Basic auth

HTTP Basic authentication encodes username + password as Base64:

Authorization: Basic dXNlcjpwYXNz

That's user:pass Base64-encoded. (Don't use Basic auth without HTTPS — Base64 isn't encryption, just encoding.)

JSON Web Tokens (JWT)

A JWT is three Base64-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.signature

Each segment is JSON Base64-encoded. Decoding the segments shows the token's claims and signature.

SSH and PGP keys

Public keys are stored as Base64 because they need to be copy-pasted into config files, emails, and version control:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@host

The AAAAB3... part is Base64 of the actual binary key.

Base64 vs. URL-safe Base64

The standard Base64 alphabet uses + and / for two of its characters. These are problematic in URLs (they get percent-encoded, breaking length expectations). URL-safe Base64 swaps them out:

• + → -
• / → _
• = padding is often omitted

You'll see URL-safe Base64 in JWTs, OAuth tokens, and anywhere binary data needs to fit in a URL.

Encoding and decoding in your browser

Base64 Encode/Decode handles both directions in your browser, with proper UTF-8 support. Type or paste:

• Encode mode: input is plain text, output is Base64.
• Decode mode: input is Base64, output is plain text.

The tool handles emoji and non-ASCII characters correctly (a common gotcha — the naive btoa() / atob() JavaScript functions don't handle Unicode).

Common gotchas

Why does my Base64 of an emoji look weird? Naive Base64 encoding of UTF-8 strings can produce wrong results because JavaScript's btoa() operates on Latin-1 byte values. Use the encode-decode-via-URI-component trick (btoa(unescape(encodeURIComponent(text)))) or a proper Base64 library that's UTF-8 aware. Dropvert's encoder handles this correctly.

Is Base64 secure? No. Base64 is encoding, not encryption. Anyone can decode it. Don't use Base64 for password storage, secret keys, or anything that needs to be private. Use it only when you need binary data to survive a text-only system.

Why is my Base64 string longer than expected? Base64 encoding adds ~33% overhead. Plus padding (= chars). Plus newlines if you used MIME-style encoding (which wraps lines at 76 characters). Total can be ~36-40% larger than the binary input.

What if my Base64 has spaces or newlines in it? Some Base64 variants (MIME) wrap output at 76 characters with newlines. The decoder usually ignores whitespace, but if not, strip newlines before decoding.

Are there any practical alternatives? Base32 (uses 32 characters, slightly larger output but case-insensitive — useful for human-typed codes), Base85 (denser, used in PDFs), hex encoding (simpler but 100% larger). Base64 is the most common because it hits a good balance between density and ASCII-safety.