What cost factor should I use?

OWASP recommends cost 12 as the minimum for new applications targeting modern server hardware, targeting roughly 100-300 ms per hash. Increase the cost factor every two to three years as hardware improves. Use cost 6-8 only for development and testing.

Free Bcrypt Hash Generator

Hash any password with bcrypt and verify existing hashes — choose your cost factor, inspect the full hash anatomy, and run everything in your browser. Your password never leaves your device.

Password to Hash

Cost Factor (Work Factor)

12 ~300 ms

6 (fastest) 8 10 12 ✓ 14 (slowest)

Hashing… higher cost factors take longer by design

Your Bcrypt Hash

All hashing runs in your browser via bcryptjs — your password never leaves your device.

Password never leaves your device Powered by bcryptjs Nothing ever sent to a server

Hash Anatomy — Understand Your Bcrypt Hash

Show

Generate a hash above to see a full breakdown of each section.

Cost Factor Reference — Which Value Should I Choose?

Show

Cost	Iterations (2ⁿ)	~Time on modern server	Recommendation
6	64	~1 ms	Dev / test only
8	256	~5 ms	Low-power devices only
10	1,024	~100 ms	Acceptable minimum
12	4,096	~300 ms	Recommended ✓
13	8,192	~600 ms	High-security accounts
14	16,384	~1.2 s	Highest security

Each cost increment exactly doubles compute time. OWASP recommends cost 12 as the minimum for new applications. Reassess every two years as hardware improves — target 100–300 ms on your production server. For creating strong passwords to hash, use our Password Generator and check robustness with our Password Strength Checker.

Password never leaves your device

Instant for cost 6–10; seconds for 12–14

Free, no sign-up needed

What This Bcrypt Hash Generator Does

Switch between two modes using the tabs. Hash a Password takes any input, generates a cryptographically random 128-bit salt, runs bcrypt at your chosen cost factor, and displays the resulting 60-character hash in the dark output panel — ready to paste directly into a database column or configuration file. Verify a Hash accepts a plaintext password and an existing bcrypt hash, extracts the embedded salt, re-runs bcrypt, and tells you whether the outputs match. Both operations run entirely using the bcryptjs library loaded in your browser; nothing is ever transmitted to any server.

The Hash Anatomy card breaks down every section of a generated hash — algorithm variant, cost factor, salt and hash output — with colour coding and explanations. The Cost Factor Reference table shows the relationship between cost values, iteration counts, approximate hash times and OWASP recommendations, so you can choose the right value for your production environment. All slider changes and mode switches are instant; only the actual hashing step takes time at higher cost factors.

Tips for Getting the Best Results

Use cost 12 as your starting point for any new production application targeting modern server hardware. This produces roughly 300 ms hash times — slow enough to defeat brute-force attacks, fast enough not to noticeably delay login on a typical web request.
Use cost 6–8 only in development and testing where you need fast iteration. Never deploy cost 6 or 7 to production — they provide insufficient protection against GPU-accelerated dictionary attacks on a compromised database.
Remember that bcrypt silently truncates input at 72 bytes. Passwords longer than 72 characters produce the same hash as their first 72 characters. For typical passwords generated by our Password Generator (16–32 characters) this is never an issue.
Always store the entire 60-character bcrypt string in your database — it contains the algorithm, cost factor, salt and hash in one self-contained string. Your verification call only needs this string and the candidate password; you never need to manage salts separately.
Use the Verify tab to test your application's bcrypt integration — generate a hash here, then confirm your library's compare function accepts it. Or paste a hash produced by your application and verify it against the original password to confirm your setup is working correctly.
After hashing, check the generated hash in the Hash Anatomy card to confirm the cost factor and salt section are correct before deploying your configuration.

Frequently Asked Questions

What is bcrypt and why is it the right choice for password hashing?

Bcrypt is a password hashing function designed in 1999 by Niels Provos and David Mazieres specifically to be slow and computationally expensive — properties that are a deliberate feature, not a bug. Unlike general-purpose cryptographic functions such as SHA-256, which can process billions of inputs per second on a GPU cluster, bcrypt is limited to roughly 20 hashes per second at cost 12 on the same hardware. That is a 500-million-times slowdown for an attacker, which effectively defeats brute-force and dictionary attacks even when a database is completely compromised.

Bcrypt also generates and embeds a unique 128-bit salt automatically on every call, meaning identical passwords always produce different hashes and precomputed rainbow tables are useless against any bcrypt-protected database. The combination of intentional slowness, automatic salting and a self-contained output format — which stores the algorithm, cost, salt and hash in a single 60-character string — makes bcrypt one of the most widely deployed and well-understood password protection mechanisms in production use today. For creating the strong passwords you then hash with bcrypt, our Password Generator uses crypto.getRandomValues() to produce credentials an attacker cannot guess. Check any existing passwords with our Password Strength Checker before deciding whether they need rotation.

