Hash Identifier

Hash generation turns text into a fixed-length digest: the text “password” gives 5f4dcc3b5aa765d61d8327deb882cf99 under MD5. Hash identification starts from a digest and asks which algorithms could have produced a string of that shape. A wordlist check starts from a digest and a list of candidate words, hashes every word and compares the results. They are often lumped together under “hash cracker”, but they answer different questions, and only the third one can ever recover a word.

This tool does the second and third. It does not compute a hash from arbitrary text you type or generate guesses automatically. Instead, it checks candidate words from a wordlist against your digest and reports whether any candidate matches.

A digest is a sequence of bytes, and most algorithms produce a fixed number of them: MD5 16, SHA-1 20, SHA-256 and SHA3-256 32, SHA-512 64, CRC32 4. Written as hexadecimal that is twice as many characters (32, 40, 64, 128, 8). The tool reads your input as hexadecimal and as Base64 (standard and URL-safe, with the padding the format requires) and compares the decoded byte length with that table. Base64 is judged by decoded length, not text length: the MD5 digest of “password” is 32 hex characters but X03MO1qnZdYdgyfeuILPmQ== in Base64 (24 characters, 16 bytes).

That is why SHA-256 and SHA3-256 always appear together for a 64-character hex string: the shape is identical, so both are shown as “Possible format match” and neither is ranked above the other. Password-hash strings that carry their own markers (bcrypt $2a$/$2b$/$2y$, MD5-Crypt $1$, SHA-256-Crypt $5$, SHA-512-Crypt $6$) are checked against their full structure: prefix, salt alphabet and length, cost or rounds range and exact hash length. Only those are labelled “Likely format match”, and a string that merely starts like one of them is not labelled at all.

A format match is evidence about shape. It does not prove which algorithm produced the string, it cannot tell which software wrote it, and it does not cover every algorithm that exists. SHA-1 and MD5 are identified because they still turn up in old CTF material and legacy systems, not because they are suitable for new security-sensitive uses.

The check reads a list of candidate words, one per line, and for each word in file order computes the digest under every algorithm you selected, then compares it with yours. The order inside a word is fixed: MD5, SHA-1, SHA-256, SHA3-256, SHA-512, CRC32. With a single hash, the run stops at the first word and algorithm that match, following that order; it does not go on to look for further matches. For a batch, checking continues until every eligible hash has matched or the wordlist ends. Hashes that cannot be checked with the selected algorithms are reported separately as “Not checked”. The bundled list has 4,613 entries, version 1.0 (its count and version are read from the shipped file, not typed into this page), an optional extended pack has 44,945 entries, version 1.0, 335 KB, and you can upload your own list of up to 200,000 physical lines and 4 MiB.

A salt is added as plain text: salt before the word gives H(salt + word), salt after gives H(word + salt). Salt and word are UTF-8 exactly as written, with no separator and no trimming. That is the only salting this tool understands. It is not bcrypt, scrypt, Argon2 or PBKDF2, and CRC32 is never salted because a checksum is not a password hash.

bcrypt, MD5-Crypt and SHA-Crypt are slow, salted password-hashing schemes. They are built so that each guess costs real time, which is exactly what a browser check against a list of thousands of words cannot do usefully, so the tool identifies them and says so instead of pretending to try. This tool does not recognize or check scrypt, Argon2 or PBKDF2 formats.

The tool also never brute-forces, never applies rules to your words (no case changes, no leet substitutions) and never shows a guessing-speed or time-to-crack estimate. The result does report the elapsed time of the check you ran; that is a measurement of this run, not a prediction of how long recovering a password would take. It is a dictionary lookup against a list you can see and control.

“No match in this wordlist for the algorithm(s) checked” says that none of the words in that list, hashed the way you asked, produced your digest. It does not say the hash is strong, that the algorithm is wrong, or that the word cannot be found some other way. A different list, a different salt position, or a different algorithm may match. A typical cause is that the hash was made with a salt or a different construction than plain hashing: sample D and sample E below have the same word and the same salt but differ in the position, and each matches only in its own position.

A typical sequence: pull a hash-looking string out of a file or capture (the Strings Analyzer lists them), paste it here, read which algorithms its length allows, then check the likeliest one against the bundled list. If the challenge text names the algorithm, put it in the hint field; it moves that algorithm to the top of the Identify list without hiding the others. It does not change the order the wordlist check uses, which is fixed (MD5, SHA-1, SHA-256, SHA3-256, SHA-512, CRC32) and depends only on the algorithms you tick on the Check tab. If the value will not identify, it may be wrapped in another encoding: the Identify tab flags a digest that is itself hexadecimal text, and the Encoding Auto-Decoder peels Base64, hex and URL layers.

If the plaintext is a word you can guess (a name, a flag-style word, a date), put your guesses in your own list and upload it; a short list you wrote is often more useful than a large generic one. If the challenge salts the hash by putting a fixed string before or after the password, enter that string and its position. If the hash is bcrypt or a crypt format, this tool only tells you what it is.