The problem Base64 solves
Computers store everything as binary — sequences of 0s and 1s. When you need to transmit binary data through a channel designed only for text (like email, HTTP headers, or a JSON field), you have a problem: binary bytes include control characters and byte values that text protocols may interpret as commands, truncate, or corrupt.
Base64 solves this by representing arbitrary binary data using only 64 characters that are safe in any text context: A–Z, a–z, 0–9, plus (+), and slash (/), with equals (=) used for padding. Any binary data can be encoded into this safe character set and decoded back to the original bytes exactly.
How the encoding actually works
Base64 takes your input bytes in groups of three. Three bytes = 24 bits. It splits those 24 bits into four groups of 6 bits each. Each 6-bit group represents a number from 0 to 63, which maps to one character in the Base64 alphabet.
So every 3 input bytes become 4 output characters. This is why Base64 makes data roughly 33% larger — the encoding is 4/3 the size of the input. The padding character (=) is added at the end when the input isn't a multiple of 3 bytes.
This also means Base64 is not encryption. It's just a different representation of the same data. Anyone can decode Base64 — there's no key or secret involved.
Where Base64 appears in practice
Data URIs embed binary files directly in HTML or CSS without a separate file request: `<img src="data:image/png;base64,iVBOR...">`. This is useful for small icons in email templates and critical above-the-fold images where you want to avoid a network round-trip.
JWT tokens use Base64URL encoding (a slight variant that replaces + with - and / with _ for URL safety) to encode the header and payload sections. If you split a JWT at the dots and decode the first two parts from Base64, you can read the token's contents.
Email attachments — despite the modern web — still use MIME encoding with Base64 to attach binary files to plain-text email messages. The file is encoded to Base64 and embedded in the email body.
Basic Authentication HTTP headers encode `username:password` as Base64 in the Authorization header. This does not provide security on its own — the credentials can be trivially decoded. HTTPS is what provides the actual security.
Base64URL vs standard Base64
Standard Base64 uses + and / characters, which have special meanings in URLs. Base64URL replaces + with - and / with _, making the encoded output safe to include in URLs and filenames without percent-encoding.
If you're encoding something for a JWT token, a filename, or a URL parameter, use Base64URL. For embedding in HTML, email, or JSON, standard Base64 is fine.
Common misconceptions about Base64
Base64 is not compression. It makes data larger, not smaller. If you need to reduce size, compress first (with gzip or brotli) and then Base64-encode if necessary.
Base64 is not encryption. The encoded content is trivially reversible by anyone who knows it's Base64-encoded. Don't use it to obscure passwords or sensitive data.
Base64-encoded strings often end with one or two = padding characters. If your decoder rejects them or your encoder omits them, that's usually fine — the = characters are optional and many implementations accept Base64 without them.