How Base64 encoding works — and when NOT to use it

Base64 is encoding, not encryption. It maps arbitrary bytes to a limited alphabet of 64 printable ASCII characters so binary data can survive channels that only tolerate text — email bodies (MIME), JSON fields, XML, URLs (often Base64URL), and HTML data: URIs. Understanding the mechanics explains the ~33% size overhead — and why Base64 is the wrong tool whenever you need secrecy or optimal bandwidth.

How Base64 works

Input bytes are treated as a continuous stream of bits. Those bits are sliced into groups of six bits (64 possible values per group). Each sextet indexes a symbol from the alphabet A–Z, a–z, 0–9, then typically + and / for the standard alphabet (MIME / PEM). Three bytes (24 bits) become four Base64 characters with no waste.

When the bit length is not divisible by 24, the final quantum is padded so the encoder always outputs full groups of four characters. Padding uses = (one or two equals signs) so decoders know how many trailing bits were insignificant. That padding is why you sometimes see == at the end of a string.

Base64 vs Base64URL

In URLs, + and / are awkward without escaping. Base64URL replaces + → -, / → _, and usually omits padding. JWTs use Base64URL for header and payload segments — same math, URL-safe alphabet.

When Base64 is the right tool

• Embedding small binaries in text formats — icons or thumbnails as data:image/png;base64,... in HTML or CSS.
• Carrying binary inside JSON or XML — certificate PEM bodies, protobuf in JSON, attachment blobs.
• SMTP and MIME — historical email attachments before binary transports were universal.
• Checksums and fingerprints as text — hex is fine too; Base64 is shorter than hex for the same bytes but not human-sortable.

When NOT to use Base64

• Never call it “encryption.” Anyone can decode Base64 instantly — there is no key. If you need confidentiality, use real cryptography (for example TLS for transport, AES-256-GCM for payload protection at rest). Confusing encoding with encryption leads to leaked passwords and compliance failures.
• Large payloads without compression first. Base64 expands size by roughly one third. Encoding gigabytes of raw binary into JSON is slow, cache-unfriendly, and expensive at the edge. Compress or use dedicated blob storage with signed URLs instead.
• Secrets you hope to “hide” in URLs or logs. Obfuscation is not protection. Tokens in query strings end up in referrer headers, analytics, and server logs — Base64 does not change that risk profile.
• When hex or plain UTF-8 would work. If you already have text, encoding again wastes bytes and CPU.

Quick mental model

Treat Base64 like turning binary into a fax-friendly alphabet: reversible, universal, and visible to everyone. Use it where the transport demands text; use cryptography where the data demands privacy.