Hash Reverser

Crack MD5/SHA/NTLM/RIPEMD hashes by dictionary, brute force, and mask — multi-threaded

About Hash Reverser

This is a learning tool for recovering your own forgotten passwords or checksums and for seeing first-hand why some hashes are weak. Recovering the plaintext behind hashes you do not own can be illegal. Use it only on your own accounts and test data, or where you have explicit permission.

Hashes cannot be reversed mathematically, and this tool does not reverse them. It generates candidate strings, hashes each one, and checks whether the result equals the target. So whether it succeeds depends less on the algorithm than on whether the plaintext is among the candidates and how many candidates you must try. Everything runs in your browser and the hash is never uploaded.

What can and can't be recovered

The tool handles fast hashes: MD5, SHA-1, SHA-224/256/384/512, MD4, NTLM and RIPEMD-160. Because these can be computed millions of times per second, a short or common plaintext is found quickly and a long random one effectively never. What is weak is the plaintext, not the algorithm.

It deliberately does not handle bcrypt, scrypt or Argon2. Those are slow-by-design password-hashing functions: each guess costs so much time that trying candidates in bulk stops being practical. When a breached service's passwords hold up, this is usually why they were stored that way.

The tool guesses the algorithm from the hash length, but 32 characters (MD5, MD4, NTLM) and 40 (SHA-1, RIPEMD-160) are ambiguous. Auto-detection tries the most common first; pick one manually if you know it.

Why it's slower than a dedicated GPU tool

The hash functions are written in synchronous plain JS rather than the async crypto.subtle API, because the function is called so often per candidate that per-call overhead dominates. It also spins up one worker per CPU core and splits the search space among them.

Even so, a dedicated GPU tool is far faster: a GPU runs the same computation across thousands of cores and tests billions per second. The point of this tool is not peak speed but understanding the mechanism without the hash ever leaving your browser.

Why real systems add a salt

The tool lets you add a fixed string before or after each candidate and re-hash the result several times, because real systems store passwords that way — and it makes the effect of salting visible. An unsalted hash can be looked up in a precomputed table (a rainbow table) in one step, but a per-user salt makes such tables useless.

A per-user salt also means two people with the same password get different hashes. Salts are not meant to be secret — they are usually stored alongside the hash — their job is to stop one computation from cracking many accounts at once. The fact that you must supply the exact salt in this tool to reproduce a plaintext demonstrates that directly.

What the results actually teach

The more common and the shorter the password, the faster it falls. Inverted, that gives the recipe for a safe one: long, not in any dictionary, and not derivable from personal data (name, birthday, company). NIST SP 800-63B (2025 revision) recommends favoring length over composition rules (no forced mix of character types) and screening candidates against lists of breached passwords.

If the tool fails, that plaintext is effectively out of reach for this approach — which is exactly what a good password looks like. Generate a long random value with the site's password generator and no amount of running this tool will find it.

Worked examples

A short common password vs a long random one

Input: Two MD5 hashes: one of a common short word, one of a 16-character random string
Output: The first is found almost instantly by the dictionary pass; the second is not found even after the whole search range

A 16-character random string over ~87 symbols (upper, lower, digits, punctuation) has about 87^16 ≈ 3.4×10^30 combinations. Even at hundreds of millions per second, that outlasts the age of the universe.

Salt or no salt

Input: Hash the same plaintext with SHA-1 twice: once plain, once with a fixed prefix string
Output: The two digests are completely different; without the salt, brute force does not reproduce it

Only entering the exact salt in the prefix option reproduces the plaintext. That is why a salt is the first line of defense after a breach.

How to use it

Paste the hash to recover; the detected type appears below.
Leave the algorithm on auto-detect or pick one.
Choose dictionary, brute force, or a mask, and set a salt or iteration count if needed.
Run it. On success the plaintext appears; otherwise you get the number of attempts and "not found".

Key terms

Dictionary attack: Hashing a list of common weak passwords and words in turn and comparing. An option also tries common variations such as case changes and reversal.
Brute force: Trying every combination over a chosen character set, shortest first. The count grows exponentially with length, so long inputs are infeasible.
Mask (hashcat style): A pattern that fixes the character type per position: ?l lowercase, ?u uppercase, ?d digit, ?s symbol. Narrows the search when you know the plaintext's shape.
Rainbow table: A precomputed hash-to-plaintext table. A per-user salt defeats it.

Frequently asked questions

Aren't hashes irreversible?

Yes. This isn't a mathematical reversal; it hashes many candidates and looks for a match. Only weak or short plaintexts are realistically recoverable.

Why run it in the browser?

It's slow, but the hash never leaves your machine. It is far slower than a dedicated GPU tool.

Does it work on bcrypt hashes?

No. bcrypt, scrypt and Argon2 are slow by design, so this approach doesn't apply — which is precisely why real systems use them.

Can I recover someone else's hash?

Recovering a hash you don't own can be illegal. Use it only on your own data, with explicit permission, or for learning.

Related guides

How Password Storage Works: From Plaintext to Argon2

Sources

Last reviewed: 2026-09-22

Privacy and how data is handled