Base64 Encode and Decode: How It Actually Works

Base64 exists because a lot of infrastructure was built for text and quietly mangles anything else. The classic case is email: SMTP was specified around 7-bit ASCII lines of limited length, so an attached JPEG — full of bytes above 127, null bytes, and no line structure at all — could not pass through as-is. The MIME standards solved this in the early 1990s by encoding attachments into a restricted alphabet that every mail relay on the path could carry without corruption. Every attachment you have ever emailed traveled as Base64.

The same pressure exists all over modern systems. JSON has no binary type, so an API that returns a generated invoice or a thumbnail inside a JSON body must encode it as a string. URLs can only carry a limited character set. HTML attributes, XML documents, environment variables, log lines, and clipboard buffers are all text channels. Whenever binary data has to cross one of these boundaries, something has to translate bytes into characters the channel treats as inert, and Base64 is the near-universal answer because it is simple, reversible, and reasonably compact.

It helps to place it against the alternatives. Hexadecimal is even simpler — two characters per byte — but doubles the size. Base64 costs only a third extra. Newer schemes like Base85 are denser still but use punctuation that breaks in URLs and quotes, which is exactly the fragility Base64 was designed to avoid. The 64-character alphabet is the sweet spot: dense enough to be practical, boring enough to survive any text pipe.

The mechanism is a straight re-grouping of bits. Base64 takes the input three bytes at a time — 24 bits — and slices those 24 bits into four groups of 6 bits each. A 6-bit number ranges from 0 to 63, and each value indexes into a fixed 64-character alphabet: A through Z for 0 to 25, a through z for 26 to 51, the digits 0 through 9 for 52 to 61, then plus for 62 and slash for 63. Three bytes of anything — pixels, machine code, emoji — become four characters from that list. This is why encoded output is always about 33 percent larger than the input: four characters carry what three bytes carried.

The trailing equals signs are padding, and they fall out of the same arithmetic. When the input length is not a multiple of three, the final group is short. One leftover byte gives 8 bits, enough for two Base64 characters, and the encoder appends two equals signs to pad the block to four; two leftover bytes give 16 bits, three characters, and one equals sign. So a Base64 string ends in ==, =, or nothing, and that tail tells you the original length modulo three. The padding carries no data — some decoders do not even require it, which is why you will meet unpadded strings in the wild.

Two variants matter in practice. Standard Base64 uses plus and slash, both of which are unsafe in URLs — plus decodes as a space in query strings and slash is a path separator. The URL-safe variant, defined in RFC 4648 as base64url, swaps them for hyphen and underscore and usually drops padding. JWTs use base64url exclusively, which is the single most common reason a token segment fails in a standard decoder. The MIME variant used in email additionally wraps output at 76 characters per line, which is why Base64 copied out of a raw email arrives full of line breaks. Decoding is the exact mirror: map each character back to its 6-bit value, glue the bits together, cut them into 8-bit bytes. One corrupted character therefore damages up to three bytes of output — and because the alphabet is case-sensitive, a lowercased Base64 string is not a cosmetic change but different data.

Base64 provides zero secrecy. There is no key, no secret, no computation to reverse — anyone with the string and any decoder has the data, full stop. It is a change of alphabet, like writing English in Morse code. This sounds obvious stated plainly, yet encoded-equals-safe thinking causes real leaks, because Base64 output looks scrambled to the eye and that visual noise gets mistaken for protection.

The classic examples are worth naming. An HTTP Basic Authentication header is just username:password run through Base64 — over plain HTTP that is a plaintext credential on the wire, which is precisely why Basic Auth is only acceptable over TLS. The header and payload of a JWT are base64url-encoded JSON, readable by anyone who holds the token; the signature stops tampering, not reading, so a JWT must never carry data its bearer should not see. Kubernetes stores Secrets as Base64 in etcd, and treating that as encryption at rest is a well-documented audit finding. API keys stuffed into Base64 blobs inside mobile apps or JavaScript bundles are recovered by anyone in minutes.

The flip side is genuinely useful: because decoding is free, Base64 is transparent for debugging. Pasting the middle segment of a JWT into a decoder to check its expiry claim, or decoding a webhook payload a vendor logged in encoded form, is a routine and legitimate move. Just keep the two ideas separate — encode to survive a text channel, encrypt to keep a secret — and reach for real cryptography when secrecy is the actual requirement.

Most Base64 work falls into a handful of recurring situations. These are the ones worth recognizing on sight:

Encoding an image as a data URI trades requests for bytes, and the trade only goes your way in narrow cases. The costs are concrete: the 33 percent size penalty, the loss of independent caching — the encoded image re-downloads with every copy of the stylesheet that contains it, and any change to it invalidates the whole file — and the loss of parallel loading, since the browser cannot fetch inlined data separately. On top of that, the old rationale has weakened: eliminating requests mattered most under HTTP/1.1, and HTTP/2 multiplexing made small extra requests much cheaper.

The cases where inlining still clearly wins: genuinely tiny assets, roughly under 2 KB, that belong to the styling itself — an arrow in a select control, a bullet, a hamburger icon; single-file deliverables such as an HTML email template, a standalone report, or an offline page where external references would break; and generated images that exist only in memory, like a chart a script just rendered, where writing a file to disk first is pure ceremony.

Skip inlining for photographs and anything above a few kilobytes, for images reused across pages where the cache would have earned its keep, and for anything a CDN should serve. One more practical note: SVG often inlines better URL-encoded than Base64-encoded, because SVG source is text that compresses well and stays diff-readable, whereas Base64 wraps it in opacity for no gain. For raster formats — PNG, JPEG, WebP — Base64 is the standard route.

Nearly every decode failure traces to one of a few causes, and you can usually diagnose by eye. Check the alphabet first: if the string contains hyphens or underscores, it is base64url — swap hyphen back to plus and underscore back to slash, or use a decoder that accepts the URL-safe variant, and it will decode. Check the length next: a standard Base64 string is a multiple of four characters; if strict decoding fails on a truncation error, append one or two equals signs to complete the final block. And strip whitespace: strings copied from emails, YAML files, or terminal output routinely pick up line breaks and indentation that strict decoders reject.

Two subtler failures are worth knowing. Double encoding happens when a value gets encoded twice — decode once and the output is another Base64 string rather than the expected data; just decode again. Character-set confusion happens after a successful decode: the bytes are correct, but they are UTF-8 text being displayed as Latin-1 or vice versa, so accented characters render as garbage pairs like a capital A with a tilde followed by a symbol. That is a text-decoding problem downstream of Base64, not a Base64 problem.

Finally, decoded binary pasted into a text box will always look like noise — that is what a PNG or a ZIP is supposed to look like as text. The first few bytes tell you what you have: a decoded PNG starts with a byte sequence that renders roughly as PNG in the first characters, a PDF starts with %PDF, a ZIP with PK. If you see those signatures, the decode worked and the data simply needs to be saved as a file rather than read as prose.