What does the cost factor actually do under the hood?

The cost factor (also called the work factor) is an exponent: bcrypt runs exactly 2^cost internal key-schedule iterations. At cost 10 that is 1,024 iterations; at cost 12 it is 4,096; at cost 14 it is 16,384. Each additional cost unit precisely doubles the time required to compute a single hash — on your server and on any attacker's machine simultaneously. This is why cost is the right lever for keeping password hashing secure as hardware improves: you can increase it without changing any stored hashes or breaking any existing verified passwords.

OWASP's 2024 recommendation is cost 12 as the minimum for new applications targeting modern server hardware, targeting roughly 100–300 ms per hash. The correct long-term strategy is to increase the cost factor every two to three years as CPU and GPU performance improves, maintaining hash time in that target window. Stored hashes do not need immediate migration — you can transparently upgrade on each successful login by re-hashing the verified password at the new cost factor before saving. The algorithm, cost and salt are all embedded in the stored hash string, so your verification code always uses the correct cost for each individual hash regardless of when it was generated.

How do I read a bcrypt hash — what does each section mean?

A bcrypt hash like $2b$12$SaltSaltSaltSaltSaltS.HashHashHashHashHashHash is entirely self-describing and contains everything needed to verify a password against it. The $2b$ prefix identifies the bcrypt algorithm variant — 2b is the current standard, correcting an obscure edge-case bug present in the earlier 2a implementation. The two-digit number after the second dollar sign is the cost factor in decimal. The following 22 characters are the Base64url-encoded salt (128 bits of random data). The final 31 characters are the bcrypt hash output itself. The total string is always exactly 60 characters for $2b$ hashes.

Because the salt is embedded in the hash string, you never need to store or manage it separately in your database. Your application saves the entire 60-character string in a single column, and at verification time passes both the candidate plaintext password and the stored hash string to bcrypt.compare() — the library extracts the salt from the hash automatically, re-runs bcrypt with the same parameters, and compares the outputs in constant time. Click Generate on this page and expand the Hash Anatomy card to see a colour-coded breakdown of every field in the output hash.

How is bcrypt different from SHA-256 or MD5 for storing passwords?

MD5 and SHA-256 are fast cryptographic hash functions built for speed — their design goal is maximum throughput. A modern GPU cluster can compute over 100 billion MD5 hashes per second and over 10 billion SHA-256 hashes per second. This makes dictionary attacks against an unsalted or weakly-salted SHA-256 password database catastrophically fast: every common English word, name, date, and known-leaked password can be tested in seconds. Even with a per-user salt, a fast hash function still allows an attacker to try billions of guesses per user per second after obtaining a database dump.

Bcrypt at cost 12 reduces that same GPU to around 20 hashes per second — slowing the attacker by a factor of hundreds of millions. This means cracking a single strong random password becomes computationally infeasible. Never use fast hash functions for password storage: use bcrypt, Argon2id or scrypt. Fast hash functions are entirely appropriate for non-password use cases — file integrity checking, content fingerprinting, HMAC generation, and data deduplication — where an attacker has no incentive to precompute guesses. Our Hash Generator covers MD5, SHA-1, SHA-256, SHA-384 and SHA-512 for all those legitimate fast-hashing tasks.

Why does bcrypt produce a different hash every time for the same password?

Every bcrypt hash call generates a fresh cryptographically random 128-bit salt, encodes it as the 22-character section of the output string, and incorporates it into the key schedule before hashing. This means running this tool twice on the exact same password produces two entirely different 60-character strings — yet both are valid and both will return true when verified against the original password, because the salt tells bcrypt exactly how to reproduce the hash for verification.

The design intent is two-fold. First, it prevents an attacker who captures a database from knowing which users share the same password — since every hash is unique, identical plaintext passwords look completely different in the database. Second, it renders precomputed rainbow tables completely useless, because every hash has a unique salt that the attacker could not have included in any precomputed table. Verification works correctly because the embedded salt is extracted from the stored hash string and fed back into bcrypt along with the candidate password; if the outputs match, the candidate is the original password.

Does bcrypt have a password length limit I need to know about?

Yes — this is one of the most important practical constraints of bcrypt. Most bcrypt implementations, including the bcryptjs library used by this tool, silently truncate input at 72 bytes. A password longer than 72 characters produces exactly the same hash as its first 72 characters, with no error or warning. For the vast majority of applications this is irrelevant: passwords generated by our Password Generator are typically 16–32 characters and never approach the limit. Users choosing their own passwords rarely exceed 72 characters either.

If your application must support arbitrary-length passphrases securely — for example, a password manager that allows multi-sentence master phrases — the standard mitigation is to SHA-256 the password first (producing a fixed 32-byte output that fits within bcrypt's input window) and then pass those bytes to bcrypt. This preserves the full entropy of any length passphrase while remaining compatible with bcrypt's 72-byte constraint. Note that SHA-256 is used here purely for length normalisation — it is not providing security on its own. Bcrypt still provides the actual slow-hashing protection, and the combined approach is safe and well-established in production systems.

Should I choose bcrypt, Argon2id or scrypt for my application?

All three are appropriate choices for production password hashing — the most important decision is to use any one of them rather than a fast hash function. The current OWASP recommendation for new projects prioritises Argon2id with a minimum of 19 MiB of memory, two iterations and one degree of parallelism. Argon2id won the 2015 Password Hashing Competition and is memory-hard: attackers need vast amounts of RAM as well as CPU time, making GPU and custom ASIC attacks far less practical than against bcrypt, which is CPU-bound but not memory-hard.

Bcrypt has an outstanding 25-year track record in production, is natively supported as a first-class function in virtually every language and framework (PHP's password_hash(), Python's bcrypt library, Node's bcryptjs and bcrypt, Ruby's bcrypt gem, Java's Spring Security, and many others), and remains fully secure against all known practical attacks when used at cost 12 or higher. If you are starting a new project and have the option, Argon2id is the stronger theoretical choice. For any existing bcrypt deployment, periodically increasing the cost factor is simpler and safer than a full algorithm migration, which would require re-hashing all passwords at the next successful login and maintaining backward compatibility during the transition period.

Can I use this tool to test my application's bcrypt integration?

Yes — testing your integration is one of the most practical uses of this tool. Generate a hash from a known test password at the cost factor your application uses, paste the result into your application's verification call, and confirm it returns a match. This confirms that your bcrypt library is correctly parsing the $2b$ format and extracting the salt. Equally, if your application generates bcrypt hashes, you can paste one into the Verify tab alongside the original password to confirm your library's hash output and cost configuration are working correctly without needing to instrument your server-side code.

Since everything runs client-side in your browser, there is no privacy concern using test credentials here. For production passwords, this tool is technically safe — nothing ever leaves your browser — but the best practice for production is to hash server-side in application code where your security controls, audit logging and key management infrastructure are in place. Use our Secure Token Generator to create the API keys and session tokens that accompany your bcrypt-protected user credentials, and our UUID / GUID Generator for the unique database identifiers that identify each user record.

How should I store bcrypt hashes in my database?

Store the complete 60-character bcrypt string in a single column — it is entirely self-contained. The recommended column type is CHAR(60) or VARCHAR(60) in SQL databases, since the bcrypt output is always exactly 60 characters for $2b$ hashes. Never split the hash into separate columns for algorithm, cost, salt and hash — the standard format keeps all components together, and every bcrypt library expects and produces the unified format. If you are planning for future algorithm migration to Argon2id, use VARCHAR(255) to accommodate longer output strings from other algorithms without a schema change.

Never store the original plaintext password alongside the hash — the entire point of hashing is to make the plaintext unrecoverable from your database. Never log the plaintext password during any step of the hash or verify workflow. Never transmit the hash to the client — it should exist only server-side in your database and application memory during the verification step. Index the user identifier (email, username) rather than the hash itself; since every bcrypt hash is unique even for identical passwords, indexing the hash would provide no lookup performance benefit and would only add storage overhead.

What is constant-time comparison and why does bcrypt verification use it?

A timing attack exploits measurable differences in how long a comparison takes to reveal information about the secret being compared. A naive string comparison like storedHash === submittedHash returns false as soon as it finds the first differing character — meaning a comparison that fails at character 50 takes slightly longer than one that fails at character 1. An attacker who can make thousands of verification requests and measure response times can use these timing differences to deduce, character by character, what the stored hash value is, eventually recovering it without ever needing the plaintext password.

Bcrypt verification avoids this by always running the complete bcrypt computation on the submitted password — re-hashing it with the embedded salt — before comparing the outputs. Since both the stored hash and the recomputed hash go through the same slow bcrypt operation, the comparison itself is not the bottleneck, and timing differences cannot be used to infer the stored value. Well-implemented bcrypt libraries additionally use constant-time string comparison for the final output check. This is one reason why you should always use a library's built-in bcrypt.compare() function rather than hashing the input and comparing the result manually with a standard equality operator.