Toolora

What is Base64?

What those long strings ending in "==" actually are, where they belong, and why they are not a way to hide anything.

Base64 is a way of writing any data — a picture, a PDF, a Thai sentence — using only 64 plain text characters. It exists because a lot of the internet still runs on channels that were built to carry text and nothing else.

If you have seen a string like 4Liq4Lin4Lix4Liq4LiU4Li1 and wondered what it was, that is Base64. It says สวัสดี.

The thing people get wrong

Base64 is not encryption. It hides nothing.

This matters enough to say before anything else, because it is the single most common misuse. Base64 has no key and no secret. Anyone who sees the string can decode it in a second — you can paste it into the decoder right now and read it.

So never use it to protect a password, an API key, or anything else that should stay private. Putting a token in Base64 before sending it is not security; it is the same token wearing a hat.

The confusion is understandable — Base64 output looks scrambled. But scrambled-looking and secret are different things. Base64 is a format, in the same family as writing a number in hexadecimal.

How to spot it

Base64 uses exactly 64 characters: A–Z, a–z, 0–9, plus + and /. The output length is always a multiple of four, and short inputs get padded with = at the end.

That trailing = or == is the strongest visual giveaway. If you see a long alphanumeric blob ending in =, it is almost certainly Base64.

Why it exists

Some systems can only handle plain text safely. Email is the classic case: the protocols were designed decades ago for 7-bit text, and raw binary sent through them gets mangled. So attaching a photo to an email means converting it to text first, sending it, and converting it back.

The same problem appears anywhere binary has to travel inside something text-shaped:

Where you meet it What is happening
Email attachments The file is Base64 inside the message body (MIME)
data:image/png;base64,… in CSS or HTML A small image embedded directly in the file
Binary inside a JSON payload JSON has no binary type, so bytes become a string
JWT tokens Each of the three dot-separated parts is Base64url

That last one deserves a warning. A JWT payload is Base64, not encrypted. Anyone holding the token can read every claim inside it — user ID, email, roles. The signature stops the token being modified, not read. Do not put anything confidential in one.

It costs about a third more space

Base64 packs every 3 bytes of input into 4 characters of output. That ratio is fixed, so encoded data is always roughly 33% larger than what went in.

That is the reason embedding large images as data URIs in CSS is usually a bad trade. A 100 KB image becomes about 133 KB of text, it cannot be cached separately from the stylesheet, and the browser has to decode it before it can paint. For an icon of a few hundred bytes the round trip you save is worth it. For a photograph it is not.

Thai text produces much longer output

This surprises people, and it is worth understanding because it is not a bug.

Base64 works on bytes, not characters. In UTF-8, an English letter is 1 byte, but a Thai character is 3. So the same visible length of text produces very different output:

Input Characters Bytes Base64 length
hello 5 5 8
สวัสดี 6 18 24

Six Thai characters cost three times what six English ones would. If you are encoding Thai content into a URL or a QR code, expect it to be roughly three times longer than the English equivalent — and for QR codes specifically, that means a denser code.

URL-safe Base64

Standard Base64 uses + and /, and both cause trouble in a URL. / is a path separator, and + means a space in query strings — so a Base64 value pasted into a URL can arrive corrupted.

URL-safe Base64 fixes this by swapping two characters:

  • + becomes -
  • / becomes _

Nothing else changes, and padding is often dropped as well. This is the variant JWTs use. If you are putting Base64 in a link, a query parameter, or a filename, use the URL-safe option — the encoder here has a checkbox for it.

So when should you use it?

Yes: when binary data has to pass through something that only accepts text, and you have no better option.

No: to hide anything, to compress anything (it does the opposite), or to embed large files in a stylesheet.

Most of the time you are not choosing Base64 at all — you are just decoding something that already arrived that way, trying to work out what it says.