BCrypt Hash: what it does and how to use it

Almost every hashing algorithm is designed to be fast. BCrypt is deliberately slow, and that inversion is the entire point. When an attacker steals a password database, their attack is offline and unlimited - they can try billions of guesses per second against a fast hash like SHA-256. Making each hash take a measurable fraction of a second reduces that to thousands, which turns a few hours of cracking into years. The cost factor controls how slow: each increment doubles the work, so 12 is roughly four times slower than 10. BCrypt also salts automatically, which is why hashing the same password twice produces two different outputs - and why precomputed rainbow tables are useless against it. The verify function is what checks a login, because it extracts the salt from the stored hash and recomputes. Note this tool processes on the server, so use test passwords rather than real credentials.

You should not have to open an IDE to format a snippet from Slack, tidy a JSON blob, or check a hash. Paste it here, copy the result, move on.

BCrypt Hash is a good fit when understanding how BCrypt hashes are structured while implementing authentication.

The useful part

BCrypt Hash is built around a few practical wins, not a long feature list:

• Deliberately slow, which is exactly what makes offline cracking impractical.
• Salting is automatic and stored inside the hash, removing a whole class of implementation mistakes.
• Adjustable cost factor, so the hash can be strengthened as hardware gets faster.
• Verify mode included, for testing that a password matches an existing hash.
• No account and no limit.

Do this, in order

1. Enter a password to hash. Use a test value. This runs server-side, so real credentials should not be pasted here.
2. Choose a cost factor. 12 is the current sensible default. Each increment doubles the computation time.
3. Generate the hash. The salt is included in the output string, which is why no separate salt column is needed.
4. Use verify to check a match. Verification extracts the salt from the hash and recomputes - you never compare hashes directly.

Who it is for

• Understanding how BCrypt hashes are structured while implementing authentication.
• Generating a test hash for a development database seed.
• Verifying that your application produces the hash you expect.
• Comparing cost factors to choose one for production.
• Learning why password hashing differs from general-purpose hashing.

If you want a clean result

• Use a cost factor of 12 or above for new systems. Recalibrate over time - what was slow enough in 2015 is not in 2026.
• Never store a separate salt. BCrypt embeds it in the hash string, and a hand-rolled salt column usually signals a misunderstanding.
• Always compare with the verify function, never with string equality on two hashes - the salts differ, so equality is always false.
• BCrypt truncates input beyond 72 bytes. That matters for very long passphrases, which is one reason Argon2 is often preferred now.
• For new systems, Argon2id is the current recommendation. BCrypt remains a perfectly reasonable choice and is far better than a fast hash.

Common mix-ups

• Using MD5 or SHA-256 for passwords. They are fast by design, which is precisely the wrong property here.
• Comparing two BCrypt hashes directly and concluding the password is wrong - different salts guarantee different hashes.
• Choosing a low cost factor to keep logins snappy, which hands attackers a much cheaper offline attack.
• Adding your own salt column, which suggests the embedded salt was not understood.
• Pasting production passwords into any online tool, including this one - it processes server-side.

Private by default

BCrypt Hash needs the ToolBox API for work a browser cannot do. What you submit is processed, then discarded. It is not kept as a library of your files.

Related tools worth opening next

If this is one step in a longer job, these usually come after it:

• Argon2 Hash - Generate and verify Argon2 hashes
• SHA-256 Hash - Generate SHA-256 hash from text or files
• MD5 Hash - Generate MD5 hash from text or files

Before you ask

Why use BCrypt instead of MD5 or SHA-256 for passwords?

BCrypt is deliberately slow and includes a built-in salt, making it far more resistant to brute-force and rainbow-table attacks than fast general-purpose hashes like MD5/SHA-256, which were never designed for password storage.

Will hashing the same password twice give the same result?

No - BCrypt includes a random salt each time, so the same password produces a different hash output every time it's hashed. This is intentional and is what makes it resistant to precomputed rainbow-table attacks.

Is it safe to test real user passwords in this tool?

No - use test values. BCrypt hashing is computationally heavy by design and runs on the server here, so the password you type is transmitted. It is not stored, but real production credentials should never be pasted into any third-party tool regardless.

What cost factor should I use?

12 or above for new systems. Each increment doubles the work, so the right number is whatever keeps login times acceptable on your hardware while making offline cracking expensive - and it should be raised over the years as hardware improves.

Why do two hashes of the same password not match?

Because BCrypt generates a random salt each time and embeds it in the output. That is deliberate - it defeats rainbow tables. Always check a password with the verify function, which reads the salt back out of the stored hash.

Should I use BCrypt or Argon2 today?

Argon2id is the current recommendation for new systems, mainly because it resists GPU and custom-hardware attacks better and has no input length limit. BCrypt remains a solid, widely-supported choice and is vastly better than any fast hash.

Open the BCrypt Hash when you are ready. It is free, and you do not need an account.