What Is Base64 Encoding? A Plain-English Guide
Base64 is a way of writing any binary data — an image, a PDF, an encryption key — using only 64 safe, printable text characters. It exists because large parts of our infrastructure were built to carry text, not raw bytes, and it survives because those parts never went away. If you have ever seen a wall of characters like SGVsbG8gd29ybGQh in a URL, an email source or an API token, you have met it.
The problem it solves
Raw binary data uses all 256 possible byte values. Text-based channels do not tolerate all 256: email systems historically mangled anything outside 7-bit ASCII, JSON strings cannot contain arbitrary bytes, HTTP headers are text, and control characters like a null byte can terminate a string or break a protocol entirely. Base64 sidesteps all of this by re-expressing the bytes using characters that every text system agrees on: A–Z, a–z, 0–9, + and /. Sixty-four symbols, hence the name.
How it works: 3 bytes in, 4 characters out
The mechanism is pure regrouping. Three bytes are 24 bits. Base64 slices those 24 bits into four 6-bit chunks, and since 6 bits can hold values 0–63, each chunk indexes one character in the 64-character alphabet. So every 3 bytes of input become exactly 4 characters of output. When the input length isn’t a multiple of three, the final group is padded and the encoder appends one or two = signs — that trailing = you see on many Base64 strings is nothing more than “the last group was short.”
A worked example: encoding “Hi!”
The string Hi! is three bytes, so it encodes with no padding. Step by step:
Text: H i !
Bytes: 72 105 33
Bits: 01001000 01101001 00100001
Regroup 24 bits into four 6-bit chunks:
010010 000110 100100 100001
Decimal: 18 6 36 33
Alphabet: S G k h
Result: "Hi!" -> "SGkh"That is the entire algorithm: no keys, no secrets, no math beyond regrouping bits. Decoding runs the same table backwards. You can verify this in the Base64 Encoder/Decoder — type Hi! and watch SGkh appear.
Where you’ll meet it
Data URIs embed files directly in HTML or CSS: src="data:image/png;base64,iVBORw0K..." puts a whole image inside the markup. JWTs — the tokens behind most modern login sessions — are three Base64-encoded segments joined by dots; paste one into the JWT Decoder and the header and payload pop out as plain JSON. Email attachments ride inside MIME messages as Base64, which is why a raw email source looks like character soup. And HTTP Basic auth sends username:password Base64-encoded in the Authorization header.
Base64 is not encryption
This deserves its own section because it is the single most common — and most dangerous — misconception. Encoding and encryption answer different questions. Encoding asks “how do I represent this data so it survives the channel?” Encryption asks “how do I keep this data secret from anyone without the key?” Base64 has no key. Anyone who sees a Base64 string can decode it instantly, with one line of code or any online tool, because the “secret” — the alphabet table — is published in the spec.
That Basic auth header from the previous section? It is the password, readable by anything that sees the request, which is why Basic auth is only acceptable over HTTPS. The payload of a JWT? Readable by anyone holding the token — the signature stops tampering, not reading. If you find yourself Base64-encoding an API key “for security” before putting it in a config file or a URL, stop: you have obscured it from human eyes for roughly four seconds and protected it from exactly no one. Secrets need real encryption or a secrets manager.
The 33% tax, and when not to use Base64
Turning 3 bytes into 4 characters means Base64 output is always about 33% larger than the input — a 3 MB image becomes 4 MB of text. For small payloads that is a fine price for compatibility. For large ones it adds up: inlining big images as data URIs bloats your HTML, defeats browser caching (the “file” re-downloads with every page), and adds decode work. The rule of thumb: Base64 is for smuggling binary through a text-only channel, never for storage or for anything a plain URL and a normal binary transfer could serve. Databases have blob columns; HTTP carries binary natively; use them.
The base64url variant
Two characters of the standard alphabet are landmines in URLs: + means a space in query strings, and / is a path separator. The base64url variant (RFC 4648) swaps them — - replaces + and _ replaces / — and usually drops the = padding, which also needs escaping in URLs. JWTs use base64url, which is why a naive standard-Base64 decode of a token segment sometimes fails on a stray - or _. If a decoder rejects a string that looks like valid Base64, checking for these two characters is the first move.
The whole topic fits in one sentence: Base64 is a reversible, keyless re-spelling of bytes as text — enormously useful for transport, worthless for secrecy, and 33% bigger every time.