Base64 Encode and Decode
Convert text to Base64 and back, with full Unicode support. Runs entirely in your browser.
This tool runs entirely in your browser. Nothing you enter is uploaded to a server.
This tool converts text to Base64 and Base64 back to text, in your browser. It encodes through UTF-8, so accented characters, emoji and non-Latin scripts survive the round trip intact, and it supports the URL-safe alphabet used in JSON Web Tokens and query strings. Nothing you paste is sent to a server.
How to use it
- Pick a directionChoose Text → Base64 to encode, or Base64 → Text to decode. You can switch at any time without losing what you typed.
- Paste your inputThe output updates as you type. If you are working with tokens or query-string values, tick URL-safe alphabet.
- Copy the resultCopy output puts the result on your clipboard, or use it as input to chain another conversion.
How Base64 works
Base64 takes your data three bytes at a time — twenty-four bits — and re-slices those bits into four groups of six. Each six-bit group has one of sixty-four possible values, and each value maps to one printable character: the uppercase letters, the lowercase letters, the digits, and two symbols. The result is text that can pass safely through systems that would mangle or reject raw binary.
The cost is size. Four characters out for every three bytes in means encoded data is about thirty-three percent larger than the original. That is why Base64 is used for small payloads — tokens, tiny images inlined as data URLs, email attachments — and avoided for large ones.
Unicode and why most encoders break
Browsers ship a built-in Base64 function called btoa, and almost every simple online encoder is a thin wrapper around it. It has a serious limitation: it only accepts characters in the Latin-1 range. Feed it "café" or any emoji and it throws an exception. Some tools catch that and silently mangle the character instead, which is worse.
This tool encodes your text to UTF-8 bytes first and Base64-encodes those bytes, which is what every modern system on the other end expects. Decoding reverses the process strictly, so invalid input produces a clear error rather than plausible-looking nonsense. Any text you can type — Sinhala, Arabic, Japanese, mathematical symbols, emoji — round-trips exactly.
Where you will run into it
JSON Web Tokens are three URL-safe Base64 segments joined by dots; decoding the middle one shows you the claims. HTTP Basic authentication sends username and password as a single Base64 string — which, again, is encoding and not protection, and is why it is only acceptable over HTTPS. Data URLs embed small images directly in CSS or HTML as Base64. Email attachments have been Base64-encoded since MIME was defined in 1992.
You will also meet it in configuration files, where binary certificates and keys are stored as Base64 text, and in webhook payloads that need to carry a signature or a small binary blob through a JSON field.
Privacy
Everything happens in your browser. The page is a static file with the conversion logic included; there is no backend, no request, and no log. Given how often the thing being decoded is a token or a credential, that is the whole reason this page exists rather than pointing you at one of the many server-based alternatives.
Frequently asked questions
What is Base64 actually for?
It represents arbitrary binary data using only 64 printable ASCII characters, so that data can travel through channels that expect text — email bodies, JSON fields, XML documents, data URLs, HTTP headers. It is an encoding, not encryption: anyone can decode it, and it provides no confidentiality whatsoever.
Is Base64 encryption?
No, and treating it as such is a common and serious mistake. Base64 is fully reversible by anyone with no key and no secret. Encoding a password or an API key in Base64 hides it from casual reading and from nothing else.
What is the URL-safe alphabet?
Standard Base64 uses + and / as its last two characters and = for padding. All three have special meaning in URLs, so RFC 4648 defines a variant that uses - and _ instead and usually omits the padding. JSON Web Tokens use this variant, which is why a JWT segment often fails to decode in a standard decoder.
Why does my output end in one or two equals signs?
Base64 encodes three bytes at a time into four characters. When the input length is not a multiple of three, the encoder pads the final group so it still comes out as four characters. One trailing = means the input had one byte left over in the last group; two means it had one byte, one over. It is normal and expected.
Can I encode a file or an image?
Not with this tool — it works on text. A file encoder is on the roadmap. For now, if you need a data URL for a small image, most browsers' developer tools can produce one.
Why does my decoded text look like garbage?
Most often the input was encoded from something other than UTF-8 text, or it is URL-safe Base64 being decoded with the standard alphabet. Try the URL-safe toggle first. If the source was genuinely binary — an image, a compressed archive — decoding it as text will never produce anything readable.
Is it safe to decode a JWT here?
The decoding happens entirely in your browser, so the token is not transmitted anywhere. That makes it materially safer than a server-based decoder. It remains good practice to treat any token you have handled outside its normal flow as one worth rotating.