Hash Generator
Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from any text.
Bcrypt Generator
Generate bcrypt password hashes and verify passwords against existing hashes — entirely in your browser. Choose the cost factor (work factor / rounds) to match your production setup. Nothing is sent to a server, nothing is logged. Useful for testing authentication code, generating seed data for migrations, and confirming that a stored hash matches the password your user typed.
Generate a Bcrypt Hash
Verify a Password Against a Hash
How to Use This Tool
- Choose hash or verify — pick whether you want to generate a new hash from a password, or check whether a password matches an existing hash.
- Set the cost factor — 10 is fast, 12 is the modern default, 14 is slow but stronger. Match the value used in your production code.
- Type or paste the password — bcrypt automatically generates a fresh random salt for every hash, so the output changes each time.
- Generate or verify — click the button. High cost factors take a moment; the hash appears in the output area below.
- Copy the result — click Copy to put the 60-character hash on your clipboard. Store the whole string; the salt is embedded inside it.
How Bcrypt Works
Bcrypt is built on the Blowfish cipher and uses an expensive key setup phase called eksblowfish. The work factor (or cost) controls how many iterations of this setup run before the actual hashing starts. Each increment of the cost factor doubles the time the algorithm takes — so cost 12 takes about twice as long as cost 11, and cost 14 takes four times as long as cost 12. This gives you a knob to slow the algorithm down as hardware gets faster, without changing the algorithm itself.
Unlike general-purpose hash functions like SHA-256, bcrypt produces a 60-character output that contains everything needed to verify a password against the hash later: the algorithm version, the cost factor, the salt, and the hash itself. Storing this single string is sufficient — there's no separate salt column or cost-factor column to manage. When verifying, the bcrypt library extracts the salt and cost from the stored hash, runs the same calculation on the supplied password, and compares the result.
Bcrypt's combination of a built-in salt and configurable slowness has kept it the workhorse of password hashing for over two decades. Newer algorithms like Argon2id offer memory-hardness as an additional defense against custom hardware attacks (GPUs, ASICs) — but bcrypt remains a perfectly acceptable choice for any application without nation-state-level attackers in the threat model. The most important decision isn't bcrypt vs Argon2; it's choosing any modern adaptive hash over fast hashes like SHA-256 or MD5.
Private by Design — Runs Entirely in Your Browser
This bcrypt generator hashes and verifies entirely in your browser, via a vendored copy of bcryptjs. The password or string you enter never leaves the page — nothing is uploaded to Janeer or any server. Since the entire point of bcrypt is protecting passwords, sending them to a remote service to hash them would defeat the purpose.
Pasting secrets into hosted tools or chatbots is a documented risk: in 2023 Samsung banned internal use of generative AI after engineers leaked confidential source code, and security firm Cyberhaven found that roughly 11% of the data employees paste into ChatGPT is confidential. Keeping the operation client-side means your data stays on your own machine.
Frequently Asked Questions
What is bcrypt and why use it for passwords?
Bcrypt is a password hashing algorithm designed by Niels Provos and David Mazières in 1999, based on the Blowfish cipher. Unlike fast hashes like SHA-256 or MD5 — which are designed to be quick — bcrypt is intentionally slow and includes a configurable cost factor that lets you make it slower as hardware gets faster. Slow hashing makes brute-force attacks (where an attacker tries billions of password guesses per second) impractical. Bcrypt also includes a built-in random salt for every hash, so identical passwords produce different hashes.
What cost factor should I use for bcrypt?
Cost factor 12 is the sensible default for most production systems on modern hardware — it produces a hash in roughly 250ms on a typical server, which is slow enough to deter brute-force attacks but fast enough that login latency stays acceptable. Cost factor 10 is the historical default and is still acceptable for most apps. Cost factor 14 doubles the work to about 1 second per hash, appropriate for high-value accounts where the extra latency is worth it. Each increment doubles the time. Re-hash existing passwords on the next successful login when you raise the cost factor.
What does a bcrypt hash look like?
A bcrypt hash is always exactly 60 characters and follows the modular crypt format:
$2a$12$abcdefghijklmnopqrstuv1234567890ABCDEFGHIJKLMNOPQRSTUVWXYz. The fields are: 2a (algorithm version — also 2b or 2y in some implementations), 12 (cost factor — the number of rounds), the next 22 characters (the salt, base64-encoded), and the last 31 characters (the hash itself, base64-encoded). You store this whole string in your database — there's no separate salt column needed because the salt is embedded in the hash.Is this generator safe to use with real passwords?
Hashing happens entirely in your browser using the bcryptjs library — no password is sent over the network or stored anywhere. The page contains no analytics scripts that capture form input. That said, treat any browser-based crypto tool the same way you'd treat any local utility: don't paste real production passwords into a tool you don't fully trust, prefer your application's own bcrypt implementation for production hashing, and use this tool for testing, development, seed data, and one-off verification.
Should I use bcrypt or Argon2 for new applications?
Argon2 (specifically Argon2id) is the modern recommendation for new systems — it won the Password Hashing Competition in 2015 and is memory-hard, which makes GPU and ASIC attacks much more expensive than against bcrypt. Bcrypt is still completely acceptable and widely supported; the difference matters most at the largest scales or against sophisticated attackers. If you're building a new app and your language has a good Argon2 library (most do), use Argon2id with reasonable parameters. If you're already using bcrypt with cost factor 12+, the migration cost rarely outweighs the benefit. Both are fine; PBKDF2 is also fine; SHA-256 alone is not.