Toolium

Base64 Encoder / Decoder

Encode or decode Base64 strings instantly

100% client-sideFree, no signup

Base64, facet by facet

Base64 is how you push arbitrary binary through a text-only channel: data URLs, basic-auth headers, email attachments, JWT parts. It reads three bytes at a time, 24 bits, and regroups them as four characters of six bits each. The tool encodes and decodes text, handling UTF-8 so non-English input survives the trip.

Why the output grows by a third

Every three input bytes become four output characters, plus one or two padding marks when the input length is not a multiple of three. The overhead sits near four-thirds no matter the content, which is the price of using only printable characters.

The btoa and atob trap

The browser's built-in btoa throws on characters outside Latin-1, because it only handles single-byte values, and an emoji or a CJK character needs more than one. The tool runs the text through TextEncoder to UTF-8 bytes first, then base64-encodes those bytes, so emoji and CJK characters round-trip cleanly.

base64 versus base64url

The URL-safe variant swaps the plus and slash for a dash and an underscore and drops the padding, so it survives inside URLs and filenames where plus and slash carry meaning. JWT segments use base64url. This decoder expects the standard alphabet, so swap the dash back to a plus and the underscore back to a slash before pasting base64url input, or it rejects the string.

What it is not

Base64 is an alphabet shift, not encryption. Anyone can decode it without a key, so it hides nothing. To protect a secret, encrypt it first and base64 the ciphertext only to move it safely as text.

Common questions

Can I base64-encode a file?
This tool takes text input. Pasting a text file's contents works; a truly binary file like an image or an executable needs a file-to-base64 tool that reads binary uploads.
Why does my decoded text have strange characters?
The source was probably encoded as Latin-1 or another single-byte set, not UTF-8. The decoder assumes UTF-8, so bytes above 127 come out mangled, and the base64 alone carries no clue about the original encoding.
Is the padding equals sign required?
Standard base64 pads to a multiple of four with equals signs. Many decoders, including this one, tolerate missing padding, but keep it when a strict parser is on the other end.