Contact

Tools  /  Encoding  /  Base64 Encoder / Decoder

Base64 Encoder / Decoder

Encode and decode Base64. Handles emoji and accents correctly.

Why encoding emoji or accented text sometimes fails elsewhere

The plain JavaScript function most Base64 tools are built on, btoa, only understands one byte per character and throws an error the moment it sees anything outside that range — which includes emoji, most accented letters, and any non-Latin script. Text is converted to its real UTF-8 bytes first here, so "café ☕" or "🚀" encode correctly on the first try instead of throwing InvalidCharacterError or silently mangling the result.

Standard vs URL-safe, and missing padding

Two Base64 alphabets exist because the standard one uses + and /, both of which have their own meaning inside a URL. URL-safe Base64 swaps those for - and _ instead — the form used inside a JWT, for instance. Decoding auto-detects which alphabet is in use, and pads the input back out if the trailing = characters were stripped, which is common in contexts like JWTs that omit padding entirely.

The encoder and decoder side by side

Both directions run at once in separate panels rather than one shared box that has to be told which way to go each time. A swap button sends the encoder's output into the decoder's input and back, which is a quick way to confirm a round trip produces the original text exactly.

Privacy

Encoding and decoding both happen in your browser. Nothing you paste, drop, or load from a file is sent to a server.

Frequently asked questions

Is my data uploaded anywhere?
No. Encoding and decoding both run locally in the browser — nothing is sent to a server.
Why does encoding emoji or accented text sometimes fail on other tools?
The underlying btoa function in JavaScript only understands one byte per character and throws an error on anything outside that range, which includes emoji, most accented letters, and non-Latin scripts. Converting text to its real UTF-8 bytes first avoids that failure entirely.
What is the difference between standard and URL-safe Base64?
Standard Base64 uses + and / in its alphabet, both of which already mean something specific inside a URL. URL-safe Base64 replaces them with - and _ so the encoded text can sit directly in a URL or filename without needing further escaping.
Why would Base64 be missing its padding characters?
Some contexts, including JWTs, omit the trailing = padding characters entirely by convention. Decoding restores the expected padding automatically before decoding, so unpadded input still works.
Can I quickly check that encoding and decoding round-trip correctly?
Yes — the swap button sends the encoder's output into the decoder's input and vice versa, so a full round trip can be checked in one click instead of copying text back and forth manually.
Can I load a file instead of typing or pasting text?
Yes — either the encoder or decoder input can load a text file directly instead of pasting its content in by hand.
Theme Accent