Encoding, hashing and encryption, sorted out
Eighteen tools for the things people mix up daily — encoding versus encryption, which hash belongs on a password, and what an HMAC is actually for. Everything runs in your browser, so nothing you paste is uploaded.
The short answer
Encoding, hashing and encryption are three different things. Encoding (Base64) is reversible by anyone and provides no security — it exists to move binary data through text-only channels. Hashing is one-way: use SHA-256 for integrity, and bcrypt or Argon2 — never MD5 or SHA — for passwords, because password hashes must be deliberately slow. Encryption (AES) is two-way and needs a key. If you're asking which to use to 'hide' something, the answer is encryption; Base64 is not hiding anything.
Encode & decode
move data through text-only channelsBase64 turns arbitrary bytes into safe ASCII so they survive email headers, JSON payloads and data URIs. It's a transport format, not a security measure — anyone can reverse it in one click, including this one.
Hash for integrity
did these bytes change?A hash is a one-way fingerprint: same input, same digest, and no way back. Use it to verify a download matches its published checksum or that a payload wasn't altered in transit.
Hash for passwords
a different job entirelyPassword hashing has the opposite requirement to integrity hashing: it must be SLOW, and salted per user. bcrypt and Argon2 are built for it. SHA and MD5 are not, no matter how many times they're used for it.
Sign & encrypt
authenticity and confidentialitySigning proves a message came from someone holding the key and wasn't tampered with. Encrypting makes it unreadable without the key. They're separate goals and separate tools — you often want both.
Passwords for humans
generate and sanity-checkLength beats complexity: a long passphrase resists guessing far better than a short string with punctuation swapped in. Generate them rather than inventing them, because people are predictable and generators aren't.
Classic ciphers
for puzzles and courseworkThese are here for CTFs, homework and curiosity. They were breakable by hand centuries ago and are trivially broken now — never reach for one to protect anything real.
Encoding is not encryption
This is the single most expensive confusion in the list, and it shows up in production code constantly: a Base64 string looks scrambled, so it gets treated as though it were protected.
It isn't. Base64 is a public, keyless, fully reversible mapping from bytes to a 64-character alphabet. There is no secret involved. Anyone who can see the string can paste it into Base64 Decode and read it — no key, no cracking, no effort. Its actual purpose is transport: getting binary data safely through channels that only tolerate text, like an HTTP header, a JSON field, or a CSS data URI via SVG to Base64 Encode.
- 1Base64-ing a secret before storing it
This adds no protection whatsoever, and it's worse than plaintext in one way: it looks protected, so it stops getting reviewed. If it needs to be secret at rest, encrypt it.
- 2Calling Base64 'encryption' in a security review
The credentials in a Basic Auth header are Base64, not encrypted — that's why Basic Auth is only acceptable over HTTPS. The transport provides the confidentiality; the encoding provides none.
Which hash for which job
Hashes divide into two families with genuinely opposite design goals, and using one where the other belongs is how password databases end up cracked in bulk.
Integrity hashes are built to be FAST. You want to fingerprint a large file quickly with File Hash Calculator and compare it to a published checksum. SHA-256 via SHA Hash Generator is the sane default. MD5 still appears in the wild for this — MD5 Hash Generator exists because you'll be handed MD5 checksums to verify — but it's been broken for collision resistance since 2004, so never accept it as proof that a file wasn't deliberately tampered with.
Password hashes are built to be SLOW, and that slowness is the entire feature. An attacker with a leaked database tries billions of guesses; a hash that takes a quarter of a second instead of a nanosecond makes that economically hopeless. Bcrypt Hash Generator and Argon2 Hash Generator are designed for exactly this, and both salt each password so identical passwords don't produce identical hashes.
- Scenario
- A leaked table of 1,000,000 unsalted SHA-256 password hashes
- Attack
- Commodity GPUs test SHA-256 candidates at billions per second
- Unsalted
- One pass cracks EVERY matching password at once — the work is shared
- bcrypt instead
- Tuned to ~250ms per guess, and salted, so no work is shared
- Result
- The same wordlist that took minutes now takes an infeasible amount of time
Check what a given cost factor buys you with Password Hash Crack Time Estimator — the right setting is the slowest one your login endpoint can tolerate.
Signing proves who, encrypting hides what
These get conflated because both involve a key, but they answer different questions.
An HMAC answers 'did the person holding this secret produce this exact message?'. It's a hash mixed with a key, and it's what webhook providers use to sign payloads — see HMAC Generator. Critically, an HMAC does not hide the message: the payload travels in the clear alongside its signature. That's fine, because the goal was authenticity, not confidentiality.
Encryption answers 'can anyone read this without the key?'. AES Encryption/Decryption gives you the real thing, two-way and key-dependent. And a JWT sits in a confusing middle: it's signed, not encrypted, so anyone can read its claims — JWT Decoder does exactly that — while only the key holder can forge one. If you need a token whose contents are secret, a plain JWT is the wrong tool.
Passwords: length beats punctuation
The old advice — one uppercase, one number, one symbol — produced passwords that are hard for humans and easy for machines, because everyone applies the same substitutions in the same places. Password1! is not meaningfully stronger than password.
What actually resists guessing is entropy, and the cheapest source of entropy is length. Generate rather than invent, with Password Generator, and if you want to see how a candidate scores against realistic guessing rather than a checkbox rule, Password Strength Analyzer models it.
- 1Rotating passwords on a schedule
Forced 90-day rotation reliably produces Summer2024!, then Summer2025!. Current guidance is to rotate on evidence of compromise, not on the calendar.
- 2Reusing one strong password everywhere
Strength doesn't help when the weakest site storing it leaks. A unique generated password per site is the only thing that contains the blast radius.
Which one do I want?
Several tools here overlap. The short version:
| SHA-256 vs bcrypt | Fingerprinting a file or payload — you want it fast. | Storing a password — you want it slow and salted. |
|---|---|---|
| Hash vs HMAC | Anyone should be able to recompute it to verify integrity. | Only a key holder should be able to produce it — that's authenticity. |
| Base64 vs AES | Getting binary safely through a text-only channel. | Actually preventing someone from reading it. |
| JWT Encoder vs JWT Decoder | Minting a signed test token with claims you choose. | Reading the claims inside a token you were given. |
Why this set
Every tool here runs client-side. Keys, tokens and passwords you paste are never uploaded — which is the only reason it's reasonable to test with a real value.
The hard part isn't computing a hash, it's knowing which one belongs where. This set is arranged around that decision rather than around algorithm names.
No openssl invocation to look up, no package to add. Open the page and paste.
Questions
Is Base64 a form of encryption?
No. Base64 is a public, keyless, fully reversible encoding — anyone can decode it instantly without a secret. It exists so binary data can travel through text-only channels like HTTP headers or JSON. If you need something to be unreadable without a key, that's encryption, such as AES.
Why can't I use SHA-256 to store passwords?
Because SHA-256 is designed to be fast, and speed is exactly what an attacker with a leaked database wants. GPUs test billions of SHA-256 candidates per second. bcrypt and Argon2 are deliberately slow and salted per user, which makes bulk cracking economically infeasible.
What's the difference between hashing and encryption?
Hashing is one-way — there's no key and no way to recover the input, only to check whether a candidate produces the same digest. Encryption is two-way: with the key you get the original back. Use hashing to verify, encryption to conceal.
Are the Caesar and Atbash ciphers secure?
Not remotely, and they aren't intended to be. Both are trivially broken by hand, let alone by a computer — Atbash has no key at all. They're included for puzzles, CTF challenges and coursework, not for protecting anything.
Can I paste a real production secret into these tools?
The processing runs entirely in your browser and nothing is uploaded, so technically yes. As a habit, though, treat any secret pasted into any web page as spent and rotate it afterwards — you can't audit a page you don't control, and building the habit matters more than this one page being safe.