Hash Identifier

All a bare digest reveals is its shape

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.

It is the reading half of a pair. The hash generator is the one that computes a digest from bytes you supply; this one goes the other way, from a value somebody handed you to the shortest honest list of things that could have made it.

The lengths, and who shares them

Hexadecimal is the common case, and the whole of the shortlist falls out of counting the characters.

Two rows deserve a footnote. NTLM is MD4 of the password as UTF-16LE, which is why a plain 32-character value turns up in Windows credential dumps. And in the crowded 64-character row, Keccak-256 differs from SHA3-256 by a single byte of padding that changes every byte of the output, so the two are indistinguishable by shape and completely different in value.

Those lengths come from FIPS 180-4, FIPS 202, RFC 1321, RFC 7693 and ISO/IEC 10118-3 rather than from observation.

The formats that introduce themselves

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.

When the value is not hex

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.

What it will not do

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. The table above narrows the field; it cannot close it.