Identify likely hash algorithms from a digest by its length, character set, and prefix format.
When you recover a hash during a penetration test, a CTF, or an incident, the first question is which algorithm produced it — because that determines how (and whether) it can be cracked. This tool infers likely algorithms from two clues that do not require running anything: the digest length and any structured prefix.
How identification works. Unsalted digests are usually shown in hexadecimal, and each algorithm has a fixed output size: 32 hex characters means 128 bits (MD5, NTLM, or MD4), 40 means 160 bits (SHA-1 or RIPEMD-160), 64 means 256 bits (SHA-256, SHA3-256, BLAKE2s), 128 means 512 bits (SHA-512, SHA3-512). Because several algorithms share a size, length alone yields candidates, not a single answer. Salted password hashes are easier: they carry a self-describing prefix such as $2b$ (bcrypt), $argon2id$ (Argon2), $6$ (sha512crypt), or $1$ (md5crypt), which this tool matches directly. The $-delimited fields after the prefix usually encode the cost/rounds and the salt, which is why two hashes of the same password look completely different — the salt is baked into the string.
From candidate to cracking mode. Identification is the first step of a workflow that ends in a tool like hashcat or John the Ripper, each of which needs an explicit mode number (hashcat -m 0 for raw MD5, -m 1000 for NTLM, -m 3200 for bcrypt). Narrowing the algorithm here is what tells you which mode to select; guessing wrong wastes an entire cracking run against the wrong format.
Worked example. The string 5f4dcc3b5aa765d61d8327deb882cf99 is 32 hex characters, so the tool proposes MD5, NTLM, and MD4. Context decides: if it came from a Windows SAM dump it is almost certainly NTLM; from a web app database it is more likely MD5. To confirm a guess, hash a known plaintext with the hash generator and compare — that string is in fact the MD5 of password.
Common mistake. Treating a length match as proof. A 32-character hex string could also be a truncated longer hash, a UUID with hyphens stripped, an HMAC tag, or an application-specific digest. Use surrounding context — where you found it, the software involved — to disambiguate. A value with characters beyond a–f is not raw hex at all; it may be Base64 or a structured crypt string.
Defensive angle. The reason NTLM and unsalted MD5/SHA-1 are so quickly identified is the same reason they are so quickly cracked: no salt and a fast function. If your own audit turns up bare MD5, SHA-1, or NTLM protecting credentials, that is a finding. Migrate to Argon2id or bcrypt with per-user salts so that even a full database leak forces attackers into slow, per-hash work.
Caesar, ROT13, Atbash, and Vigenère transforms plus letter-frequency analysis for CTF and puzzle solving.
Decode a PKCS#10 Certificate Signing Request (CSR) to verify its subject, public-key algorithm, and signature before you submit it to a CA.
Shannon entropy and character-class analysis for a secret.
Compute MD5, SHA-1, SHA-256, and SHA-512 digests of any text in one pass, entirely in your browser.
Generate keyed HMAC signatures (HMAC-SHA1, HMAC-SHA256, HMAC-SHA512) for API signing and webhook verification.
Generate strong, cryptographically-random passwords with configurable length and character sets — computed in your browser and never transmitted.