Hashes/Crypto
Bcrypt Hash + Verify
Hash passwords with bcrypt (random salt, adjustable cost) and verify a password against an existing bcrypt hash.
Bcrypt is a deliberately slow password-hashing algorithm: unlike MD5 or SHA-256, it intentionally requires heavy computation so that brute-forcing passwords stays impractical even if a database of hashes leaks.
How to use it
- Hash: enter a password and set a cost factor — a higher number means slower, more secure hashing.
- Every hash call generates a fresh random salt, so the same password produces a different hash each time — that's expected and normal.
- Verify: paste a password and an existing bcrypt hash to check whether they match, without hashing manually yourself.
Common uses
- Manually checking that a backend hashes passwords correctly before storing them.
- Generating a test bcrypt hash for seed data or fixtures during development.
- Debugging a failed login by comparing an entered password against the stored hash.
Things to keep in mind
Pick a cost factor that keeps hashing around 100-300ms on your target server — a balance between security and login-time load.
Bcrypt truncates passwords longer than 72 bytes — characters beyond that limit are ignored by the algorithm.
Article about this tool: Bcrypt: why passwords are hashed slowly, not quickly
Frequently asked questions
Why does bcrypt include a "cost" or "rounds" factor?
The cost factor controls how many times the hashing is repeated internally, so hashing gets exponentially slower as it increases. This lets you deliberately keep it slow enough to resist brute-force attacks even as hardware gets faster.
Why is the bcrypt hash always the same length regardless of my password?
Bcrypt outputs a fixed-length hash (typically 60 characters) that encodes the algorithm version, cost factor, salt, and hash together — the length doesn't depend on how long or short the original password was.
Does bcrypt need a separate salt field?
No. The salt is generated automatically and embedded directly in the output string, so you don't need to store or manage it separately — it's included whenever you verify a password against the hash.
Is there a limit on password length in bcrypt?
Yes, bcrypt only processes the first 72 bytes of a password — anything beyond that is silently dropped without warning. In practice this is rarely an issue, but it's worth remembering when working with very long passwords or non-ASCII characters, where one character can take up multiple bytes.
Why is bcrypt still recommended if Argon2 exists?
Bcrypt has been battle-tested for decades, is widely supported across every language and framework, and remains a perfectly solid choice. Argon2 is recommended as the priority pick for new systems due to its resistance to GPU/ASIC attacks, but bcrypt isn't considered unsafe — just less resistant to specialized hardware.