PassCheckup

Password Hash Generator & Verifier

Generate a password hash or verify a password against an existing hash, directly in your browser.

Processed locally in your browser. Your password is never sent to us.

Algorithm

Settings: m=19456 KiB (19 MiB), t=2, p=1, a 16-byte random salt and a 32-byte output.

How does this work?

  1. Runs in your browserHashing runs in a background worker inside this page.
  2. Not sent to PassCheckupPasswords and hashes aren’t sent to PassCheckup’s servers.
  3. Not storedNot stored in cookies, browser storage or analytics.
  4. Cleared when you leaveRefreshing or closing the page clears the fields.

Understand your hash

Password-hashing functions store their settings and salt inside the hash string, so a password can be checked later with exactly the same parameters. These are real hashes of the password example password, made with this tool’s default settings.

Argon2id
  1. AlgorithmArgon2id, a memory-hard password-hashing function (RFC 9106)
  2. VersionArgon2 version 1.3 (0x13), the current version
  3. Memory cost19,456 KiB (19 MiB) of memory per hash
  4. Time cost2 passes over that memory
  5. Parallelism1 lane
  6. Salt16 bytes, Base64 encoded
  7. Hash output32 bytes, Base64 encoded
bcrypt
  1. Algorithmbcrypt, revision 2b
  2. Cost2^12 = 4,096 iterations of bcrypt’s expensive key setup; each step up doubles the work
  3. Salt22 characters: 16 bytes in bcrypt’s own Base64 alphabet
  4. Hash output31 characters: 23 bytes in bcrypt’s own Base64 alphabet

What is password hashing?

Password hashing turns a password into a fixed-length value that can’t be turned back into the password. Services store this hash instead of the password itself.

Password-hashing functions such as Argon2id and bcrypt are deliberately slow and use a unique random salt for every password. If a database of hashes is stolen, every guess an attacker makes costs real time and, with Argon2id, memory.

This password hash generator creates Argon2id and bcrypt hashes, and its verifier checks whether a password matches a hash you already have, without sending anything to a server.

How does password verification work?

A hash string records the algorithm, its settings and the salt. To verify a password, the same function runs again on the entered password with the stored salt and settings. If the new result equals the stored hash, the password matches. That’s exactly what Verify does here.

Why can’t a password hash be decrypted?

Hashing isn’t encryption: there’s no key that reverses it. The only way to recover a password from its hash is to guess candidates and hash each one, which is what cracking means. Slow, salted hashing makes that guessing expensive. PassCheckup doesn’t crack, reverse or look up hashes.

Argon2id vs bcrypt vs PBKDF2

All three are designed for password storage, but they make guessing expensive in different ways and fit different situations. Current guidance, such as the OWASP Password Storage Cheat Sheet, lists Argon2id first.

  • Argon2idPreferred for new systems

    Winner of the 2015 Password Hashing Competition and specified in RFC 9106. It’s memory-hard: each hash needs a configurable amount of memory, which makes large-scale guessing on GPUs and specialized hardware more costly. This tool uses m=19456 KiB (19 MiB), t=2, p=1, one of the minimum configurations OWASP recommends.

  • bcryptWidely deployed

    Published in 1999 and supported by almost every platform and framework. Its cost is exponential: each step doubles the work. It uses only a small, fixed amount of memory and reads at most 72 bytes of the password. OWASP’s guidance places it after Argon2id and scrypt, mainly for existing systems, with a cost of at least 10. This tool defaults to 12.

  • PBKDF2Where FIPS-140 is required

    A NIST-approved key derivation function (SP 800-132) built on HMAC. It isn’t memory-hard, so it relies on a high iteration count: OWASP recommends 600,000 iterations for PBKDF2-HMAC-SHA256. PassCheckup doesn’t generate PBKDF2 hashes, because there’s no single standard string format for storing them, so a result here wouldn’t reliably work elsewhere.

scrypt is another memory-hard option, which OWASP recommends when Argon2id isn’t available. It isn’t offered in this tool.

What is a salt?

