Base64 Encoder & Decoder

Encode and decode Base64 with correct UTF-8 and URL-safe handling.

Plain text
Base64
Send output to

Base64 without the Unicode bug

Base64 exists to move arbitrary bytes through a channel that only accepts text. Email attachments, data URIs, basic-auth headers, JWT segments and binary blobs stuffed into JSON all rely on it. It takes three bytes at a time and re-expresses them as four characters from a 64-symbol alphabet, which is why encoded output is always about a third larger than the input.

Why so many Base64 tools mangle emoji

The browser's built-in btoa only accepts characters in the Latin-1 range. Hand it an emoji, a Chinese character or even a curly apostrophe and it throws, or — worse, in tools that catch the error and press on — silently produces something that will not decode back to what you started with. This tool runs input through TextEncoder first, converting to UTF-8 bytes before encoding, so any Unicode text survives the round trip intact. Decoding reverses it with TextDecoder.

Standard versus URL-safe

The standard alphabet ends with + and /, and pads with =. All three are unsafe in a URL: + is read as a space in a query string, / is a path separator, and = separates a parameter from its value. RFC 4648 §5 defines a URL-safe variant that substitutes - and _ and drops the padding. That is the variant JSON Web Tokens use, which is why a JWT segment often fails to decode in a tool that only understands the standard alphabet. This one accepts both when decoding, automatically.

Base64 is not encryption

This is worth stating plainly because the mistake is common and expensive. Base64 is a reversible encoding with no key. Anyone who sees the string can decode it instantly — that is its entire purpose. Encoding a password, an API key or a token in Base64 provides exactly zero protection; it only makes the value non-obvious to a human skimming a file. If you need secrecy, you need encryption, and if you need integrity, you need a signature or a MAC.

Kubernetes Secrets are the canonical trap here: their values are Base64 encoded, which leads people to believe they are protected. They are stored encoded, not encrypted, unless you have explicitly enabled encryption at rest.

If you can decode it without a key, it was never a secret.

Decoding happens here, not on a server

Because Base64 is so often wrapped around credentials, pasting a token into a remote decoder hands it over in plain text. Everything on this page runs in your browser — a decoded bearer token never leaves the tab.

Questions people actually ask

Why do other Base64 tools mangle emoji and accents?
Because the browser's raw btoa only accepts Latin-1. This tool runs the text through TextEncoder first, so any Unicode input — emoji, CJK, accented characters — survives the round trip.
What is the URL-safe variant?
RFC 4648 §5 replaces + and / with - and _ and drops the padding, so the result can be dropped into a URL or a JWT segment without escaping.
Is Base64 encryption?
No. It is an encoding, not a cipher — anyone can decode it instantly. Never use it to protect a secret; use it to move bytes through a text-only channel.
navigate open esc close