Hash Type Identifier

When an unknown string of letters and numbers lands in your database dump or log file, a hash type identifier tells you which algorithms could have produced it. You paste the value in, the tool compares its length, character set and prefix against known patterns, and you get a short list of candidates in seconds. Think of it as a hash fingerprint lookup: it narrows the field, and you confirm the winner yourself.

How a Hash Identifier Reads an Unknown Hash

Hash identification starts from a simple fact: a hash identifier never sees your original password or file. A hash function is deterministic, so the same input always gives the same output, and that output is fixed-length no matter how large the input was. A hash analyzer therefore works only with structural clues: how long the value is, which characters appear in it and whether any format markers such as a leading $2b$ are present. It compares those clues with a list of format patterns, and every pattern that fits becomes a candidate.

Because it matches shapes rather than proving anything, the answer is probabilistic, and every hash identifier you try will say so. Several algorithms produce the same length and character set, so a good hash identifier tool (and any hash identifier worth bookmarking) returns candidate formats ranked from most to least likely rather than a single verdict.

Hash Length and Bit Length

The quickest clue is hash length. Each hexadecimal digit stores 4 bits, so you can turn a count of characters into a bit length and match it to an algorithm family:

$$\text{bit length} = 4 \times \text{hexadecimal characters}$$

A 40-character value is \(40 \times 4 = 160\) bits, which points to SHA1 and its same-sized relatives. A 64-character value is 256 bits (SHA256), and 128 characters is 512 bits (SHA512). A 32-character value is 128 bits, the size shared by MD5, MD4 and NTLM, so a lone MD5-sized value is the hardest case.

Hexadecimal, Base64 and the Character Set

Most digests are written in hexadecimal (base 16), using only 0-9 and a-f. If you see uppercase letters, plus signs, slashes or an equals sign at the end, the same digest has probably been written in base64 instead. Base64 packs 6 bits into each character, so the encoded string is shorter than its hex twin:

$$\text{base64 characters} = 4 \times \left\lceil \frac{n}{3} \right\rceil$$

Here \(n\) is the digest size in bytes. A 20-byte SHA1 digest is 40 hexadecimal characters but only 28 base64 characters, so always note the encoding before you trust the length.

Salt, Dollar Signs and Format Markers

A salt is random data mixed into a password before hashing so that identical passwords no longer produce identical output. Systems that store the salt next to the digest usually separate the fields with dollar signs, and that delimiter is the strongest clue you can get, and the whole hash format becomes easier to name once you spot it. Unix-style $1$salt$digest means MD5crypt (also written MD5-Crypt), $2b$ means bcrypt, $5$ and $6$ mean SHA-Crypt. Because the salt travels inside the stored representation, a salted value is longer than its bare algorithm size suggests and will not match the fixed lengths above.

Hash Type Identifier Worked Example: Identify a Hash Step by Step

Suppose a colleague hands you this value from an old export, with no label on the column:

e295c2b513b4ca2c6b1ebb62e9e44872801c51f0

Here is how you identify a hash like this one, from first glance to confirmation.

1. Count the characters: there are 40, and every one is a lowercase hexadecimal character.
2. Check for a prefix, a salt or any dollar signs. There are none, so it is a bare digest.
3. Convert with the formula: \(40 \times 4 = 160\) bits.
4. Paste the value into the identifier. A 160-bit result lists SHA1 first, with RIPEMD-160 and a few rarer algorithms behind it.
5. Confirm with context: if the application that produced the export is known to use SHA1, hash a test password and compare.

The last step matters most. Hashing the test string tidepool-7714 with SHA1 returns exactly e295c2b513b4ca2c6b1ebb62e9e44872801c51f0, so the guess is correct for that value. The identifier narrowed the field; the match settled it.

Reading the Candidate List

Kali Linux ships a command-line hash-identifier that groups its answers under the label "Possible Hashs" and the least possible matches underneath. Treat the top group as the first things to test and the long tail as rare formats worth ignoring unless the context points to them. Online tools such as the Haiti-based dCode identifier work the same way, comparing your string with a database of several hundred format signature entries, and some, like OnlineHashCrack, run the check in your browser so the value never leaves your machine.

The 32-character case shows why context matters. The same input, tidepool-7714, produces three different values of identical size depending on the algorithm:

Nothing in the three 32-character rows tells them apart by shape alone, which is exactly why a hash type analyzer can only list them as candidates.

Using a Hash Analyzer on a Legacy Forum Export

Marisol Okafor is two days into an authorized security review of a decommissioned community forum, and the users table has a column called pw with no documentation. The first row holds 909c4f6e69443a9811cb7a5f4d3262fd, and she pastes it into the hash type identifier to see what she is dealing with.

The tool reports 32 hexadecimal characters, no dollar signs and no salt marker, so the value is 128 bits. It lists MD5 first, with MD4 and NTLM behind it. NTLM would be odd for a web forum, so she checks the application's own config: it is a PHP board from 2009, which fits plain MD5. To confirm, she asks the former admin for a test account whose password is known, orchard-ledger-5206, and hashes that string with MD5. The output matches 909c4f6e69443a9811cb7a5f4d3262fd exactly, so the identification holds for every row of that shape.

