Base64 Explained: What It Is, When to Use It, and When Not To

You've seen Base64 a thousand times — that long string ending in an equals sign sitting inside an API response, an email attachment, or a data URL. Base64 is an encoding scheme that represents binary data using only 64 safe ASCII characters (A–Z, a–z, 0–9, +, /), with = used as padding.

Why it exists

Many transport layers were designed for text, not raw bytes. Email, JSON, XML, and URLs choke on binary data — null bytes, control characters, and non-ASCII values can be mangled, truncated, or misinterpreted. Encoding binary as Base64 guarantees it survives the round trip untouched.

• Email attachments (MIME) rely on Base64 to carry files.
• JSON APIs embed images and files as Base64 strings.
• Data URLs let you inline small assets directly in HTML.
• Basic auth sends credentials as Base64 (note: plaintext-ish — see below).

Encode and decode in seconds

ForgePlug's Base64 Encoder & Decoder handles both directions with smart auto-detection: paste plain text and it encodes, paste an encoded string and it decodes. Unicode, emoji, and multiline text survive the round trip, and file uploads let you encode any binary payload. Optional hex and binary previews show exactly what the encoding produces — useful when you're debugging why a payload looks the way it does.

How the encoding actually works

The mechanism is simple arithmetic. Three bytes of input are 24 bits; those 24 bits are re-sliced into four groups of six, and each 6-bit group indexes into the 64-character alphabet. Three bytes in, four characters out — which is exactly where the 33% size increase comes from.

Padding exists because input length is not always a multiple of three. If one byte remains, it produces two characters followed by two equals signs; if two bytes remain, three characters and one equals sign. This is why you can often tell something about a Base64 string's length just by looking at its tail, and why a stray trailing equals sign is normal rather than a sign of corruption.

Base64url: the variant that trips people up

Standard Base64 uses + and / as its last two characters, and both have special meaning in URLs — + is interpreted as a space in query strings and / is a path separator. So a URL-safe variant substitutes - for + and _ for /, and usually strips the padding entirely. This is what JWTs use for all three of their segments.

The practical consequence: a JWT segment pasted into a standard Base64 decoder frequently fails, because the decoder does not recognise - and _ and objects to the missing padding. Either use a decoder that auto-detects the variant, or convert the characters back and re-add equals signs until the length is a multiple of four. A decode failure here almost always means variant mismatch rather than a corrupted token.

The line-break rule nobody expects

Base64 as used in email (MIME) is wrapped at 76 characters per line, and PEM-format certificates and keys wrap at 64. Those line breaks are part of the transport convention, not the data — but strict decoders reject whitespace outright, which is why copying a certificate body or an email attachment payload into a decoder sometimes fails for no visible reason. Stripping newlines before decoding resolves it.

The catch: size

Base64 inflates data by roughly 33% because every three bytes of input become four characters of output. That's fine for small payloads like tokens and thumbnails, but it's the wrong tool for bulk data — prefer multipart uploads or binary bodies when size matters.

There is a second cost that is easy to miss: Base64 compresses poorly. Gzip and Brotli work on byte patterns, and spreading binary data across a restricted 64-character alphabet destroys much of the structure they would otherwise exploit. A Base64-encoded image inside a JSON payload typically ends up meaningfully larger after compression than the same image sent as raw bytes, so the 33% overhead understates the real transfer cost.

The same reasoning applies to data URLs in CSS and HTML. Inlining a small icon saves a request and is often worth it; inlining a large image is usually a net loss, because the bytes now sit inside a render-blocking stylesheet, cannot be cached independently, and must be re-downloaded whenever that file changes. As a rough guide, inlining stays sensible for assets of a few kilobytes and stops being sensible well before you reach a full photograph.