Hash identifier for password hashes and digests
This hash identifier looks at the shape of a hash string and tells you which algorithm most likely produced it. It is meant for developers and administrators who find an unlabeled hash in a config file, a legacy database column or an old .htpasswd file and need to know what they are dealing with before migrating or verifying it.
How identification works
Hashes carry no metadata, so identification relies on two clues:
- Prefixes and structure. Modern password hashes are self-describing.
$2y$10$…is bcrypt,$argon2id$v=19$…is Argon2,$6$is SHA-512 crypt from Linux/etc/shadow,$apr1$is Apache MD5,$P$is phpass (older WordPress),pbkdf2_sha256$is Django, and*followed by 40 uppercase hex characters is MySQL'smysql_native_password. These matches are nearly certain. - Length and alphabet. A bare hex string can only be narrowed down by its length. 32 hex characters is 128 bits, which fits MD5, NTLM, MD4 and others; 64 hex characters fits SHA-256, SHA3-256, BLAKE2s and more. Base64 strings are decoded to a byte count and matched the same way.
Example
Three lines from the sample input produce:
5f4dcc3b5aa765d61d8327deb882cf99
→ MD5 — 32 hex characters = 128 bits (most likely)
NTLM — 128-bit alternative
MD4 — 128-bit alternative
LM — 128-bit alternative
RIPEMD-128 — 128-bit alternative
xxHash128 — 128-bit alternative
$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy
→ bcrypt — Password hash (Blowfish-based, cost factor after the version).
*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19
→ MySQL 4.1+ (mysql_native_password) — SHA1(SHA1(password)).The bcrypt and MySQL results are definitive because of their prefixes. The first line is ambiguous by nature: every 128-bit algorithm produces 32 hex characters, so the tool lists MD5 first as the most common and shows the rest as alternatives.
Formats it recognizes
| Group | Examples |
|---|---|
| Password hashing | bcrypt, Argon2 (id/i/d), scrypt, yescrypt, SHA-512 crypt, SHA-256 crypt, MD5 crypt, APR1 |
| Application formats | phpass, WordPress 6.8+ bcrypt, Django PBKDF2 and legacy SHA-1, passlib PBKDF2 |
| Databases and directories | MySQL 4.1+ and caching_sha2, PostgreSQL MD5 and SCRAM-SHA-256, MSSQL, LDAP {SHA}/{SSHA} |
| Raw digests | CRC-32, MD5, NTLM, SHA-1, SHA-224 to SHA-512, SHA-3, BLAKE2, Whirlpool, in hex or Base64 |
If you paste a JSON Web Token by mistake, it is flagged as a token, not a hash; open it in the JWT decoder instead.
Confirming an ambiguous result
When several algorithms share a length, the reliable way to confirm is to hash a known value. If you know one password in the dataset, hash it with the MD5 hash generator or SHA-256 hash generator and compare. Context helps too: a 32-character hash in a Windows export is likely NTLM, while one in an old PHP app is likely MD5.
Why this matters for security
Knowing the format is the first step in a defensive audit. If you find unsalted MD5, SHA-1 or NTLM protecting user passwords, those hashes should be migrated to a slow, salted algorithm such as bcrypt or Argon2, typically by rehashing each password at the user's next successful login. Identifying formats is also useful when importing users from another platform or checking that a new hasher is actually in use.
Privacy
Identification is pure pattern matching in your browser. Hashes are not uploaded or looked up against any online database, so you can safely analyze data from internal systems.