Base64 shows up everywhere — data URIs, email attachments, JWT parts, API payloads — and yet it is widely misunderstood, sometimes in ways that cause real security mistakes. This guide explains what Base64 actually does, why it exists, and when it is the right tool versus when it is being misused.
The problem Base64 solves
Many channels were designed for text, not arbitrary binary data — email bodies, URLs, JSON string fields, HTML attributes. Sending raw bytes through them can corrupt the data. Base64 solves this by representing any binary data using only 64 safe ASCII characters (A–Z, a–z, 0–9, plus two symbols), which survive text-only transport intact.
How it works, briefly
Base64 takes three bytes (24 bits) at a time and splits them into four six-bit groups, each mapped to one of the 64 characters. Because three bytes become four characters, the output is about 33% larger than the input. When the data does not divide evenly into three, padding with = characters fills the gap.
The critical misconception
Base64 is NOT encryption and provides NO security whatsoever. Anyone can decode it instantly — that is the entire point. If you see a credential "hidden" in Base64, treat it as plaintext. Use Base64 for transport convenience, never to protect anything. When you need secrecy, you need encryption.
When to use it (and when not to)
Base64 is a good fit for embedding a small image as a data URI to save an HTTP request, encoding binary data inside JSON, or inspecting the parts of a JWT. It is a poor fit for large files, where the 33% size increase and loss of separate caching outweigh the convenience, and it is never a fit for hiding secrets.