It’s one of the most common misconceptions in software: someone sees a string like cGFzc3dvcmQ= and assumes the data is “encrypted.” It isn’t. Base64 is encoding, not encryption — and confusing the two can lead to real security mistakes. Let’s clear it up.
Here is the proof, not the assertion. Take the standard sample JSON Web Token from the JWT documentation and paste it into our JWT decoder. Without supplying any key, it immediately prints:
{ "alg": "HS256", "typ": "JWT" } { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }That token’s payload is Base64url, and Base64 is a transport encoding with a public alphabet — no secret is involved, so anything encoded that way is readable by anyone who bothers. The signature is the only part that needs a key, and it protects against tampering, not against reading. Never put anything confidential in a Base64 string and call it protected.
What Base64 actually does
Base64 takes arbitrary bytes and represents them using 64 printable characters (A–Z, a–z, 0–9, +, /). Its purpose is transport: it lets you carry binary data or special characters through channels that only handle text — email bodies, JSON fields, data URIs, JWT segments, and so on.
Crucially, Base64 uses no key and no secret. Anyone can decode it back to the original in a fraction of a second. Try it: paste cGFzc3dvcmQ= into the Base64 tool and you’ll instantly get back password.
Here is the claim as output. Each row went through our own Base64 encoder; paste any of the right-hand values back into the same page, switch to decode, and the left-hand column comes back exactly. No key is involved at any point — there is nowhere to put one.
| Input | Base64 |
|---|---|
secret | c2VjcmV0 |
admin:password | YWRtaW46cGFzc3dvcmQ= |
{"role":"admin"} | eyJyb2xlIjoiYWRtaW4ifQ== |
Hello, World! | SGVsbG8sIFdvcmxkIQ== |
Encoding vs. encryption
| Encoding (Base64) | Encryption | |
|---|---|---|
| Goal | Make data safe to transport | Make data unreadable to others |
| Key/secret | None | Yes — a key is required |
| Reversible by anyone? | Yes, trivially | No, only with the key |
| Provides confidentiality? | ❌ No | ✅ Yes |
Encoding is about representation. Encryption is about secrecy. They solve completely different problems.
The second row is not a contrived example. HTTP Basic authentication sends exactly that: admin:password becomes YWRtaW46cGFzc3dvcmQ=, and the header reads Authorization: Basic YWRtaW46cGFzc3dvcmQ=. Anyone who can see the request can read the password, which is why Basic auth is only acceptable over TLS — the transport provides the secrecy, the encoding provides none. The third row is the same mistake in a different costume: eyJyb2xlIjoiYWRtaW4ifQ== looks opaque and decodes to {"role":"admin"} in one step, so a value like that in a cookie is a permission the user can grant themselves.
A related concept: hashing
People also confuse Base64 with hashing. Hashing (like SHA-256) is a one-way function — you cannot recover the original from the output — and it’s used for integrity checks and password storage, not transport. If you want to experiment, our hash generator shows how the same input always produces the same fixed-length fingerprint.
So there are three distinct ideas:
- Encoding (Base64): reversible by anyone, for transport.
- Hashing (SHA-256): one-way, for integrity.
- Encryption (AES, RSA…): reversible only with a key, for secrecy.
The security mistake to avoid
Never use Base64 to “hide” a password, API key, or any sensitive value. Because it’s trivially reversible, Base64-encoding a secret provides zero protection. If you need confidentiality, use real encryption (for example, TLS in transit and AES at rest) and store credentials properly.
A useful test for whether something is encryption: ask what would have to be secret. With c2VjcmV0 nothing is — the algorithm is public, the alphabet is public, and there is no key parameter to protect. Encryption without a secret is not encryption; it is a different spelling of the same data.
When Base64 is the right tool
Base64 is perfect when you legitimately need to move binary or special data through a text channel:
- Embedding a small image as a data URI in HTML or CSS.
- Inspecting or assembling the segments of a JWT.
- Passing binary content through a JSON API.
- Putting special characters safely into a value.
Use it for what it’s built for — representation — and reach for encryption when you need secrecy. You can encode and decode text (with full UTF-8 support) using our free, browser-based Base64 tool.