Base64 Encoder and Decoder

Base64 is not encryption

This is the single most common misunderstanding about Base64, and it matters. Encoding scrambles nothing and protects nothing — anyone who sees the output can paste it into this page and read your text in a second. There is no key and no secret. If you need something to stay private, you need encryption; Base64 only changes the alphabet the data is written in.

What Base64 is actually for

Plenty of systems were built to carry text and only text. Email bodies, JSON string values, XML attributes, CSS files, HTTP headers — none of them can hold arbitrary bytes safely. A raw byte might be a null, a newline, or a quote character that terminates the field early and corrupts everything after it.

Base64 solves that by re-expressing arbitrary bytes using 64 characters that survive any text channel: A–Z, a–z, 0–9, plus two symbols. Every three bytes of input become four of those characters. The result travels safely, and the receiver converts it back to the original bytes.

That is why you see it in email attachments, in `data:` URIs that embed a small image directly in HTML or CSS, in JSON Web Tokens, and in API responses that need to return a file inside a text field.

It makes data about a third larger

Every three bytes become four characters, so the output is roughly 33% bigger than the input. That is the price of the guarantee, and it is unavoidable.

For non-Latin text the effect compounds, which surprises people. An English letter is one byte in UTF-8, so it produces about 1.3 Base64 characters. A Thai character is three bytes, so it produces about four. The same number of characters of Thai yields roughly three times the Base64 that English does — the byte counter above the input box shows what is really being encoded.

This is worth knowing before you embed a large image as a `data:` URI. A 100 KB image becomes about 133 KB of text inside your HTML, which is downloaded on every page load and cannot be cached separately.

When to use the URL-safe alphabet

Standard Base64 uses `+` and `/` as its final two characters. Both cause problems in a URL. In a query string, `+` is decoded as a space, so your data silently changes. And `/` is a path separator, so it breaks anything that reads the URL structurally.

The URL-safe variant swaps them for `-` and `_`, which have no special meaning in either position. Tick the box if the result is going into a URL, a filename, or anything else that treats those characters as syntax. Decoding accepts both alphabets automatically, so you never have to know which one you were given.

Padding is a related nuisance. The trailing `=` characters exist so the length is always a multiple of four, but `=` also has meaning in query strings. Dropping it is safe — the length still determines how many bytes came out — and this tool decodes padded and unpadded input alike.

Common questions

Is my text sent anywhere?

No. The conversion runs in your browser using JavaScript that was downloaded with the page. There is no server involved, which you can verify by disconnecting from the internet after the page loads — the tool keeps working.

Why does decoding say the result is binary, not text?

Because it genuinely is. Base64 can carry any bytes at all, including images, PDFs and compressed archives. If those bytes are not valid UTF-8 text, there is no sensible string to display, so the tool tells you rather than showing you a screen of replacement characters that looks like a bug.

Can I safely put a password in Base64?

No, and it is worth being blunt: encoded credentials are plaintext credentials. HTTP Basic authentication sends the username and password as Base64, which is exactly why it must only ever be used over HTTPS. The encoding contributes nothing to security.

Why does my Base64 have equals signs at the end?

That is padding. Base64 works in groups of four characters representing three bytes, so when the input length is not a multiple of three, one or two `=` characters fill the last group. They carry no data. You can remove them with the "No padding" option and the result still decodes correctly.

Does it handle Thai and emoji?

Yes. Text is converted to UTF-8 bytes before encoding, so any Unicode works — Thai, Chinese, Arabic, and emoji including multi-part sequences like flags and family emoji. Many Base64 tools use the browser’s older function directly, which fails outright on anything beyond Latin-1.

Is Base64 the same as encryption or hashing?

No, and the three are worth keeping straight. Base64 is reversible by anyone and protects nothing. Hashing is one-way and cannot be reversed at all. Encryption is reversible only with a key. If you want a checksum, use the hash generator instead.