Hash Identifier

Identify which algorithm produced a given hash string

Identify the likely algorithm behind a hash by its length, character set and prefix. Recognises bcrypt, Argon2, crypt(3), MD5, SHA family, NTLM and more, listing every plausible candidate. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

How does hash identification work?

Structured hashes such as bcrypt and Argon2 carry an explicit prefix, so they are matched exactly. Raw hex or Base64 digests have no label, so the tool infers candidates from the length in bits and the character set.

A hash identifier tells you which algorithm most likely produced a hash string, so you can pick the correct verification routine or debug a password store. Some hashes announce themselves with a prefix; others are anonymous fixed-length digests where only the length and character set narrow the options. This tool handles both cases, running entirely in your browser.

How it works

There are two distinct cases:

  1. Prefixed / structured formats carry an explicit identifier and are matched first with high confidence. Examples include bcrypt ($2b$...), Argon2 ($argon2id$...), the crypt(3) family ($1$ md5crypt, $5$ sha256crypt, $6$ sha512crypt, $y$ yescrypt) and LDAP {SSHA}.
  2. Raw digests in hex or Base64 have no label, so candidates are inferred from the length in bits and the character set. For instance 32 hex characters (128 bits) matches MD5, MD4, NTLM and MD2; 64 hex characters (256 bits) matches SHA-256, SHA3-256 and BLAKE2s.

Because algorithms collide on length, the tool returns all plausible candidates for raw digests rather than guessing a single answer.

Common hash lengths and their candidates

Hex charactersBitsPossible algorithms
32128MD5, MD4, NTLM, MD2
40160SHA-1, RIPEMD-160
56224SHA-224, SHA3-224
64256SHA-256, SHA3-256, BLAKE2s, BLAKE3
96384SHA-384, SHA3-384
128512SHA-512, SHA3-512, BLAKE2b-512, Whirlpool

Recognizing prefixed formats on sight

Structured password hashes include their format in the string itself:

  • $2b$12$... — bcrypt (cost factor 12, then 53 Base64 characters of salt and hash)
  • $argon2id$v=19$... — Argon2id with explicit parameters
  • $6$rounds=5000$salt$... — SHA-512crypt via crypt(3)
  • $1$salt$... — MD5crypt; legacy, avoid
  • {SSHA}Base64string... — Salted SHA-1 as used in some LDAP directories
  • sha256:iterations:salt:hash — Django PBKDF2-SHA256 format

These are unambiguous: the prefix completely identifies the algorithm, and the salt and parameters are embedded in the string. No length-guessing is needed.

Practical debugging scenarios

Scenario 1 — migrating a user database: You inherited a password column containing 32-character hex strings. This tool confirms they are likely MD5 (or MD4/NTLM), which you then need to re-hash with a modern slow function on users’ next login.

Scenario 2 — debugging a checksum mismatch: A build system reports a mismatch on a 64-character hex artifact hash. This tool tells you the hash is SHA-256 compatible, so you verify using sha256sum locally.

Scenario 3 — reading a legacy config file: An old application stores password hashes as $5$salt$...; this tool identifies that as sha256crypt, letting you set up the correct verification library.

What this tool does not do

  • It does not crack, reverse, or look up any hash. Identifying a format is the first step in a verification workflow, not an attack.
  • For salted or slow hashes (bcrypt, Argon2), the format identification is the most useful output — these cannot be reversed by any practical method.
  • All matching runs in your browser; the hash never leaves your device.