hash type identification
A hash on its own, with no label attached, is just a sequence of characters; figuring out which algorithm produced it depends on indirect clues like the character length, the alphabet used, and, when one exists, a format prefix like `$2y$` or `$apr1$` that hands over the answer with certainty.
All three algorithms produce exactly 32 hexadecimal characters; the identifier lists MD5 first because it is statistically the most common in this format, not because the string proves it is MD5.
A 256-bit digest split into hexadecimal always yields 64 characters, so the same length fits three different hash families, each with its own hashcat number.
The `$2y$` prefix and the 22-plus-31-character itoa64 structure identify bcrypt unambiguously, unlike the two previous examples; the cost factor pulled straight from the hash shows that 1024 rounds were used.
It depends on the format. Prefixed schemes such as bcrypt, Argon2, yescrypt, sha512crypt and PBKDF2 identify themselves and get close to certainty. Bare hexadecimal digests are ambiguous by nature: several algorithms produce the same 32, 40 or 64-character output, so the correct answer is a ranked list, not a single name.
Because both algorithms produce exactly 128-bit digests, that is, 32 hexadecimal characters, and neither carries a prefix or format marker that tells them apart within the string; the only way to know which is which comes from the context the hash was pulled from, for example a Windows SAM file points to NTLM.
It is the mode identifier hashcat itself uses for that algorithm, for example `-m 0` runs attacks against MD5 and `-m 1400` against SHA-256; the identifier shows this number as a reference for whoever plans to use the hash in a cracking tool, not as part of the hash calculation itself.
Because bcrypt embeds its own format inside the hash: the `$2y$` prefix, the cost factor, and the clear separation between salt and digest leave little doubt about the algorithm. A raw SHA-256 hash is just 64 hexadecimal characters with no marker at all, so the same length also fits SHA3-256 and Keccak-256.
No, matching length only means the candidate algorithms produce hashes of the same size; it says nothing about the source text. Two different MD5 hashes, both 32 characters long, almost certainly come from different texts, unless they are identical character for character.
Paste a value above to see the most likely format, the parameters it carries and the alternative candidates.
Identification happens only in the browser, matching patterns locally. Nothing you paste is sent, stored or logged.