What happens when the payload is not text?

The bytes are decoded, then run through a strict UTF-8 decoder. If that rejects them, the tool tells you the payload is binary and offers the raw bytes as a decoded.bin download rather than printing replacement characters. That is the normal outcome for an image, a key file or a zip.

Why does the data: URI still use + and / when I picked URL-safe?

Because a data: URI is parsed as standard Base64 and would break otherwise. The URL-safe alphabet applies to the raw Base64 shown above it, which is where you would paste it into a token or a filename.

Base64 Encoder

No upload · runs in your browser

Alphabet

Line breaks

Text or Base64

0 characters

Result

Runs entirely in your browser, nothing is uploaded.

File to Base64

Any file up to 25 MB. Read locally, never uploaded.

How it works

Base64 encoder and decoder that handles UTF-8 and files

Encode and decode Base64 with real UTF-8 handling and an optional URL-safe alphabet. Files up to 25 MB become raw Base64 or a data: URI.

What this does

Text is UTF-8 encoded before btoa sees it, so emoji and accents survive the round trip
The URL-safe alphabet swaps + and / for - and _ and drops the = padding
Optional wrapping at 76 columns for MIME bodies and email headers
The decoder takes either alphabet with or without padding, and ignores line breaks
A file up to 25 MB gives you the raw Base64 next to a ready-to-paste data: URI
A payload that is not valid UTF-8 is offered as a .bin download instead of mangled text

FAQ

Because btoa() only accepts code points up to U+00FF, so anything above that either throws or is silently mangled. This tool runs the text through TextEncoder first, so btoa only ever sees bytes, which is what every server-side library does. The catch is the other end: whatever decodes the string has to read those bytes back as UTF-8. Decode them as Latin-1 instead and “München” comes back as “MÃ¼nchen”, with the accented letter split into two.

Keep going