Base64 Encode and Decode
Encode text to Base64 and decode it back, with full support for any language.
Free forever, no sign-up and no limits, and this tool installs on its own so you can keep it on your home screen.
Paste text or Base64 and the tool picks the right direction on its own, encoding through UTF-8 so accented characters, emoji and non-Latin scripts survive intact. It reads URL-safe and unpadded Base64 without being told, encodes whole files to Base64 or a data URI, and previews decoded images.
How to use it
- Paste either formAuto detects whether you pasted plain text or Base64 and converts the right way, with a note saying which it chose. The direction buttons override it.
- Adjust the outputTick URL-safe output for tokens and query strings, or drop a file on the tool to encode it whole, as raw Base64 or a data URI.
- 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.
Questions people ask
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. When decoding, this tool recognises both alphabets on its own, padded or not.
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?
Yes. Drop a file on the tool, or tap the drop area to choose one, and it becomes Base64 or a complete data URI ready to paste into CSS or HTML. Keep it under 20 MB: Base64 is a third larger than the original, and very large text makes any page sluggish.
How does the automatic detection decide?
Input counts as Base64 only when it uses the Base64 alphabet, has a length that padding can complete, and decodes to readable text or a recognisable image. Anything else is treated as plain text to encode. The note under the input says which way it went, and the direction buttons override it.
Why does my decoded text look like garbage, or refuse to decode?
Most often the input was never text to begin with. If the decoded bytes are a PNG, JPEG, GIF or WebP image, the tool shows the image itself, with its dimensions. Genuinely binary data such as an archive or a certificate has no readable text form, and the tool reports that rather than printing noise.
Is it safe to decode a JWT here?
It will show you the payload, but a JWT is worth opening properly: our JWT decoder next door splits the header from the claims and turns the expiry into a real date. Remember that Base64 is not encryption either way, so reading a token proves nothing about whether it is genuine, and treat any credential handled outside its normal flow as one worth rotating.