Skip to main content

Base64 Encoding Explained: Real Use Cases, Hidden Pitfalls, and When to Skip It

A practical guide to base64 encoding — what it actually does to your bytes, where it genuinely helps, and the three situations where you should reach for something else entirely.

Published
#base64 #encoding #web-development #security #data-transfer

Base64 Encoding Explained: Real Use Cases, Hidden Pitfalls, and When to Skip It

Base64 encoding is one of those techniques that developers reach for almost reflexively — paste some binary data into a text field, run it through base64, done. But "it works" and "it's the right call" are not the same thing. This guide walks through what base64 actually does at the byte level, where it genuinely earns its place, and three concrete situations where using it makes your system measurably worse.

What Base64 Actually Does to Your Data

Base64 converts arbitrary binary data into a 64-character alphabet: uppercase A–Z, lowercase a–z, digits 0–9, plus + and / (with = for padding). Every 3 bytes of input become 4 ASCII characters of output.

That math has an immediate consequence: base64 inflates the size of your data by approximately 33%. A 300 KB image becomes ~400 KB after encoding. A 1 MB binary becomes ~1.37 MB. The RFC 4648 specification documents this ratio precisely — 3 input bytes always yield 4 output characters, with up to 2 padding characters when the input length isn't divisible by 3.

Here's a concrete example. The 11-byte ASCII string Hello World encodes as follows:

Input bytes (hex): 48 65 6C 6C 6F 20 57 6F 72 6C 64
Base64 output:     SGVsbG8gV29ybGQ=

You can verify this instantly with the Base64 Encoder on Toolora. Paste Hello World, hit encode, and you get SGVsbG8gV29ybGQ= — 16 characters for 11 bytes, consistent with the 4/3 ratio (11 × 4/3 = 14.67, rounded up to 16 with padding).

The "64" in base64 is not arbitrary. These 64 printable ASCII characters are safe to transmit through virtually every text-based system built in the last 50 years — email (which SMTP historically mangled binary), XML attributes, JSON strings, HTML data: URIs, and HTTP headers. That portability is the entire point.

Where Base64 Genuinely Earns Its Place

Embedding small images in HTML/CSS. A 2 KB icon encoded as a base64 data: URI saves an HTTP round trip. Google's own Page Speed recommendations acknowledge this trade-off: the 33% size penalty is often worth eliminating latency for tiny assets below ~5 KB. Above that threshold, the equation flips.

Email attachments and MIME multipart. SMTP was designed for 7-bit ASCII text. Binary files — PDFs, images, executables — can't travel through old mail relays unchanged. Base64 encoding in MIME (RFC 2045) is the standard solution, and every email client in the world knows how to handle it.

Embedding binary data in JSON payloads. JSON has no native binary type. When an API needs to return file content, a cryptographic signature, or a public key inside a JSON response body, base64 is the standard approach. The Stripe API, for example, uses base64 to encode binary webhook signatures so they can live in HTTP headers.

JWT tokens. JSON Web Tokens use base64url (a slight variant that replaces + with - and / with _ and omits padding) to encode the header, payload, and signature. If you work with JWTs, the Base64URL Encoder/Decoder for JWT-safe strings is worth bookmarking — it handles the alphabet difference automatically, which is the part that trips up most people writing custom JWT parsers.

Three Situations Where You Should Not Use Base64

1. Storing passwords or secrets. I've encountered this in legacy codebases more times than I'd like: a password hashed, then base64-encoded "for extra security." Base64 is not encryption. It is not hashing. It is fully reversible by anyone, with zero key material required. Encoding letmein gives bGV0bWVpbg==; decoding bGV0bWVpbg== gives letmein. Every security scanner flags this immediately because it is, at best, security theater.

2. Compressing files before transmission. This is a compounding mistake. If you compress a file (which produces near-random bytes with high entropy) and then base64-encode it, the resulting string is ~33% larger than the compressed binary — and the random-looking content compresses poorly if you try to gzip it afterward. The correct order, if you need both, is: compress, then transmit the raw binary without encoding. Or compress and encode if binary transmission is not available, accepting the size cost.

3. Storing large binary files in a database column. Encoding a 50 MB video as base64 and storing the resulting 67 MB string in a TEXT column achieves nothing good. You pay the 33% size penalty, lose the ability to stream the data efficiently, and often hit column size limits. The right answer is blob storage (S3, GCS, Azure Blob) with a URL reference in the database.

The Hex Alternative and When It Applies

Base64 isn't the only encoding for binary-to-text conversion. Hexadecimal encoding — representing each byte as two hex digits — is common for checksums, cryptographic hashes, and debugging output. Hex is 100% larger than the original (2 chars per byte vs. base64's 1.33 chars per byte), but it's far more readable: deadbeef is instantly recognizable to a developer, while its base64 equivalent 3q2+7w== communicates nothing.

When you need to convert between the two representations, the Base64 to Hex converter handles both directions. I use this regularly when comparing a signature value returned by an API in base64 against a hex-formatted value from a CLI tool — they're the same bytes, just written differently.

Reading Base64 Output Without a Tool

When I first started debugging JWT tokens in production, I didn't always have a tool handy. It's useful to know that base64 output has a few quick tells:

  • Strings ending in == had 1 byte in the last group (2 padding characters)
  • Strings ending in = had 2 bytes in the last group (1 padding character)
  • Strings with no = padding had a byte count evenly divisible by 3
  • Base64url tokens (JWTs, OAuth codes) use - and _ instead of + and /, and typically omit padding entirely

The first segment of a JWT header, for example, is always eyJ — that's the base64 encoding of {" (open brace, double quote), which begins every valid JWT header JSON object. Recognizing that pattern tells you immediately that a string is a JWT.

A Quick Decision Framework

Use base64 when:

  • You need binary data to survive transit through a text-only channel (email, JSON, XML)
  • You're embedding a small binary asset inline to save an HTTP round trip
  • A protocol or standard explicitly calls for it (JWTs, MIME, AWS Signature v4)

Skip base64 when:

  • You're dealing with secrets or passwords — use a proper hash or encrypt
  • You're optimizing for storage size — binary is always smaller
  • The receiving system can handle binary data natively — don't encode what doesn't need encoding

Base64 is a transport primitive, not a general-purpose tool. Understanding that boundary makes it easy to reach for it when it's the right call — and recognize when something else fits better.

Made by Toolora · Updated 2026-06-29