Base64 is encoding, not encryption

Q: Is Base64 encrypted?

No. It is a public alphabet. Decoding does not require a secret.

Q: Why does my JWT look like Base64?

The header and payload are Base64url-encoded JSON. The signature is separate and is not encryption of those parts.

Sumit Jha · Updated 2026-11-06

Encoding maps bytes to a safer alphabet so a transport can carry them. Decoding is the inverse map and needs no key. If you can decode a value with a public tool, it was not encrypted. Use Base64 for embedding, percent-encoding for URL components, and real cryptography when you need confidentiality.

Open Base64 Encode / Decode

What Base64 actually changes

Base64 takes three bytes and writes four ASCII characters from a 64-character alphabet, with = as padding. Base64url swaps + and / for - and _ so the string can sit in a URL or a JWT without extra escaping. The information is the same. A token that looks opaque is often just Base64 of JSON, which is why JWT payloads are readable.

A data URL is the same idea with a prefix: data:image/png;base64, followed by the bytes. It is convenient for a tiny icon and a bad idea for a large photo, because the text is about a third larger than the file and it lands in your HTML or CSS.

hello  →  aGVsbG8=
aGVsbG8=  →  hello

Percent-encoding and HTML entities are the same class of mistake

Percent-encoding (URL encoding) replaces a space with %20 so a query value survives. Encode a component, not a full URL that is already encoded, or you will turn %20 into %2520. HTML entities turn < into < so a browser shows the character instead of starting a tag. That is a text-context escape, not a sanitizer for attributes, URLs, or JavaScript strings.

Hex encoding is also reversible. A hash is not. If you can turn the string back into the original with a decode button, you did not hash it and you did not encrypt it.

When you actually need a key

Confidentiality needs encryption, and authentication of a message needs a MAC or a signature. HMAC uses a secret and does not hide the message. bcrypt stores a password check, not a reversible encoding. If the goal is “only the server can read this,” Base64 is the wrong tool even though the output looks scrambled.

A round trip that should worry you if it fails, and not if it succeeds

Encode the word hello. You get aGVsbG8=. Decode it and you get hello. Anyone else with the same string gets the same word. That success is the property of an encoding. If a teammate calls this encryption because the characters look random, show them the round trip with no key field on the page. There is nothing to withhold.

The practical failures are alphabet and padding, not secrecy. Standard Base64 uses + and / and pads with =. Base64url uses - and _ and often drops the padding. A JWT middle segment will not decode on a strict standard decoder until you swap the alphabet and restore padding. Binary files need the byte path, not a UTF-8 text box that replaces invalid sequences. An image data URL that “decodes” to mojibake was pasted as text.

URL encoding has a similar trap. Encoding a full URL that already contains %20 produces %2520, and the server sees a literal percent. Encode the component you are adding. HTML entities belong in text nodes. They do not make an attribute or a URL safe. If the threat is “someone else should not be able to read this,” stop and pick a cipher.

People reach for Base64 because the output is ASCII and looks unrelated to the input. That is a transport property. Email attachments, data URLs, and JWT segments all needed a way to put bytes into a text channel. None of them needed the bytes to be secret. If you must both carry the bytes and keep them secret, encrypt first and then Base64 the ciphertext so the transport can hold it. Reversing that order, encoding and then hoping the alphabet is obscure, is the mistake this page is about. The decoder on DevTooKit has no key field because a key would be a lie.

FAQ

Is Base64 encrypted?