¿Qué factor de costo debería usar?

10-12 es un default común para aplicaciones web hoy, balanceando seguridad con velocidad de login aceptable. Valores más altos aumentan la seguridad pero también la carga del servidor — ajústelo a lo que su hardware pueda manejar en menos de ~250ms.

¿Por qué el hash se ve distinto cada vez que hasheo la misma contraseña?

Bcrypt genera automáticamente una sal aleatoria para cada hash, incrustada en el resultado mismo — esto es intencional y significa que dos hashes de la misma contraseña nunca van a coincidir byte por byte, pero ambos van a verificar correctamente.

Bcrypt Hash Generator

Password

Cost Factor (rounds)

Bcrypt Hash

How to use this bcrypt tool

Choose "Hash" to create a new bcrypt hash, or "Check" to verify a password against one.
For hashing, type a password and pick a cost factor (10 is a good default).
For checking, paste the password and the existing hash to compare.

Why is bcrypt slow on purpose?

Bcrypt's "cost factor" controls how many rounds of internal hashing it performs — deliberately slow, so that attackers trying millions of password guesses per second are significantly slowed down, unlike fast hashes like SHA-256 which are unsuitable for password storage.

What cost factor should I use?

10-12 is a common default for web applications today, balancing security with acceptable login speed. Higher values increase security but also server load — tune it to what your hardware can handle in under ~250ms.

Why does the hash look different every time I hash the same password?

Bcrypt automatically generates a random salt for every hash, embedded in the output itself — this is intentional and means two hashes of the same password will never match byte-for-byte, but both will still verify correctly.

Anatomy of a bcrypt hash string

A bcrypt hash isn't just a hash — it's a self-contained string that packs the algorithm version, cost factor, salt, and resulting hash all into one piece of text, typically starting with $2a$, $2b$, or $2y$ (identifying which bcrypt variant produced it), followed by the cost factor, then the salt and hash concatenated together and encoded in a bcrypt-specific base64 variant. This all-in-one format is exactly why bcrypt hashes are so portable: verifying a password against a stored hash requires no separate salt lookup or configuration, since everything needed to check it is embedded in the hash string itself — the verification function extracts the cost and salt from the hash before recomputing and comparing.

Why the cost factor scales exponentially, not linearly

Bcrypt's cost factor isn't a linear speed dial — each increment doubles the number of internal hashing rounds, since the actual round count is 2 raised to the cost factor. Going from a cost of 10 to 12 doesn't make hashing 20% slower, it makes it roughly 4 times slower, because 2^12 is four times 2^10. This exponential relationship is deliberate: it lets a fixed cost factor stay meaningfully secure even as hardware gets faster over time, since bumping the cost by just one or two points meaningfully raises the computational cost for anyone trying to brute-force a stolen hash, without dramatically increasing the delay for a single legitimate login.

Bcrypt's often-overlooked 72-byte password limit

Bcrypt silently truncates any password longer than 72 bytes — anything beyond that limit is simply ignored during hashing, which means a password with a long, unique suffix past the 72-byte mark hashes identically to the same password without that suffix. This rarely matters for typical passwords, which are well under the limit, but it becomes a real issue for passphrases (long strings of multiple words) or any password containing multi-byte Unicode characters, where 72 bytes can be reached with far fewer visible characters than expected. Some bcrypt implementations pre-hash the password with SHA-256 before bcrypt to sidestep this limit entirely; this tool follows the standard, unmodified bcrypt behavior, so it's worth being aware of the 72-byte ceiling if you're testing unusually long inputs.

Bcrypt vs. Argon2 and scrypt

Bcrypt dates to 1999 and remains widely considered acceptable for password hashing today, but it isn't the newest option. Its main limitation compared to more recent algorithms like Argon2 and scrypt is that bcrypt's cost is purely computational (CPU rounds) with no tunable memory requirement, which makes it somewhat more vulnerable to parallelized cracking attempts using GPUs or specialized hardware than memory-hard algorithms designed specifically to resist that kind of parallelization. Argon2 (winner of the 2015 Password Hashing Competition) is generally the current recommendation for new systems, but bcrypt remains a solid, battle-tested choice, especially for existing systems already built around it — the difference between them matters more for large-scale, well-resourced attackers than for typical threat models.

Limitations of this tool

This tool runs bcrypt hashing entirely in your browser using JavaScript, which means higher cost factors (12 and above) can take several seconds and may make the tab feel unresponsive while computing, since the deliberate slowness that makes bcrypt secure also makes it slow wherever it runs, including client-side. It's also worth treating any online tool, including this one, with appropriate caution when testing real production passwords — even though nothing here is transmitted anywhere and everything runs locally, it's generally better practice to test with placeholder values rather than actual user credentials whenever possible.