Encoding vs encryption

Encoding changes how data is represented so it survives a particular channel, and anyone can reverse it. Encryption hides data so that only someone holding the key can read it. Mistaking one for the other is a common source of leaked secrets.

Encoding: a change of representation

An encoding maps data to a different form so it can travel through a channel that would otherwise mangle it. Base64 turns arbitrary bytes into letters, digits and a few symbols so they fit in email, JSON or an HTTP header. Percent-encoding writes a space as %20 so it can sit inside a URL. HTML entities write < as < so a browser shows it instead of treating it as a tag.

Every one of these is public and keyless. The rules are published in standards, and the same function that encodes can be run backwards by anyone. That is the point: the receiver has to be able to decode without any prior arrangement.

Encryption: hiding data behind a key

Encryption, such as AES or ChaCha20, transforms data so that it can only be turned back into the original by someone holding the right key. Without the key, the output is designed to be indistinguishable from random bytes: no patterns, no recognizable structure, nothing that gives away what went in.

Because encrypted output is binary, it is often then encoded, usually as Base64, so it can be stored as text. That is why a Base64 string can hold something secret. The Base64 layer protects nothing; the encryption underneath does.

Where the two get confused

“It’s encoded, so it’s safe.” A JWT’s payload is only Base64URL-encoded. Anyone holding the token can read every claim in it, so it must never carry a password or other secret.
“Hashing is encryption.” A hash such as SHA-256 is a one-way fingerprint with no key and no way back, which makes it a third, separate thing.
“This tool can detect encryption.” It can’t, and nothing honest can. Encoded data has structure that gives it away; well-encrypted data has none by design. A tool that claims to recognize “AES ciphertext” is guessing.

Telling them apart in practice

If a value decodes to readable text or a known file type, it was only encoded. If it decodes to bytes with no visible structure, it may be encrypted, compressed, a random key or just noise, and the bytes alone cannot say which. The Vaultools Format Identifier follows exactly that rule: it recognizes encodings by their structure, and it says it doesn’t recognize a value rather than guess that it’s encrypted.

Base64 — Base64 is an encoding that represents any sequence of bytes using 64 printable text characters, so binary data can travel through systems built for text such as email, JSON, URLs and HTTP headers. It is not encryption, and it makes data about a third larger.
Percent-encoding — Percent-encoding, also called URL encoding, writes a character as a percent sign followed by the hexadecimal value of each of its UTF-8 bytes, such as %20 for a space, so text can be carried safely inside a URL. It is defined in RFC 3986.
HTML entity — An HTML entity, or character reference, is text like &, — or — that stands for a single character in HTML. It lets you write characters that would otherwise be read as markup, such as < and &, and characters that are hard to type or see.
JWT (JSON Web Token) — A JSON Web Token is a compact, URL-safe string that carries a set of claims as JSON, usually signed so the receiver can detect tampering. It is defined in RFC 7519 and is widely used for API and session authentication.
SHA-256 (Secure Hash Algorithm, 256-bit) — SHA-256 is a cryptographic hash function from the SHA-2 family that turns any input into a fixed 256-bit digest, usually written as 64 hexadecimal characters. The same input always gives the same output, and it is infeasible to work backwards from the digest.