Analyse hash

The likely algorithm family, from length and character set alone. It measures your string, converts that to a byte count, and lists every algorithm in the site table that produces exactly that many bytes. It is a heuristic, not a proof, which is why 32 bytes comes back as a list, SHA-256, SHA3-256, BLAKE2s, BLAKE3, SM3 and Keccak-256, rather than as one answer.

No. It never computes a hash and never tries to find an input that produces one. It looks at the shape of the string you gave it and nothing else. To test a candidate password against a stored hash, use bcrypt verify or Argon2 verify. There is no cracking tool anywhere on this site.

It tries base64 next, matching A to Z, a to z, digits, plus, slash and trailing equals signs, and estimates the decoded size as three quarters of the length. If it is neither, you get "not a recognized hex or base64 hash string". Hex is checked first on purpose, because hex is a subset of the base64 character set and would otherwise be misread.

Because a hex digest always has an even number of characters, two per byte. If yours does not, the tool says so and suggests truncation: the text ends "odd length, so this isn't a complete byte string (truncated?)". Usually a character was lost in copying, or a line was cut short in a log.

The candidate list comes from the same twenty-four algorithm table that Generate all hashes uses. If nothing has your byte count, it says "No shipped hash algorithm produces exactly this length." Formats that carry their own prefix, such as bcrypt or Argon2 encoded strings, are not in the table either; those you can recognise by the $ segments without guessing.

As a file. Drop a text file containing the digest and the contents are read as text and trimmed. Drop several and each is analysed separately. Nothing leaves the page: the whole check is string arithmetic in a Web Worker in this tab.