Base64 Encoder & Decoder

How the Base64 Encoder / Decoder works

Base64 encoder: getting a good result

Base64 takes arbitrary bytes and rewrites them using 64 characters that survive being pasted into places that were only ever designed to carry plain text — email headers, JSON strings, XML attributes, a URL. That is the whole job. It is a transport format, and understanding what it does not do is more useful than understanding what it does.

Base64 is not encryption. This is the one that costs people real money. Anything encoded here can be decoded by anyone, instantly, with no key, using this page. A password, an API token or a customer record encoded into Base64 is exactly as exposed as it was before — it is simply less obviously readable at a glance, which is worse than plaintext because it looks like it has been protected. The Authorization: Basic header is Base64 for framing reasons only; it is safe over HTTPS and completely open over HTTP. If you need secrecy you need encryption, and Base64 is the thing you often apply after encrypting, so the ciphertext can be pasted somewhere.

It always makes things bigger, by about a third. Three bytes of input become four characters of output, because each output character carries six bits rather than eight. That is a fixed 4:3 ratio, so 3 MB of data becomes 4 MB of Base64, plus padding. This is why inlining images as data: URIs is a trade rather than a win — you save an HTTP request and pay 33% more bytes on the wire, before compression claws some of it back. The trailing = characters are padding that rounds the output to a multiple of four; one = means the input ended one byte short of a group of three, two = means two bytes short.

There is more than one alphabet. Standard Base64 uses + and / for its last two characters, and both mean something else inside a URL — + is read as a space in a query string and / splits the path. The URL-safe variant substitutes - and _, and usually drops the padding as well, because = also needs escaping. JWTs use exactly this variant, which is why a token pasted into a standard decoder often fails on the last few characters. The decoder above accepts either alphabet and re-adds missing padding, so you do not have to work out which one you have.

Unicode needs a step that older tools skip. The browser's own btoa only accepts characters below 256 and throws on anything else, which is why so many decoders mangle accented text and emoji. This tool converts text to UTF-8 bytes first and decodes them back the same way, so café, Москва and 🙂 all round-trip exactly.

Related tools