Loading Hash Identifier…
Paste a hash above. Every algorithm whose published output length matches will be listed, in specification order, with no attempt to rank them — there is nothing in the digest to rank them by.
A length is not an identification. Sixty-four hex characters is SHA-256 most of the time and SHA3-256, SHA-512/256, BLAKE2s-256 or Keccak-256 the rest of the time, and no examination of the string can separate them. What settles it is context: the tool that produced the value, the field it was stored in, or a matching digest you compute yourself. Where this tool is genuinely certain is the crypt formats, because those carry their own name.
Identifying a hash is not reversing one, and this tool does neither lookups nor cracking. It makes no network request of any kind, so a hash pasted here is not submitted to a rainbow table, a breach database or anything else. If the value came from somewhere you do not control, treat it as somebody’s password material and handle it accordingly.
A hash has no header, no version marker and no name attached. What survives the trip is a length and an alphabet, and several algorithms share both, so the only honest answer to "what produced this?" is usually a shortlist. This tool builds that shortlist from published output lengths and then refuses to rank it, because there is nothing in the string to rank it by.
That refusal is the feature. An identifier that answers "SHA-256" to every 64-character value is right most of the time and gives no way to notice the occasions when it is wrong, which are exactly the occasions that cost hours.
Thirty-two hex characters is MD5, but also MD4, RIPEMD-128 and NTLM — the last being MD4 of the password as UTF-16LE, which is why it turns up in Windows credential dumps. Forty characters is SHA-1, RIPEMD-160, or a MySQL 4.1 password hash with its leading asterisk removed. Fifty-six is SHA-224, SHA-512/224 or SHA3-224.
Sixty-four is the crowded one: SHA-256, SHA-512/256, SHA3-256, BLAKE2s-256 and Keccak-256 all land there, and Keccak-256 differs from SHA3-256 by a single byte of padding that changes every byte of the output. Ninety-six is SHA-384 or SHA3-384; 128 is SHA-512, SHA3-512, BLAKE2b-512 or Whirlpool. Those lengths come from FIPS 180-4, FIPS 202, RFC 1321, RFC 7693 and ISO/IEC 10118-3 rather than from observation.
Password hashes are the exception, because whoever verifies one has to know which function and which parameters to repeat. So they carry that information in front: $2a$, $2b$ or $2y$ for bcrypt in a fixed 60 characters, with the cost factor as a power of two in the two digits after it; $argon2id$ for the Argon2 of RFC 9106, with memory, time and parallelism written in as m, t and p; $6$ and $5$ for the SHA-512 and SHA-256 crypt variants in /etc/shadow; $1$ for md5crypt; $y$ for yescrypt.
Django puts the algorithm name before the first dollar instead, and LDAP wraps it in braces as {SSHA}. The registry of these prefixes is documented by Passlib, and where a prefix is present this tool states a name rather than a shortlist.
Plenty of digests travel in base64 instead, where the length arithmetic changes: a 32-byte digest becomes 44 characters with padding, a 20-byte one becomes 28. An HTML integrity attribute goes further and writes the algorithm in front, as sha256- followed by standard base64, making it one of the few self-labelling forms outside the crypt prefixes.
Base32 is a different signal again. Upper-case letters with the digits 2 to 7 and no others usually indicates a shared secret rather than a digest — an authenticator app seed is the common case, and that is key material to protect rather than a hash to name. The tool says as much instead of matching it against digest lengths that happen to line up.
It does not reverse anything, look anything up, or crack anything. There is no network request of any kind, so a value pasted here is not submitted to a rainbow table or a breach database — it is read in the page and forgotten. Identification and recovery are different problems, and only the first one is on offer.
It is also easy to mislead. A digest that has been truncated for a database column looks exactly like a shorter algorithm’s output. An encrypted blob, a random token or a TOTP seed in base32 all have the shape of a hash without being one. What settles the question is context — the tool that wrote the value, or a digest you compute yourself and compare.
By looking outside the string. Find out what wrote it: a WordPress database, a Git object, an Ethereum address and a Linux checksum file each narrow it immediately. Failing that, hash a known input with each candidate and compare.
Not with this tool and not by any direct method, since a hash discards information on the way through. Predictable inputs can still be found by guessing them and comparing, which is a separate exercise entirely and one this page does not perform.
Then it is very likely a crypt-format password hash from a scheme this tool does not carry. The convention is that the text between the first two dollar signs names the algorithm, so searching for that fragment usually identifies it.
No. Hex is a number written down, so case is presentation only and the digest is identical either way. Command line tools print lower case, which is the sensible form to normalise to before comparing two values.