Hash Type Identifier

Hash type identifier: work out what algorithm produced an unknown hash

You have a string that looks like a hash and you need to know what made it before you can do anything with it — feed it to the right cracking mode, match it to a known format, or confirm it is a hash at all and not some other encoding. This tool reads the structure of what you paste and lists the algorithms that could have produced it, ordered most likely first, with the hashcat -m mode and John the Ripper format name attached to each so you can go straight on to the next step in an authorised engagement or CTF.

Paste one hash per line, up to 50 at a time. Everything runs in your browser by pattern matching alone — there is no lookup, no server call, nothing leaves the page. That matters here, because the strings you are examining are often credentials.

Identification is a best guess from structure, not a certainty

This is the honest constraint at the centre of the whole exercise: a raw hash carries no label. An MD5 digest is 128 bits of output rendered as 32 hexadecimal characters, and so is an NTLM hash, and so is an MD4 digest, and so is one half of an LM hash. Nothing inside the string distinguishes them — the algorithm identity is not encoded anywhere in a bare digest. So when several algorithms produce the same shape, the tool lists all of them and marks each with a confidence of high, medium or low rather than pretending to pick one. High means it is the common, expected match for that shape; low means it is structurally possible but rare. You bring the context — where the hash came from — that the string itself cannot give you.

Length and character set: the first cut

For hex-only strings, length narrows the field to a family, and that is usually as far as raw structure can take you. The lengths the tool recognises:

The pattern the tool tests for these is strictly [a-f0-9] at the exact length — a 64-character string that contains a g or a space is not a hex digest and will not match here, which is itself useful information. Two rules of thumb fall straight out of the table. A 32-character hex string is overwhelmingly MD5 or NTLM, and which one depends entirely on provenance: pulled from a Windows SAM or a domain controller dump it is NTLM, seen hashing a web application password it is almost always MD5. A 64-character hex string is SHA-256 far more often than anything else, but the SHA-3 and Keccak families share its length exactly, so if you are working with Ethereum data or a system you know uses Keccak, do not assume SHA-256.

Prefixed formats identify themselves

Modern password hashing does not leave you guessing. Unix-style crypt formats and their relatives carry a $id$ prefix, and several other systems use recognisable wrappers, so these are matched first and returned with high confidence — the format is self-describing:

• $2a$, $2b$, $2y$ — bcrypt (hashcat 3200). The two digits after the prefix are the cost factor.
• $argon2id$, $argon2i$, $argon2d$ — Argon2, a memory-hard password hash.
• $scrypt$ or a SCRYPT: prefix — scrypt (hashcat 8900).
• $y$ or $7$ — yescrypt, the default on current Linux distributions.
• $1$ — md5crypt, the old Unix MD5 (hashcat 500).
• $5$ — sha256crypt (hashcat 7400).
• $6$ — sha512crypt (hashcat 1800), the common modern /etc/shadow format.
• $apr1$ — Apache's apr1 MD5 variant (hashcat 1600).
• $P$ or $H$ — phpass, the WordPress and phpBB portable hash (hashcat 400).

These are not just longer hex — they are complete records that bundle the algorithm identifier, the parameters (cost, rounds, memory), the salt and the digest into one $-delimited string. That is why a $6$ hash is unambiguous where a bare 128-hex string is not: sha512crypt writes its identity into the front of every hash it produces. A couple of these have no mainstream cracking support — Argon2 and yescrypt in particular — and the tool says so on the result rather than handing you a hashcat mode that does not exist.

Salted and application-specific formats

Beyond the crypt family, the tool recognises a set of composite and vendor formats by their delimiters and wrappers:

• {SSHA} and {SHA} base64 wrappers — LDAP salted SHA-1 and SHA-1.
• sha1$salt$hash and pbkdf2_sha256$ — Django's formats.
• A leading asterisk on 40 hex characters, *ABC123… — MySQL 4.1 and later.
• 32hex:salt — a salted MD5, reported as both md5($pass.$salt) and md5($salt.$pass) because the concatenation order is not recoverable from the string.
• NetNTLMv1 and NetNTLMv2 challenge/response captures, recognised by their multi-field colon-delimited layout.
• An NT hash embedded in a secretsdump or SAM line, where the 32-hex NT portion is the part you actually crack.

