JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
Hash Identifier
Identify a hash by length, alphabet and prefix.
What it does. Hashes are identified by shape: length, alphabet and any prefix. A 32-character hex string is MD5 or NTLM; 64 hex is SHA-256; a string starting <code>$2b$</code> is bcrypt and <code>$argon2id$</code> is Argon2. Identification is a strong inference from format, never a certainty — several algorithms share a length.
Runs in your browserNothing uploadsNo signupWorks offline
How to use Hash Identifier
- Paste the hash.
- Read the candidate algorithms, ordered by likelihood.
- Use the context notes to narrow between same-length candidates.
Identification by shape
| Looks like | Length | Likely |
|---|---|---|
| Hex | 32 | MD5, NTLM, MD4 |
| Hex | 40 | SHA-1, MySQL 4.1+ |
| Hex | 56 | SHA-224 |
| Hex | 64 | SHA-256, SHA3-256, BLAKE2s |
| Hex | 96 | SHA-384 |
| Hex | 128 | SHA-512, SHA3-512, BLAKE2b |
| $2a$ / $2b$ / $2y$ | 60 | bcrypt |
| $argon2id$ | varies | Argon2id |
| $6$ | varies | SHA-512 crypt |
Where several candidates share a length, only context separates them. A 32-hex hash from a Windows SAM dump is NTLM; the same shape from a web application is almost certainly MD5.
What the prefix tells you
Modern password hashes are self-describing, and that is a deliberate design improvement. The Modular Crypt Format encodes the algorithm, cost parameters and salt in the string itself.
$2b$12$ means bcrypt at cost factor 12. $argon2id$v=19$m=65536,t=3,p=4$ gives the Argon2 variant, version, memory, iterations and parallelism.
A bare hex string carries none of this, which is exactly why identifying it is guesswork. If you are designing storage, choose a format that names itself — it removes this problem permanently and lets you migrate cost factors later.
A note on what this is for
Identifying a hash format is a routine part of incident response, migrating a user database between systems, and debugging an authentication integration.
It is worth being clear that identifying a hash does not reverse it. A hash is one-way by construction, and knowing that a string is bcrypt tells you only how it was produced.
If you are migrating a password database, the correct approach is not to recover the passwords. Store the old hash, verify against it at next login, and re-hash with the new algorithm at that moment.
Frequently asked questions
Can you tell me what the original text was?
No, and no tool can. Hashing is one-way by design. Identifying the algorithm tells you how the hash was produced, nothing about its input.
Two algorithms have the same length — which is it?
Only context decides. A 32-character hex hash is MD5 or NTLM depending on where it came from: a Windows credential store points to NTLM, a web application to MD5.
Why do some hashes start with a dollar sign?
That is Modular Crypt Format, which encodes the algorithm, cost parameters and salt inside the string. $2b$ is bcrypt, $argon2id$ is Argon2id, $6$ is SHA-512 crypt.
What should I use for storing passwords?
Argon2id where available, bcrypt otherwise. Both are deliberately slow and take a tunable cost parameter. Never a bare MD5, SHA-1 or SHA-256 — they are built to be fast, which is exactly wrong for passwords.
How do I migrate a legacy password database?
Do not try to recover the passwords. Keep the old hashes, verify against them at the next successful login, and re-hash with the new algorithm at that moment. The database converts itself as people sign in.