Base64 Isn't Encryption (and Other Things People Get Wrong About It)
A string of random-looking letters and numbers ending in "==" has a way of looking secure. It isn't. Base64 has nothing to do with secrecy — here's what it actually does, and what to reach for when you genuinely need to hide something.
The CalcLake Team
Built alongside the calculators themselves
It's an easy mistake to make: you see a blob of text like "U2VjcmV0IG1lc3NhZ2U9" sitting in a config file, a URL, or an API payload, and it looks encrypted — dense, unreadable, official. It isn't. It's Base64, and anyone with an internet connection can decode it back to plain text in about two seconds, with no password, no key, and no special tools required.
What Base64 is actually solving
Base64 exists to solve a completely different problem than secrecy: how do you safely represent arbitrary binary data — images, files, encrypted blobs — using only the roughly 64 printable characters that text-based systems (email, URLs, JSON, XML) can reliably carry without corrupting? Base64 takes any input and re-encodes it into a safe alphabet of A–Z, a–z, 0–9, +, and /, padded with = at the end. That's the entire job: transport safety, not confidentiality.
Decoding it takes no secret at all
Because Base64 is a public, standardized, reversible mapping — not a cipher — decoding it requires zero secret information. The "algorithm" and the "key" are the same publicly known lookup table for every Base64 implementation on Earth. This is the single fact that trips people up: something can look obfuscated to the human eye while being completely transparent to a computer, or to anyone who pastes it into a decoder.
Try the tool
Decode a Base64 string yourself in seconds
Where Base64 legitimately shows up
None of this makes Base64 useless — quite the opposite, it's genuinely everywhere for good reason. Email attachments are Base64-encoded so binary files survive text-only mail transport. Images get embedded directly into HTML or CSS as Base64 data URIs. And JSON Web Tokens (JWTs) — the things that look like three dot-separated blobs of gibberish — have a header and payload that are just Base64url-encoded JSON, not encrypted at all. Anyone can paste a JWT into a decoder and read the payload in plain text.
A JWT's signature proves the payload wasn't tampered with. It does nothing to hide what's inside — and it was never designed to.
What to reach for when you actually need secrecy or integrity
The confusion usually comes from three different tools all producing similarly "random-looking" text output, despite doing completely unrelated jobs. It's worth keeping them straight:
- Base64 encoding: reversible, no key, zero confidentiality. Use it purely to make binary data safe to transport as text — never to hide anything from anyone.
- Hashing (MD5, SHA-256, etc.): one-way and not reversible at all, used to verify data hasn't changed or to store password checks — not to store or retrieve the original data, since there's no way back.
- Actual encryption (AES and similar): reversible on purpose, but only with a secret key. This is the only one of the three that's genuinely designed to keep contents hidden from anyone who doesn't hold the key.
Try the tool
See what a real one-way hash looks like
If your goal is genuinely to hide something, Base64 was never in the running — it was solving a transport problem that happens to produce output that looks secretive by accident. Knowing the difference is the kind of thing that's obvious once you see it and a little embarrassing the first time you don't.