Base64 Encoder Decoder

How it actually works

Encoding runs on the browser's own Base64 primitives, with a UTF-8 step in front of them: the text is turned into percent-escaped bytes and then handed to btoa(), so characters above U+007F survive instead of throwing the InvalidCharacterError that a raw btoa() call raises. Decoding walks the same path backwards through atob(), which is why emojis, Arabic, Urdu, CJK and accented Latin all come out of the round trip identical to what you pasted in.

Nothing is uploaded. Encode and Decode are two radio states on one screen, and the output area is rebuilt the moment you switch, so the same text can be inspected in both directions without retyping. Character counts for input and output sit in the stats bar, the copy button writes the result to your clipboard, and a fallback path is there for browsers that block the async clipboard API on an insecure origin.

What that means for your results

Round-trip fidelity is the property that matters here and it is exact: any string you encode returns character for character, because the intermediate representation is bytes rather than the browser's internal UTF-16. Try it with a mixed string such as <h1>Ünïcödé 你好 🚀</h1> and the decoded output still carries every mark.

Base64 is an encoding, not a protection. Anyone who has the string can reverse it with no key and no password, and that is true whether you produced it here or in a server library. Use it to move binary or non-ASCII data through a channel that only accepts plain text, never to hide anything; if the payload must be unreadable, it has to be encrypted before it is encoded.

Because every three bytes become four characters, expect output about a third longer than the input. That inflation is the whole cost of the format and it is why Base64 payloads in emails and JSON bodies push transfer sizes up rather than down.

Where it falls short — honestly

The tool takes text you paste or type. There is no file picker: to convert an actual image you would need its bytes in a data: URI, which is a job for a developer console or a purpose-built converter rather than this field.

The standard alphabet is produced and accepted, with = padding. Files and APIs that use the URL-safe variant (- and _ instead of + and /) will not decode cleanly until those characters are swapped back, and input containing spaces, newlines or non-Base64 punctuation is reported as invalid rather than repaired.

A real end-to-end workflow

The everyday use is stuffing binary or Unicode content into a text-only slot: an icon inside a CSS background image, an avatar in a JSON API payload, a template string in a config file that must stay plain ASCII. Paste, encode, copy the result into the source, and check the byte order mark is not doubled.

The other direction is debugging. When an API response, a cookie or a token fragment looks like gibberish, paste it into Decode and see whether it is UTF-8 text, JSON to hand to JSON Validator, or something binary that this tool was never meant to display. For similar byte-level inspection there is Binary to Text and Hex to Text; for escaping markup rather than encoding bytes, use HTML Escape/Unescape.