How this instrument works
Cryptographic and checksum hash functions always output a fixed number of bits, no matter how long the input was — MD5 always produces 128 bits, SHA-256 always produces 256 bits, and so on. When that fixed-length output is written as hexadecimal (base 16, using digits 0-9 and letters a-f), each character represents exactly 4 bits, so the character count alone reveals the bit length: a 32-character hex string is 128 bits, a 64-character string is 256 bits, and so forth. This length-based check is the same first-pass heuristic real hash-identifier tools use before trying anything more sophisticated.
This instrument covers the well-established fixed hex-digest lengths of the standard MD/SHA family: 8 characters for CRC-32 (32-bit), 32 for MD5, MD4, or NTLM (128-bit), 40 for SHA-1 or RIPEMD-160 (160-bit), 56 for SHA-224 or SHA3-224 (224-bit), 64 for SHA-256 or SHA3-256 (256-bit), 96 for SHA-384 or SHA3-384 (384-bit), and 128 for SHA-512, SHA3-512, or Whirlpool (512-bit).
Length alone is a narrowing tool, not a final answer — several distinct algorithms happen to share the exact same output size, and this instrument reports every common candidate at that length rather than guessing which one it actually is. It also deliberately excludes salted or formatted schemes like bcrypt (which look like $2b$10$... rather than a plain hex digest) and Base64-encoded digests, since neither one is a fixed-length hex string that this length-only method can meaningfully classify.
Real-world uses include sanity-checking a hash pulled from a config file, a leaked-credential dump, or a checksum listing before deciding how to handle it — knowing a string is 40 hex characters immediately rules out MD5 and SHA-256 as possibilities, even before you know anything else about where it came from.
- Count the characters in your hash string (digits 0-9 and letters a-f/A-F only) and enter that count into Hash length (hex characters).
- Read Likely algorithm for the family of hash functions whose fixed digest size matches that exact length.
- If your string contains characters outside 0-9 and a-f — like $, ., or extra symbols — it isn't a plain hex digest, and this length-only check doesn't apply; look for a bcrypt or Base64 pattern instead.
- Treat the result as a starting point: pair it with context, such as where the hash came from or whether it's salted, to confirm the exact algorithm among same-length candidates.
Worked example — a 32-character hex string
A hash like 5f4dcc3b5aa765d61d8327deb882cf99 is 32 hexadecimal characters long. Since each hex character encodes 4 bits, that's 32 x 4 = 128 bits total — exactly the digest size produced by MD5, the older and now-broken MD4, or NTLM, the hash format Windows uses for stored passwords. Likely algorithm reads 'MD5, MD4, or NTLM (128-bit)'.
Length alone can't distinguish between these three without additional context — a hash pulled from a Windows SAM database or a captured NTLM authentication exchange is almost certainly NTLM, while the same 32-character string in a generic file-checksum listing is far more likely to be plain MD5. The tool narrows the field; the surrounding context picks the winner.
Questions
How do I identify a hash algorithm just from the string itself?
The fastest first check is length: convert the character count to bits (hex characters x 4, since each hex digit is 4 bits) and compare it against known fixed digest sizes — 128 bits for MD5, 160 for SHA-1, 256 for SHA-256, and so on. This narrows the possibilities immediately, though several algorithms can share the same output length, so length alone rarely gives one definitive answer. Beyond length, format clues (delimiters like $2b$ for bcrypt, or a non-hex character set for Base64) and knowing where the hash came from help narrow it further.
Why can't this tool tell MD5 apart from NTLM?
Both MD5 and NTLM produce a 128-bit digest, written as exactly 32 hexadecimal characters — the two outputs are indistinguishable by length or format alone. Telling them apart requires context outside the hash string itself, such as knowing it came from a Windows password database (pointing to NTLM) versus a generic file checksum or a web application's password column (more often plain MD5, though modern practice avoids storing MD5 password hashes directly at all).
What about bcrypt or Base64-encoded hashes — why don't they show up here?
bcrypt, scrypt, and Argon2 embed the algorithm name, cost factor, and salt directly in a delimited string, such as $2b$10$..., rather than outputting a fixed-length plain hex digest — there's no single "length" to look up. Base64-encoded digests use a different character set and a different length relationship (3 bytes become 4 Base64 characters, not the 2-hex-characters-per-byte this tool assumes), so they need a separate identification approach entirely.
Does a longer hash always mean stronger, more secure hashing?
Not by itself. Digest length affects theoretical collision resistance, but algorithm design matters just as much: MD5 and SHA-1 are both considered cryptographically broken today, not because their output is short, but because practical collision attacks were found against their internal construction. A longer output from a flawed algorithm isn't automatically safer than a shorter output from a sound, current one — for new work, a modern algorithm like SHA-256 or better is the safer choice regardless of length comparisons to older ones.
What's the difference between a checksum like CRC-32 and a cryptographic hash?
CRC-32 is designed to catch accidental data corruption — a scratched disk, a dropped packet — cheaply and quickly, but it's trivial to forge deliberately, so it offers no protection against a tampering attacker. Cryptographic hash functions like SHA-256 are built specifically to resist intentional attacks: finding two inputs that produce the same output, or reversing a hash back to its input, should both be computationally infeasible. Never use a checksum like CRC-32 anywhere security matters.