How to Identify a Hash Type (with a Reference Table)

Figure 1: Length, character set, and prefix narrow the field fast

The string tells you more than you think

A raw hash looks like static, but its shape leaks its origin. Length, character set, and any prefix at the front narrow the field quickly, often down to a single likely algorithm. Reading those signals saves time in audits, forensics, and CTF rounds, and it is the first move before any cracking tool can do useful work.

Here is a practical method, plus a table you can keep next to you.

Start with length and character set

Two quick observations do most of the job.

First, measure the length. Many raw hashes are plain hexadecimal, so counting characters points straight at a family: 32 characters suggests the MD5 or NTLM group, 40 points at SHA-1, and 64 at SHA-256.

Second, look at the character set. All hex, meaning 0 through 9 and a through f? Probably a classic digest. A mix of letters, digits, and symbols broken up by dollar signs? That is almost certainly a structured format carrying its own metadata.

Reference table: common hashes at a glance

Modes shift a little between tool versions, so treat the numbers as a strong hint rather than a rule.

Prefixes make it easy

Anything that opens with a dollar sign is handing you the answer. The modular crypt format wraps the algorithm name, cost, salt, and digest between dollar signs, so $6$ reads as sha512crypt and $2b$ as bcrypt with no further guessing. The *2john family follows the same idea: $office$, $zip2$, $pdf$, and $sshng$ each announce where the data came from. When you see one of these, the work is basically done.

When length alone is not enough

The awkward case is the 32-character hex string, because MD5, NTLM, and MD4 all share that exact shape. Length cannot separate them, so context decides. Pulled from a Windows account database? Read it as NTLM. Sitting in a web app's user table? MD5 is the safer first guess. A failed attempt under one assumption is a cue to try the next, which is normal and quick.

The same overlap touches the 64-character group, where SHA-256, SHA3-256, and Keccak-256 look identical. Again, where you found the value usually settles which to try first.

Try it on real strings

Here are genuine values you can drop into the identifier to watch the method work. Each one is the hash of the word password, so the shapes are easy to compare:

5f4dcc3b5aa765d61d8327deb882cf99                          MD5     (32 hex)
8846F7EAEE8FB117AD06BDD830B7586C                          NTLM    (32 hex)
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8                  SHA-1   (40 hex)
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8   SHA-256 (64 hex)

Notice the first two are the same length. Nothing in the string itself tells them apart, which is exactly the ambiguity to expect from a 32-character value.

A quick walkthrough on an unknown string: say you pull 5f4dcc3b5aa765d61d8327deb882cf99 from a web application's user table. Count the characters, 32, all hex, so the candidates are MD5, NTLM, and MD4. It came from a web app rather than a Windows account, so MD5 is the sensible first try. Run it against a wordlist, and it resolves to password at once, confirming the guess.

Let the tool do the matching

Running every check by eye gets old fast. The hash identifier does it instantly: paste a value and it reports the likely types, each with its Hashcat mode and John format, ranked by confidence. It runs in the browser, so nothing you paste is sent anywhere. From there you can jump to the right generator, such as the NTLM tool or the bcrypt verifier, to confirm a match.

The takeaway

Read the length, read the character set, and check the front for a dollar-sign prefix, and most hashes announce themselves. Keep the table handy for the common cases, lean on context when two formats collide, and let the identifier rank the candidates when you want a second opinion. Correct identification is what makes every tool after it faster.