Base64 Encoder / Decoder

Base64 Encoder and Decoder

Base64 exists to move arbitrary bytes through channels that only tolerate text. Email bodies, JSON string fields, HTTP headers, data URIs in a stylesheet — all of them will mangle a raw 0x00 or a stray newline, and all of them are perfectly happy with sixty-five ASCII characters.

The three-to-four arithmetic

The encoder takes the input three bytes at a time. Three bytes are 24 bits; 24 bits split evenly into four 6-bit groups; each group indexes a 64-character alphabet of A-Z, a-z, 0-9, + and /. Four output characters for every three input bytes is where the roughly 33% size increase comes from, and it is why a data URI is always larger than the file it carries.

When the input length is not a multiple of three, the last group is padded and = characters mark how much padding was added. One = means the final group held two bytes, two = means it held one. The padding carries no data — it exists so a decoder knows where the real bytes stop.

Text goes in as UTF-8

This is where most quick implementations fall over. The browser's own btoa accepts only code points below 256 and throws on anything else, so a naive tool either crashes on café or, worse, silently truncates it. Encoding here runs the string through TextEncoder first, so what gets encoded is the UTF-8 byte sequence, and decoding runs the bytes back through TextDecoder.

The practical consequence is that emoji survive the round trip. 👍 is four UTF-8 bytes, encodes to 8J+RjQ==, and comes back as the same character. Accented Latin, Greek, Cyrillic, CJK and combining marks behave the same way. If a token you decoded elsewhere came out as é where you expected é, that is a UTF-8 sequence read as Latin-1 somewhere in the chain.

Standard alphabet or URL-safe

Tick URL-safe alphabet (RFC 4648) and the output uses - and _ in place of + and /, and drops the trailing =. Those three substitutions exist because + means a space in a query string, / is a path separator, and = separates a parameter from its value. Anything you plan to put in a URL, a filename or a JWT segment needs this variant.

The decoder does not need to be told. It accepts either alphabet, restores the missing padding itself, and strips whitespace, so a base64 blob that arrived wrapped at 76 columns in an email header decodes without any tidying first.

Files, data URIs and images

The file picker reads a local file and encodes it directly to a data URI, complete with its MIME type — useful for inlining a small icon in CSS rather than spending a request on it. Going the other way, paste a data URI and the data:image/png;base64, prefix is recognised and removed before decoding. When the result looks like image bytes the preview panel renders it, and the decoded file can be saved.

Keep inlining to genuinely small assets. A 200 KB PNG becomes roughly 267 KB of text that cannot be cached separately from the document that carries it.

It is an encoding, not a lock

Base64 provides no confidentiality whatsoever. The alphabet is public, the transform is reversible without a key, and any bystander can paste your string into this very page. Anyone treating a base64 string as an obscured secret has hidden nothing. If the content must stay private, encrypt it and then base64 the ciphertext for transport. The same logic applies to the middle segment of a token — see JWT Decoder, which reads a payload no one bothered to hide.

For query-string escaping rather than binary-safe transport, URL Encoder is the right tool; percent-encoding and Base64 solve related but different problems.

Encoding and decoding both happen inside this tab with no upload step of any kind. Whatever is in the editor is stored in sessionStorage until the tab closes, and "Clear it now" empties it immediately.