Base64 Encoding and Decoding: What It Is, and Why Most Tools Mangle Non-Latin Text

You come across a long run of letters and digits ending in one or two equals signs, and you recognise it as Base64. Then comes the real question: what is inside it, and why was it written that way at all? The common answer — "to hide it" — is flatly wrong, and that particular misunderstanding is behind a fair number of security incidents.

Base64 is encoding, not encryption

The distinction matters. Encryption needs a key to undo. Encoding is undone by anyone in a second with nothing at all. Base64 is firmly the second kind. It is simply a way of writing data — an image, a file, some text — using only 64 safe characters: upper and lower case English letters, digits, and two extra symbols.

It exists because many older systems and text-based protocols do not carry binary data safely. Some strip particular bytes, some interpret a byte as the end of a message. Convert your data into those 64 characters and it passes through any text channel intact.

If the plan is to put a password or a key in Base64 "so nobody sees it", any browser will undo that instantly. Encoding makes data transportable, not secret.

The cost: your data gets bigger

A practical point many people miss. Base64 represents every three bytes as four characters, so the output is about a third larger than the input. Encode a three-megabyte image to embed in a page and you are shipping roughly four megabytes. That makes embedding large images this way usually a poor trade, while it stays sensible for very small icons where inlining saves an entire network request.

The equals signs at the end are padding. Because the length has to be a multiple of four, one or two are added to round it out. Seeing them is completely normal and is not a sign of anything being wrong.

Why non-Latin text comes out broken

Here is the most annoying failure. Base64 works on bytes, not on characters. An Arabic letter in UTF-8 is not stored in one byte like an English letter — it takes two. An emoji can take four.

Plenty of tools, and some languages' built-in functions, assume one character equals one byte. They take a word like "مرحبا" and slice every letter in half. The result is either an outright error or — worse — a string that looks fine but decodes to question marks. Sahel's Base64 tool converts text to UTF-8 bytes first and encodes those, so Arabic and emoji come back exactly as you typed them.

Standard alphabet versus URL-safe

The standard alphabet uses + and / among its sixty-four characters. Both mean something else inside a URL: the slash separates path segments, and the plus is read as a space in some contexts. Put a standard Base64 string into a URL and it can arrive broken.

So there is a second variant that swaps + for a hyphen and / for an underscore, and usually drops the padding. It is the form you see in tokens such as JWTs. The tool supports both and lets you choose rather than assuming.

How to use it

1. Pick the direction: encode text to Base64, or decode a string back to text.
2. Pick the alphabet: standard for general use, URL-safe if the result is going into a link.
3. Paste your text or string.
4. Copy the result. If the string is invalid you get a message explaining why, rather than mangled output.

A realistic scenario

A developer receives an error from a third-party service with a field called details holding a long Base64 string. Pasting it into the tool reveals a JSON object carrying the actual error message and its code — information that was there the whole time, hidden behind one layer of encoding. They then drop the result into the JSON formatter to read it laid out properly. And if what they are holding is a token rather than plain text, the JWT decoder shows its contents directly with no manual steps.

Frequently asked questions

Does Base64 make a file smaller?

No, it makes it about a third larger. Anyone confusing it with compression is achieving the exact opposite of what they intended.

How can I tell whether a string is Base64?

The signs: letters and digits only with no spaces, a length that is a multiple of four, and possibly an equals sign at the end. Those are hints, not proof — the only way to be sure is to decode it and look at what comes out.

Is my data sent to a server?

No, the whole operation runs in your browser. That matters, because what gets encoded is so often credentials or internal content.

Why does decoding sometimes fail?

Usually because the string was copied incomplete, or because it uses the URL-safe alphabet while you are decoding it as standard, or because spaces and line breaks crept in during the copy. Try the other alphabet first.

Can I encode an entire file?

In principle yes, and that is exactly what happens with email attachments and data URIs. But for large files the string becomes enormous and heavy for a browser, and uploading the file as it is beats turning it into text.