Hashing, encryption and encoding are three different things

One is reversible by design, one is reversible only with a key, and one is not reversible on purpose. Mixing them up is how secrets end up in plain sight.

Published 2026-06-17

One line each

The test that separates them: ask who can undo this, and what do they need? Anyone with no secret at all (encoding), nobody (hashing), or the key holder (encryption).

Encoding changes the representation of data so it survives some channel. Reversible by anyone, by design. No key involved.
Hashing maps input of any size to a fixed-size digest. Not reversible — there is no inverse function, only guessing.
Encryption transforms data so that only a holder of the key can transform it back. Reversible, but only with the key.

Encoding: reversible by design

Base64, percent-encoding and backslash escapes exist to move awkward bytes through channels that only accept certain characters. None of them protect anything — the Base64 tool decodes any Base64 you paste without a password, because that is the entire point. If you want the longer version, see what Base64 encoding actually is.

The same goes for HTTP Basic authentication: Authorization: Basic carries Base64 of user:password, which is encoding, not protection. It is safe only because TLS is protecting the whole request — over plain HTTP those credentials are effectively in the clear. Decode one with the Basic Auth Header tool and the point makes itself.

Hashing: one-way and fixed-size

A hash function chews any amount of input into a fixed-length digest — SHA-256 always produces 256 bits, whether you feed it one character or a gigabyte. Change a single bit of input and roughly half the output bits flip, which is why digests are useful as fingerprints. Try it in the Hash Generator: add one space and watch the whole digest change.

Because the output is fixed-size and the input is not, collisions must exist mathematically — the value of a good hash is that finding one is infeasible. That is precisely what broke SHA-1: collisions were demonstrated in 2017, so it is fine as a checksum for non-adversarial data and unfit for signatures or deduplicating anything an attacker controls. Prefer SHA-256 when the result has to mean something.

Encryption: reversible with a key

Encryption is the only one of the three that gives you confidentiality, and it is the one OmniWebTools deliberately does not offer — a browser tool cannot manage keys safely, and rolling your own is how data gets lost. Use a vetted library or your platform's keystore.

And to name the obvious near-miss: ROT13 and Caesar shifts are not encryption. The ROT / Caesar tool is there for puzzles and for spoiler text, not for secrets — the “key” is one of 25 possibilities and can be brute-forced by eye.

Where this goes wrong in practice

Storing passwords with SHA-256. Fast hashes are the wrong tool: a GPU tries billions per second. Password storage wants a deliberately slow, salted function — Argon2id, scrypt or bcrypt — never a bare SHA digest, and never an unsalted one.
Calling Base64 “encrypted”. It appears in incident reports more often than it should. If a reviewer cannot tell the difference, assume an attacker can.
Assuming a signed JWT is private. HMAC signing proves a token was not tampered with; it does nothing to hide the payload, which is plain Base64url. The JWT Signer will build one for you and the JWT Decoder will read anyone's back — so keep secrets out of claims.
Hashing to “anonymise” identifiers. A hash of an email address or a phone number is not anonymous: the input space is small enough to enumerate, so the digest is a pseudonym at best.

Picking the right one

Need it to travel through a text-only channel? Encoding.
Need to compare or fingerprint without storing the original? Hashing — SHA-256 for integrity, a slow salted KDF for passwords.
Need it kept secret from whoever holds the bytes? Encryption, with a library you did not write.
Need a value nobody has to reverse at all? Generate a fresh random one with the Password Generator instead of deriving it from something.