Skip to content
MyDevToolbox

Bcrypt / Argon2 Validator

Server-side

Hash and verify passwords with bcrypt and Argon2.

Processed securely on our server · Inputs are saved only in this browser, if you allow it

Generate a hash

Each +1 doubles the time. 10–12 is a common choice; aim for ~250 ms on your servers.

Verify a password

🔒 Passwords are sent over HTTPS, processed in memory and never logged or stored. Avoid pasting real production passwords into any online tool.

Why passwords need a special kind of hash

Fast hashes such as SHA-256 are great for checksums but terrible for passwords: a modern GPU computes billions of them per second, so a leaked database of fast hashes can be brute-forced quickly. bcrypt and Argon2 are deliberately slow, salted password-hashing functions. Each hash includes a random salt and its cost parameters, so identical passwords produce different hashes and you can raise the cost over the years as hardware gets faster.

bcrypt or Argon2id?

  • Argon2id won the Password Hashing Competition and is the first choice in the OWASP Password Storage Cheat Sheet. Its memory cost makes GPU and ASIC attacks expensive. A good starting point is 19–64 MiB of memory, 2–3 iterations and parallelism 1–4.
  • bcrypt is battle-tested and available everywhere. Use a cost factor of at least 10 (12 is common) and remember that it only looks at the first 72 bytes of the password – this tool warns you when you exceed that limit.

Reading a hash

A bcrypt hash such as $2b$12$… stores the version (2b) and the cost (12) before the salt and digest. An Argon2 hash such as $argon2id$v=19$m=65536,t=3,p=4$… stores the variant, version, memory in KiB, iterations and parallelism. The verifier detects the algorithm automatically and shows these parameters.

Practical examples

  • Debug a login bug: paste the hash from your database and the password from your test account to confirm whether the problem is the stored hash or your application code.
  • Seed a test database: generate a hash for a fixture user without writing a script.
  • Tune your cost: watch the reported time and pick parameters that take roughly 250 ms on your hardware.

Security and privacy

Hashing runs on our server because these algorithms need native, constant-time implementations. Requests travel over HTTPS, are processed in memory and are never logged or stored, and responses are marked as non-cacheable. Parameters are capped and requests are rate-limited to protect the service. Even so, treat any online tool as untrusted for real production passwords: use test credentials whenever possible.