The result changes what she recommends. A bare MD5 digest with no salt means two users with the same password share a value, and a GPU can test billions of guesses per second against it. She compares that with the OWASP Password Storage Cheat Sheet, which asks for a salted, slow function (bcrypt with a work factor of at least 10, or Argon2id) and writes a single next action into her report: rehash each account to bcrypt at its next successful login, then delete the old column once 90 percent of active users have migrated.

Common Hash Formats and How to Tell Them Apart

Learning a handful of hash formats makes the tool's output easier to judge, and it lets you identify hash types by eye before you even paste anything. These hash types are the ones you will meet most often:

• MD5: 32 hexadecimal characters, 128 bits, still common in legacy MySQL, Wordpress and phpBB installs.
• SHA1: 40 hexadecimal characters, 160 bits.
• SHA256 and SHA512: 64 and 128 hexadecimal characters.
• bcrypt: a 60-character string starting with $2a$, $2b$ or $2y$, carrying its own salt.
• NTLM: 32 hex characters, used for Windows account storage, and MD4-based like Domain Cached Credentials.
• Rarer families such as Whirlpool, RipeMD, Haval, Tiger, SNEFRU, CRC32 and Oracle database formats.

A bcrypt string is a good example of how much a password hash can carry in one field. Its 60 characters split into a 4-character prefix, a 3-character cost, a 22-character salt and a 31-character digest, so a prefix alone is enough to settle the question, whereas a bare MD5 value offers no such hint.

If you need to identify hash values in bulk, run each one through the identifier and sort them by candidate. Want more reference material? The hashcat example hashes page lists a sample for nearly every supported format, which makes it a handy source of hash examples to test against.

Hash Analyzer Limits: Why Identification Stays Probabilistic

An identifier checks that a string is compatible with a format. It does not verify that the value is a genuine output of that hash value algorithm, and it cannot see how many rounds, which pepper or which wrapper (for example md5 of an md5) was applied. A plain 32-character value could just as easily be md5 of a username plus a password, which is why the long "least possible" tail exists and why any hash analysis should end with a test hash of a known string, such as a legacy MD5 comparison.

One-Way Functions Cannot Be Decoded

A cryptographic hash function is one-way: you cannot decode or decrypt a digest back into the original text. Hashing is not encryption, even though people often use the word loosely: you encrypt text with a key and can decrypt it later, while a hash has no key to turn back. Tools that appear to decrypt a value actually look it up in dictionaries or rainbow tables built from commonly used passwords.

From Identification to Cracking Hashes

Once you know the family, recovery means guessing. Tools such as hashcat try millions of candidate passwords per second on a GPU, hashing each guess and comparing it with your target. Security teams crack hashes only as part of an authorized password audit or penetration assessment, for instance the cracking methodology taught in the PEN-200 training course. If you are not sure you have permission, confirm the scope in writing first, and never try to recover passwords from a system you do not own.

Using a Hash Fingerprint for Integrity Checks and Software Security

Identification is not only for passwords. Software teams use a checksum or fingerprint to verify that a download was not corrupted or tampered with, to find duplicate files without opening them, since two unique files should never share a value, and to look up a file's reputation in a security database. The identifier helps here too: a 64-character value beside a download link is almost certainly SHA256, so you know which command to run on your side to verify it.

The same identification step matters for modern cryptography and cybersecurity reviews of stored credentials. Paste a stored password value into the identifier: a bare 32- or 40-character result suggests unsalted MD5 or SHA1, while a $2b$ prefix is a unique marker for bcrypt. A server or application you manage should store passwords with a slow, salted function such as bcrypt rather than a bare MD5 or SHA1 digest, and the tool is a quick way to see whether it currently does.

Frequently Asked Questions

Can this tool tell me the exact algorithm with certainty?

Not always -- many algorithms produce identically-sized output (MD5 and NTLM are both 32 hex characters; SHA-256 and SHA3-256 are both 64), so length and character set alone can't always distinguish them. When a hash has a clear format prefix (like bcrypt's $2b$ or Argon2's $argon2id$), identification is high-confidence; plain hex digests are narrowed to a shortlist of possibilities instead.

Why does a 32-character hex string match both MD5 and NTLM?

Both algorithms produce a 128-bit (16-byte) digest, which is always 32 hex characters regardless of algorithm. There's no structural difference in the output itself -- you'd need to know the context it came from (a Windows SAM database vs. a general-purpose hash) to tell them apart.

What does the $2b$ prefix in a bcrypt hash mean?

It identifies the bcrypt variant (2a, 2b, 2x, and 2y all exist for historical reasons around a padding bug fix), immediately followed by a two-digit cost factor and then the salt and hash digest together, Base64-encoded in bcrypt's own alphabet. This structure is unique enough that bcrypt hashes are always identified with high confidence.

Is my hash sent anywhere to be identified?

No. Identification runs entirely in your browser using pattern matching against known formats -- nothing is transmitted, logged, or stored.

What should I do once I know the hash type?

If it's a fast, unsalted hash like plain MD5 or SHA-1 used for passwords, that's a red flag -- those algorithms are unsuitable for password storage and should be migrated to bcrypt, scrypt, or Argon2. If you need to verify a password against a bcrypt hash specifically, use the Bcrypt Hash Verifier.