What a hash actually is
A hash takes any amount of input and hands back a fixed-length value. Same input, same output, and no way back — the only route from a hash to an input is guessing until one matches.
hello → 2cf24dba…938b9824 — sha-256, always 64 hex characters, whether the input was one byte or a gigabyte
One question decides which algorithm you want: data, or a password? sha-256 is fast, and speed is exactly what an attacker holding a stolen database wants — bcrypt and argon2id are slow and salted on purpose. md5 and sha-1 are neither, and their collision resistance broke years ago.
Choosing an algorithm
The single most consequential choice here is whether you are hashing data or a password. Everything else follows from that.
| Algorithm | Family | Reach for it when | Do not use it for |
|---|---|---|---|
| MD5 | Fast digest | Checking a file against a published checksum, or keying a cache where nobody is trying to fool you. | Signatures, certificates, deduplication, or anything an attacker can influence. Colliding MD5 inputs can be produced in seconds. |
| SHA-1 | Fast digest | Reading legacy systems that already emit it — Git object ids, older TLS chains. | Anything new. Collisions have been demonstrated in practice since 2017. |
| SHA-256 | Fast digest | The general-purpose default: content addressing, integrity checks, HMAC keys, signature digests. | Storing passwords. It is fast, and speed is the attacker's advantage. |
| SHA-512 | Fast digest | The same work as SHA-256 where a longer digest is required, or on 64-bit hardware where it is often faster. | Storing passwords, for exactly the same reason. |
| bcrypt | Password hashing | Storing passwords in a system that already uses it, or where you need a format every language has a library for. | Passphrases longer than 72 bytes, which it silently truncates. Use Argon2id instead. |
| Argon2id | Password hashing | New systems storing passwords. Argon2id is the current first recommendation, and resists both GPU and side-channel attacks. | Hashing large files or high-volume data — it is slow and memory-hungry by design. |
Argon2 comes in three variants. Argon2id is the one to pick: it runs the memory-hard, side-channel-resistant Argon2i for its first half pass and the faster, GPU-resistant Argon2d for the rest. Argon2i and Argon2d are here for reproducing hashes that already exist, not for new work.
SHA-1 and SHA-256 are unrelated designs despite the shared name; SHA-256 and SHA-512 are the same design at different widths. None of them is a password hash.
Why a fast hash is the wrong tool for a password
Suppose a database of SHA-256 password hashes leaks. A consumer graphics card computes billions of SHA-256 hashes a second, so an attacker works through every eight-character password in hours, and every word in every leaked-password list in minutes. The hash function did nothing wrong — it was fast, which is what it was built to be.
bcrypt and Argon2 attack this from the other side. A cost factor sets how much work one hash takes, and you raise it as hardware gets faster. bcrypt's cost is exponential: each step doubles the rounds, so cost 12 is four times the work of cost 10. Argon2 adds a memory cost, which matters because memory is the one resource a GPU cannot cheaply multiply — a card with thousands of cores and a few gigabytes of RAM cannot run thousands of 64 MiB hashes at once.
Both salt automatically. A salt is a random value mixed into the hash and stored alongside it, so two people with the same password get different stored hashes, and a precomputed table built for one database is useless against another. You never need to generate or manage a salt yourself — it lives inside the $-delimited string the algorithm hands back.
That string is the whole record. $2b$10$ followed by 53 characters carries the bcrypt version, the cost, the salt, and the hash. $argon2id$v=19$m=19456,t=2,p=1$… carries the variant, the Argon2 version, all three cost parameters, the salt, and the hash. Store that one string and any correct implementation can verify a password against it years later, whatever settings you have moved on to.
Never paste a password you actually use into any web tool, including this one. This page runs entirely in your browser and sends nothing anywhere, but that is a property you would have to verify rather than trust. Use it with test passwords.
Every setting, and when it matters
Which settings appear depends on the algorithm. A setting that cannot apply is disabled with a note saying why, rather than being quietly ignored.
| Setting | What it does | Reach for it when |
|---|---|---|
| Mode | Switches between producing a hash and checking one. | You already have a hash and want to know whether something matches it. |
| Algorithm | Picks the hash function, and with it which settings below apply. | Always. The digest and password families behave completely differently. |
| Output encoding | Writes a raw digest as hex or as base64. | You are matching a system that publishes base64 digests — Subresource Integrity attributes and many package lock files do. |
| Upper-case hex | Capitalises hex output. Disabled under base64, which is case-significant. | You are comparing against a checksum file that publishes capitals. The value is the same either way. |
| Cost factor | Sets bcrypt's work factor. The round count is two to this power. | Matching an existing system's setting, or working out what your servers can carry. 10 to 12 is the usual range. |
| Memory | Sets how much memory one Argon2 hash must hold, in KiB. | This is Argon2's main defence. Raise it as far as your servers allow before raising iterations. |
| Iterations | Sets how many passes Argon2 makes over that memory. | You have hit your memory ceiling and still want more work per hash. |
| Parallelism | Splits the memory into that many lanes. | Matching a hash that already specifies it. Memory must be at least 8 KiB per lane. |
| Output length | Sets how many bytes of Argon2 output to keep. | Matching an existing format. 32 bytes is the common choice and there is little reason to change it. |
| New salt | Draws fresh random bytes for the salted families, so the same input hashes to something different. | You want to see that bcrypt and Argon2 never produce the same hash twice for the same password. |
| Download | Saves the current result as a timestamped text file. | You are recording a checksum alongside a release artefact. |
The digests take no salt at all, so the salt control does nothing under MD5 or the SHA family and is disabled there. This is not a shortcoming of those algorithms — a checksum has to be reproducible by anyone with the same file, which is exactly what a salt prevents.
The cost factor is capped at 14 here rather than bcrypt's own 31. Hashing runs in this tab, on the same thread that draws the page, and each step doubles the time — cost 14 already takes about a second, and cost 31 would take longer than the machine will be switched on. Production systems are not bound by that cap; a server can run cost 12 comfortably.
The defaults are SHA-256 in lower-case hex, bcrypt at cost 10, and Argon2id at 19456 KiB with two iterations on one lane — the current OWASP first-choice setting.
How comparing works
There is one rule, and the right-hand box decides everything.
- Whatever you paste on the right is read first. If it is a bcrypt or Argon2 hash, every parameter needed to check it — cost, memory, iterations, lanes, salt — is already inside that string, so the tool reads them back out and uses them. Nothing in the Generate settings affects a comparison, which is what lets you verify a hash made with settings you no longer use.
- If the right-hand box holds a bare digest instead, its length identifies the algorithm: 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256, 128 is SHA-512, and base64 has its own four widths. Length is the only signal a bare digest carries. Thirty-two hex characters is equally an MD5, an MD4, or an NTLM hash, and no tool can tell them apart from the string alone.
- With a digest on the right, what is on the left decides which of two checks runs. If the left box holds a digest of exactly the same algorithm and encoding, the two are compared directly — the checksum-against-checksum case. Otherwise the left box is treated as text, hashed with the detected algorithm, and the results are compared. The tool always names which of the two it ran, so the choice is never silent.
- Hex comparisons ignore case, because hex digits carry no case. Base64 comparisons do not, because base64 does. Passwords are never trimmed — a leading space is part of a password, and stripping it would turn a mismatch into a match.
What people use this for
Checking a download. A project publishes a SHA-256 sum next to its release; you hash the file's contents and compare. Compare mode does the whole thing in one step: paste the published sum on the right and your computed one on the left.
Working out why a login fails. You have a bcrypt hash from a database and a password that should match it. Paste both and find out, without writing a script or standing up a server.
Sizing a cost factor. Raise bcrypt's cost or Argon2's memory and watch how long a single hash takes. Your servers are faster than a browser tab, but the shape of the curve is the same, and it makes the trade-off concrete.