A salt is a random value generated separately for every password and stored alongside the hash. It isn’t secret. Because each password gets its own salt, two people with the same password end up with different hashes, and precomputed tables of hashes (rainbow tables) don’t work.

Argon2id hashes here use a fresh 16-byte salt from your browser’s cryptographic random number generator (crypto.getRandomValues). bcrypt always uses a 16-byte salt. That’s why hashing the same password twice gives two different hashes, and both verify.

What is a work factor?

The work factor, or cost, sets how much computation (and for Argon2id, how much memory) each hash takes. Higher settings slow down every guess an attacker makes, but also every sign-in, so services choose the highest cost they can afford and raise it over time. Argon2id has three settings: memory (m), passes (t) and parallelism (p). bcrypt has a single cost, where each step doubles the work.

Why shouldn’t SHA-256 alone be used for password storage?

SHA-256 is a fast general-purpose hash. Speed is useful for checking files, but bad for passwords: specialized hardware can compute billions of SHA-256 hashes per second, so stolen hashes of ordinary passwords can be guessed quickly, even with a salt. SHA-256 is fine as a building block, as in PBKDF2-HMAC-SHA256, but not on its own.

Browser-local limitations

Everything runs in this page. That keeps your password on your device, but it also means:

  • SpeedHashing speed depends on your device. A hash that takes half a second on one device can take several seconds on another.
  • LimitsTo keep the page responsive, Verify applies browser-safe limits to Argon2id memory, total work, passes and parallelism, and to bcrypt cost. Unusually demanding hashes require confirmation before they run, hashes beyond the tool’s limits are refused, and any job is stopped after 30 seconds.
  • ServersIt doesn’t replace server-side hashing. In a real system, the server hashes passwords with a maintained library. Use this tool to learn, test implementations, create test data or check whether a password matches a hash.
  • PepperA pepper is a secret key a server keeps outside its database and mixes into password hashing. It belongs on the server, so this tool doesn’t ask for one.
  • UnicodePasswords are hashed exactly as typed. Some systems normalize passwords (for example to Unicode NFC) before hashing, and the same-looking password can then produce different bytes. This tool never changes the password, and tells you when NFC normalization would make a difference.

Frequently asked questions

What is the best password-hashing algorithm?

For new systems, Argon2id is the usual recommendation: it’s listed first in the OWASP Password Storage Cheat Sheet and specified in RFC 9106. scrypt is a good alternative, bcrypt remains acceptable for existing systems with an adequate cost, and PBKDF2 is commonly used where FIPS-140 compliance is required. The settings matter as much as the algorithm.

Is bcrypt still secure?

bcrypt with an adequate cost (OWASP suggests at least 10) is still considered reasonable, especially in existing systems. Its limitations are that it isn’t memory-hard and only uses the first 72 bytes of a password. For new systems, Argon2id is generally preferred.

What is bcrypt’s 72-byte limit?

bcrypt reads at most 72 bytes of the password, counted in UTF-8. That’s 72 plain ASCII characters, but fewer if the password contains accented letters, other scripts or emoji, which take 2 to 4 bytes each. Many bcrypt implementations use at most the first 72 bytes of a password. PassCheckup shows the byte count and refuses passwords over 72 bytes for bcrypt instead of truncating them.

Can a password hash be decrypted?

No. Password hashing is one-way. A hash can only be attacked by guessing passwords and hashing each guess, which is why a slow, salted hash and a hard-to-guess password both matter.

Why not SHA-256?

SHA-256 is designed to be fast, so attackers can test enormous numbers of guesses. Storing passwords needs a deliberately slow, salted function such as Argon2id, bcrypt, scrypt or PBKDF2.

What is a salt?

A random value stored with each hash, so that identical passwords get different hashes and precomputed tables don’t work. It doesn’t need to be secret.

Why does the same password give a different hash each time?

Each hash gets a new random salt. The salt is stored inside the hash string, so every one of those hashes still verifies against the password.

Is my password sent to PassCheckup?

No. Hashing and verification happen in your browser, in a background worker on this page. Passwords and hashes aren’t sent to PassCheckup, stored in cookies or browser storage, or included in the page address.