For the base64-wrapped LDAP formats, the digest and salt sit inside a Base64 blob after the scheme tag — the wrapper is what identifies them, so the tool keys on {SSHA} and {SHA} rather than trying to measure the decoded length. If your string is bare Base64 with no wrapper, that on its own does not tell you what was hashed; you would need to decode it and measure the raw byte length (16 bytes points at MD5-family, 20 at SHA-1, 32 at SHA-256) to make any progress.

Worked examples

Try the built-in examples and watch what the ordering does:

• 5f4dcc3b5aa765d61d8327deb882cf99 — 32 hex, so MD5 leads with NTLM close behind and MD4, LM, MD2 and RIPEMD-128 listed lower. This particular digest is the MD5 of the word password, which is exactly why length alone cannot tell you it is MD5 and not NTLM.
• $2b$12$GhvMmNVjRW29ulnudl.LbuAnUtN/LRfe1oOF6UEt8CQjW8/7Cq0S6 — the $2b$ prefix pins it to bcrypt at cost 12 with no ambiguity.
• b1b3773a05c0ed0176787a4f1574ff0075f7521e — 40 hex, so SHA-1 with RIPEMD-160 and HAS-160 as low-confidence alternates.
• $6$rounds=5000$anotherlongsalt$abc — the $6$ makes it sha512crypt regardless of what follows.

Disambiguating the ambiguous cases

When length leaves you with several candidates, structure has done all it can and the deciding evidence comes from outside the string. A short field guide to the calls the tool cannot make for you:

• MD5 versus NTLM (32 hex). Provenance decides. Anything extracted from a Windows credential store — a SAM hive, an ntds.dit dump, a secretsdump line — is NTLM. A password column in a leaked web database, a checksum, or a value your own code produced with a generic hash function is MD5. If you truly have no context, try NTLM (hashcat mode 1000) and MD5 (mode 0) in turn; they cost the same to attempt.
• SHA-256 versus the SHA-3 and Keccak family (64 hex). SHA-256 is the default assumption almost everywhere. Reach for Keccak-256 only when the source is a system you know uses it — Ethereum addresses and transaction hashes are the common example.
• SHA-1 versus RIPEMD-160 (40 hex). SHA-1 dominates by a wide margin. RIPEMD-160 turns up mainly in Bitcoin address derivation and a few older European systems.
• A bare digest versus a truncated longer one. Some systems store the first N characters of a longer hash. If a 32-hex string will not crack as any 128-bit algorithm, consider that it may be a truncated SHA-1 or SHA-256 — something the length cannot reveal.

The confidence badges encode exactly this: the high-confidence entry is what you should try first, and the low-confidence ones are there so you have somewhere to go when the obvious attempt fails.

Reading Base64 the tool cannot label

Bare Base64 with no scheme wrapper is the one case where you have to do a little work yourself, because the tool matches structure and unwrapped Base64 has no distinguishing structure. The trick is to decode it and measure the raw bytes: Base64 encodes three bytes into four characters, so a 24-character Base64 string (with padding) is 16 raw bytes, a 28-character string is 20 bytes, and so on. Map the byte length back to the algorithm the same way you would a hex digest:

The LDAP {SSHA} format is the salted version of this: decode the blob and the digest is the first 20 bytes, with the salt as whatever trails it. The tool recognises the wrapped form for you; only the unwrapped blob needs the manual decode.

What each result gives you

Every candidate carries a confidence badge and, where cracking support exists, the two identifiers you need to act on it. The hashcat -m mode is the number you pass to hashcat to select the algorithm; the john --format= name is the equivalent for John the Ripper. A handful of algorithms — Argon2, yescrypt, some of the exotic hex-length matches — have no hashcat mode, and the tool shows "No hashcat mode" rather than inventing one. Copy buttons put the command fragment or the raw input on your clipboard so you are not retyping a 128-character string.

When nothing matches

If the tool returns no candidates, the string does not fit any format it knows. The likely explanations, in rough order: it is an encoding rather than a hash (Base64 or hex-encoded data that happens to look hash-like), it is a ciphertext rather than a digest, it has been truncated or has stray whitespace, or it is a format outside this tool's set. A quick sanity check is the character set — if it contains characters outside 0–9 a–f and is not one of the prefixed formats above, it is not one of the common raw hex digests.

Identifying the type is only the first move. Once you know what you are looking at and have the authority to proceed, the site's hash lookup tool checks a digest against known databases — a different job from working out its type, which is all this page does.