Hash Identifier
Found a hash in a config file, a database dump, or a CTF? The fastest first step is identifying what produced it. The live identifier supports 90+ formats - link to it below.
Open the hash identifier
Stop comparing the string against a wiki table by eye. Paste it into the live hash identifier and it checks length, alphabet and structure against 90+ formats - MD5, SHA-1, SHA-256, bcrypt, scrypt, NTLM, WordPress, Argon2 and the rest - then returns the most likely candidates along with why each one matched. It's free, there's no signup, and it starts matching the moment you paste.
Below is what the tool is actually checking, and what to do once you have a name for your hash.
What is a hash, in 30 seconds
A hash is a one-way function. Feed it any input - a password, a file, a whole database - and you get back a fixed-length fingerprint. The same input always produces the same fingerprint, but the fingerprint can't be reversed to recover the input. That's by design, not limitation.
That's why sites store hashes instead of plaintext passwords: a database dump shouldn't hand over usable credentials. Except attackers still want those dumps. People pick predictable passwords, and a stolen hash can be attacked offline at attacker speed - no lockouts, no rate limits, forever.
So you can't 'decrypt' a hash. There's no key to unlock it and no reverse gear. What you can do is identify it: every algorithm leaves a recognizable shape in its output. Name the algorithm and you know exactly how much trouble you're in.
How identification works
Identification is pattern-matching on three signals: length, alphabet and structure. The identifier automates exactly this checklist.
Length
Length alone eliminates most candidates. 32 hexadecimal characters (0-9, a-f) points at the MD5 family - which also covers NTLM and MD4. 40 hex characters is SHA-1. 64 is SHA-256, 96 is SHA-384, 128 is SHA-512. 16 hex characters is the old pre-4.1 MySQL algorithm, or a truncated MD5 someone cut in half.
Alphabet
Hex-only output means the MD/SHA/NTLM world. A string with mixed case, digits, + and / is probably Base64-encoded output, common in modern frameworks and .htpasswd-style files. A single character outside 0-9a-f rules the hex candidates out immediately.
Structure
Structured prefixes are the loudest signal. In practice you'll meet:
- $2a$, $2b$ or $2y$ followed by a cost factor - bcrypt, 60 characters total
- $argon2i$ or $argon2id$ - Argon2
- $P$ or $Q$ - WordPress and phpass portable hashes
- $S$ - Drupal 7 and later; $H$ - older Drupal
- $1$, $5$ or $6$ - Unix crypt: MD5, SHA-256, SHA-512
- * followed by 40 uppercase hex characters - MySQL 4.1 and later
Two hashes with the same structure can still differ in strength - a bcrypt hash at cost 04 falls far faster than one at cost 12 - but the prefix tells you which family of attacks applies at all.
Common hashes you'll actually meet
MD5 (32 hex characters). Everywhere in legacy applications, CTF challenges and file checksums. Fast to compute - trivially cracked as a password hash.
SHA-1 (40 hex). Older signatures and document fingerprints. Same fast-hash weaknesses as MD5; treat it the same way.
SHA-256 (64 hex). The modern default for integrity: TLS certificates, blockchains, download checksums. A fine fingerprint, still the wrong tool for passwords.
bcrypt ($2b$). The current password-hashing workhorse - slow by design, with a tunable cost factor that limits an attacker to dozens of guesses per second per core instead of billions.
NTLM (32 hex, usually uppercase). Windows' domain credential format and the main prize in Active Directory dumps, which is why it shows up constantly in internal engagements.
WordPress. Old wp_users tables store plain unsalted MD5; anything modern is a phpass portable hash starting $P$. An MD5 sitting in a WordPress users table is a password hash, not a checksum.
MySQL. Pre-4.1 databases use a weak 16-hex hash; 4.1+ stores a SHA-1-based value as * plus 40 hex. If you found the latter in a config backup, that's a live credential.
Joomla and Drupal. Joomla leans on phpass $P$ hashes, Drupal on $S$ since version 7. Both are migrating toward bcrypt and Argon2 on current releases.
Identified it - now what?
If you named a fast hash - MD5, SHA-1, NTLM, raw SHA-256 - assume it's crackable. A consumer GPU runs billions of guesses per second against those: any dictionary password or rule mutation falls in minutes, and short random ones follow. The arsenal covers how those attacks actually run, including hashcat and John the Ripper cheat sheets; to check one specific password instead, run it through the password breach checker.
If it's bcrypt, scrypt or Argon2, that's the good news. They're expensive on purpose, tuned to cost an attacker real time and power per guess. A leaked bcrypt hash is still a leak - but it doesn't crack at GPU speed.
Either way, rotate the credential. Identification tells you how exposed you were, not whether you're safe. The hash proves that password was correct at some point - treat it as burned and force a reset.
Where to go next
Keep going: browse the rest of the free tools, work through the offensive cheat sheets in the arsenal, or check a password directly with the breach checker. If you found these hashes in your own database during a migration or cleanup, a web application penetration test will verify what else is exposed - or just contact me and describe what you've got.
Hash questions
Yes, if it comes from your own systems or an engagement you're authorized to run - that's standard work in a penetration test. I confirm scope and authorization first, then test how crackable the hash really is with dictionaries, rules and GPU brute force. For a random hash you found on the internet, no - I only work on systems I'm authorized to assess.
No. Identification tells you which algorithm produced the hash by matching its length, alphabet and structure - that's pattern recognition. Decrypting would mean reversing it back to the original input, which is impossible by design: hashes are one-way functions with no key and no reverse gear. The only way to recover a fast hash is guessing inputs and comparing outputs, and that's cracking, not decryption.
Because modern algorithms salt each password: a unique random value is mixed in before hashing, so identical passwords store as completely different strings. Salting defeats precomputed rainbow tables and stops attackers from spotting shared passwords at a glance. That's also why two bcrypt hashes of the same password look nothing alike.
A salt is a random value added to a password before it's hashed, stored next to the hash so the server can repeat the same computation at login. Salts don't need to be secret - their job is uniqueness. Each salted hash is one of a kind, so precomputed tables don't work and the same password never hashes the same way twice. A pepper - a secret key kept outside the database - adds another layer on top.
Treat them as compromised and assume whoever extracted them has had time to attack them. Rotate the affected passwords from a clean device, force resets for your users, revoke existing sessions, and review access logs around the time of exposure. Then move storage to a slow, salted algorithm - Argon2id, bcrypt or scrypt - and if you need to know how weak the old ones were, I can assess that.
Found credential hashes in your own systems?
Let me verify how crackable they really are - before someone else does.