Toolrack

Base64 Encoder & Decoder

Works offlineNothing is uploadedFree, no sign-up

PEM blocks, email attachments and openssl without -A all expect wrapped lines

Everything is encoded locally. Files are read with FileReader and never uploaded.

Encode and decode Base64, with correct UTF-8 handling for any language. Also converts any file into a Base64 data URI ready to paste into HTML or CSS.

How Base64 works

Base64 takes three bytes — 24 bits — and re-splits them into four groups of six bits. Each 6-bit group indexes into a 64-character alphabet of A–Z, a–z, 0–9, plus and slash. When the input length is not a multiple of three, the output is padded with one or two equals signs, which is why so much Base64 ends in = or ==.

The URL-safe variant swaps plus and slash for hyphen and underscore, because those two characters have their own meaning inside a URL and would otherwise need percent-encoding on top of the Base64.

The UTF-8 step people miss

The browser's btoa() only accepts characters in the range 0–255, so btoa("Ünsiyyət") throws an exception — the ə is U+0259, well past the ceiling. The fix is to convert text to UTF-8 bytes first, then Base64-encode those bytes. This tool does that, which is why non-Latin text round-trips correctly here and breaks in simpler implementations.

The same step is why the growth figure above is reported in bytes. Three bytes always become four characters, but a character is not a byte: in UTF-8 a Cyrillic letter is two bytes and a CJK character is three, so counting characters would make the same encoding look several times more expensive than it is.

Frequently asked questions

Is Base64 encryption?

No, and treating it as such is a genuine security mistake. Base64 is an encoding — anyone can decode it instantly with no key, which is exactly what this page does. It exists to move binary data safely through channels that only accept text, not to hide anything.

Why does the encoded text get bigger?

Base64 represents every three bytes as four ASCII characters, so output is about 33 percent larger than the input in bytes, plus padding. Note that this is measured in bytes, not characters: a Japanese character is three UTF-8 bytes, so seven characters of Japanese become 28 Base64 characters — a fourfold rise in character count and the usual third in bytes.

Does this handle non-English text correctly?

Yes. Text is encoded as UTF-8 first, then Base64. This matters because the browser's built-in btoa function throws an error on any character above code point 255, which is every accented Latin character, and all Cyrillic, Arabic, Chinese and emoji.

When should I use a data URI instead of a file?

For small assets that would otherwise cost an extra network request — an icon under a few kilobytes, or a font subset. Above roughly 5 KB the size penalty outweighs the saved request, and because data URIs are inlined into the file that references them, they cannot be cached separately.

Related tools