Encode text to Base64 or decode it back. Unlike many browser tools, this handles Unicode properly - accented characters, Arabic, emoji and CJK all survive the round trip intact.
Base64 Encoder & Decoder
LiveHow it works
Base64 represents binary data using 64 printable characters - A-Z, a-z, 0-9, plus + and /, with = as padding. It takes three bytes of input (24 bits) and rewrites them as four characters of six bits each. That's the whole mechanism, and it explains the one property people find surprising: Base64 output is about 33% larger than the input, because you're spending four characters to carry three bytes.
Why Unicode breaks most Base64 tools
The browser's built-in btoa() function only accepts characters in the Latin-1 range. Feed it an emoji, an Arabic letter, or a Chinese character and it throws an error - or, in tools that catch the error badly, silently produces mangled output.
The correct approach is to convert the text to UTF-8 bytes first, then Base64-encode those bytes. This tool does that, which is why the default example round-trips cleanly. If you've ever decoded something and got question marks or replacement characters back, an encoder that skipped this step is usually the reason.
What Base64 is actually for
- Embedding small files in code - a tiny icon as a data URI inside CSS or HTML, avoiding an extra network request.
- Email attachments - the MIME standard uses it, because older mail infrastructure only reliably handled plain text.
- Passing data through text-only channels - API tokens, JSON payloads inside URLs, config values in environment variables.
- Basic HTTP authentication - credentials are Base64-encoded in the header, which is exactly why that scheme requires HTTPS.
Common mistakes
+ and / characters have meaning in URLs and will be mangled. URLs need the base64url variant, which substitutes - and _ instead.= signs. They're padding that tells the decoder how many bytes the final group holds. Some implementations tolerate their absence; many don't, and the failure is often silent truncation rather than an error.Frequently asked questions
Is Base64 secure?
No, and it was never intended to be. It's a way of representing binary data as text so it can pass through systems that only handle text. Decoding requires no key and no effort. Anything genuinely sensitive needs encryption, and putting it in Base64 first adds nothing.
Is anything I paste here uploaded?
No. The encoding and decoding both happen in JavaScript inside your own browser - there's no request to any server, and nothing is stored. You can verify this by disconnecting from the internet after the page loads; the tool keeps working.
Why does my decoded text come out as gibberish?
Usually one of three things: the input isn't actually Base64, it was encoded by a tool that mishandled Unicode, or it's base64url (using - and _) rather than standard Base64. Replacing - with + and _ with / often fixes the third case.
Can I Base64 a whole file here?
This tool handles text. Encoding a binary file - an image or PDF - needs the file read as bytes rather than pasted as text, which is a different operation. Pasting the raw contents of a binary file into a text box will not produce a valid result.
What's the difference between Base64 and base64url?
They encode identically but use different characters for two of the 64 symbols. Standard Base64 uses + and /; base64url swaps them for - and _ so the result is safe inside a URL or filename. JSON Web Tokens use base64url, which is why pasting a JWT segment into a standard decoder sometimes fails.
Does Base64 compress data?
The opposite - it makes data roughly a third larger. It's a transport format, not a compression format. If size matters, compress first and then Base64 the compressed result, never the other way round.
Related tools
See the full list of Generators, or try: