Bcrypt Hash Generator

Bcrypt has been around since 1999, which in software years makes it practically ancient. Most things from 1999 have not aged well. Bcrypt is one of the exceptions. It was designed by Niels Provos and David Mazières specifically for password hashing at a time when most developers were still reaching for MD5 for the job, and its core design decision, making the cost of computation adjustable, turned out to be exactly the right property to build in.

This tool generates bcrypt hashes from any input, lets you configure the cost factor, verifies passwords against existing hashes, and extracts the salt from a hash string. Everything runs in your browser. Nothing leaves your device.

What Makes Bcrypt Different From General-Purpose Hash Functions

The distinction matters and it comes up constantly in security discussions, so it is worth being clear about.

General-purpose cryptographic hash functions like MD5, SHA-1, and SHA-256 are designed to be fast. They are appropriate for checksums, digital signatures, file integrity verification, and data deduplication. Speed is a feature in those contexts. For password storage, speed is a liability. A fast hash function means an attacker who obtains a database of hashed passwords can test billions of guesses per second using commodity hardware.

Bcrypt is slow by design and deliberately so. Its internal structure uses the Blowfish cipher and runs an expensive key setup phase called EksBlowfish. The cost factor you configure directly controls how many times that key setup runs, each increment doubling the computation time. At cost factor 10, hashing one password takes roughly 100 milliseconds on modern hardware. At cost factor 12, it is around 400 milliseconds. That fraction of a second is imperceptible to a legitimate user logging in. For an attacker attempting billions of guesses against a leaked database, that cost compounds into a practical barrier.

The MD5 Hash Generator and SHA-256 Hash Generator on this site are genuinely useful tools for their intended purposes: file checksums, data fingerprinting, non-security verification tasks. Using either for password storage is a different matter, and the distinction is worth keeping straight.

The Cost Factor: What It Is and How to Choose It

The cost factor is the single most important configuration decision when generating bcrypt hashes, and it is also the property that keeps bcrypt relevant as hardware gets faster.

Bcrypt uses a cost factor expressed as a power of two. A cost factor of 10 means the key setup phase runs 2^10 (1,024) iterations. A cost factor of 12 runs 2^12 (4,096) iterations. Each increment of one doubles the computation time. This is intentional. As CPUs and GPUs get faster year over year, you can increase the cost factor on new hashes to maintain the same effective security margin. Existing hashes remain valid and verifiable using their original cost factor, which is stored in the hash string itself.

Current practical recommendations hover around cost factor 10 to 12 for most web applications, though the right choice depends on your server hardware and acceptable authentication latency. The standard approach is to benchmark on your production environment and choose the highest cost factor that keeps authentication response time under an acceptable threshold, typically around 100 to 300 milliseconds. OWASP's current recommendation is a minimum cost factor of 10.

One thing bcrypt does not let you do is configure memory or parallelism the way Argon2 does. Its memory usage is fixed at 4 KB per computation, which is low enough that modern GPUs handle it comfortably at scale. This is bcrypt's main structural limitation compared to newer algorithms. It remains a solid and widely supported choice for existing systems, but for new implementations where you have freedom to choose, the Argon2 Hash Generator covers an algorithm with stronger resistance to GPU-based attacks.

Salt Extraction and Why Salts Matter

Every bcrypt hash includes an automatically generated random salt embedded directly in the hash string. This is not optional and it is not something you configure separately. It happens by design on every hash generation.

The salt exists to prevent precomputation attacks. Without unique salts, an attacker could precompute a massive table of common passwords and their hashes, then look up any matching hash in a database instantly. With a unique random salt per password, every hash is unique even if two users choose identical passwords. Precomputed tables become useless because the attacker would need to generate a separate table for every possible salt value.

The salt extraction feature in this tool lets you pull the salt value out of an existing bcrypt hash string. This is useful for debugging, auditing existing hash implementations, or understanding the structure of bcrypt output. In normal application use, you never need to handle the salt manually since bcrypt libraries manage it automatically.

The standard bcrypt hash string looks like this:

$2b$12$saltvaluehere.hashedoutputhere

The $2b$ prefix identifies the bcrypt version. The 12 is the cost factor. The next 22 characters are the base64-encoded salt. The remaining 31 characters are the hash. The whole string is self-contained. When you verify a password, the library reads the cost factor and salt directly from the stored hash string and recomputes the hash to compare. You do not store anything separately.

How to Use the Bcrypt Hash Generator

1. Enter the text you want to hash into the input field. For password hashing use cases, this is the plaintext password.
2. Set your preferred cost factor. A value between 10 and 12 is appropriate for most applications.
3. Click the generate button. The bcrypt hash appears in the output area instantly.
4. Copy the hash to your clipboard with one click, or download the output as a file.

For verification, switch to the verify mode, enter the plaintext password and the existing bcrypt hash you want to check it against, and the tool will confirm whether they match. This is useful for testing that your application is storing and verifying hashes correctly, or for validating hash output from different bcrypt implementations.

Everything is processed client-side. Your plaintext input and hash output never leave your browser.

Bcrypt in Real Application Contexts

Bcrypt is available in virtually every major programming language through well-maintained libraries. PHP has had native bcrypt support through password_hash() with PASSWORD_BCRYPT since PHP 5.5. Node.js has the bcrypt and bcryptjs packages. Python has bcrypt via pip. Ruby on Rails has used bcrypt as the default in has_secure_password since Rails 3. Java has Spring Security's BCryptPasswordEncoder. The algorithm is not going anywhere, and its library support reflects decades of production use.

One implementation detail worth noting: bcrypt truncates input at 72 bytes. Passwords longer than 72 bytes are treated identically to their first 72 bytes. For most real-world passwords this is not relevant, but if you are hashing arbitrary-length data or supporting very long passphrases, it is a limitation to account for. Some implementations pre-hash the input with SHA-256 before passing it to bcrypt to work around this, though that introduces its own considerations.

For teams managing credentials, access rules, or server configurations, keeping security tooling in one place has practical value. If you are also configuring server-level access rules alongside your password hashing decisions, the .htaccess Generator handles IP blocking, authentication headers, and directory access controls at the Apache configuration level, which complements application-layer password security rather than replacing it.

Frequently Asked Questions

What cost factor should I use for bcrypt?

OWASP recommends a minimum cost factor of 10 for most applications. In practice, choose the highest cost factor that keeps authentication response time under your acceptable threshold, typically 100 to 300 milliseconds on your production hardware. Benchmark first, then decide.

Is bcrypt still secure now?

Yes, bcrypt remains a solid choice for password hashing in existing systems. Its main limitation compared to newer algorithms is the fixed 4 KB memory usage, which is low enough for GPU-based attacks to scale more efficiently than against memory-hard algorithms like Argon2id. For new systems, Argon2id is the current best-practice recommendation. For existing bcrypt deployments, it remains acceptable at appropriate cost factors.

Does bcrypt have an input length limit?

Yes. Bcrypt processes a maximum of 72 bytes of input. Text longer than 72 bytes is silently truncated. For standard password use cases this is not typically a problem, but it is worth knowing if you are hashing long strings or arbitrary data.

Can I use the generated hash directly in my application?

The hash string this tool generates follows the standard bcrypt encoded format compatible with bcrypt libraries across all major languages. Use it for testing and verification. Production hashing should always happen server-side within your application using a trusted bcrypt library, not by copying hashes generated in a browser tool.

What is the difference between bcrypt and Argon2?

Both are password hashing functions designed to be slow and configurable. The main difference is that Argon2 adds configurable memory cost and parallelism, which makes it harder to attack with GPUs since high memory usage limits how many parallel hashes an attacker can compute simultaneously. Bcrypt's fixed 4 KB memory footprint does not impose the same constraint. Argon2id is the current OWASP first-choice recommendation for new systems.