How to store a password hash instead of the password

The table should not be able to show the password

If a row stores the password as the person typed it, anyone who can read that row can log in as them. A hash is a one-way stand-in. You can check a later guess against it. You cannot open the hash and read the password back.

Speed matters in the wrong direction. A fast checksum is a poor store for passwords because an attacker can try a huge number of guesses. Bcrypt is built to be slow on purpose. Each step up in cost doubles the work. The hash also carries a random salt, so hashing the same password twice produces two different strings, and both still verify. Two users who picked the same password do not get the same stored value.

For new systems, Argon2id is the current recommendation. This site's tool does not offer it. If you are already on bcrypt, or you need a hash your stack already verifies, the steps below match that tool. Measure cost on the server that will check logins. A hash you generated in the browser at a high cost can be slower or faster than the same cost on the machine that serves traffic.

Invent it, test it, then hash what you will keep

If you are choosing the password, use the Password Generator. It draws on the browser's secure random generator and shows strength in bits for the length and character sets you picked. Entropy describes how the password was generated. It says nothing about reuse. A long random password that you also use on another site is still one leak away from both accounts. Some sites reject symbols or cap the length. Turn symbols off or shorten the string if the form refuses it. The page does not save what it generated. Copy it into a password manager before you leave.

If the password already exists, or you want to see why a clever one is still weak, use the Password Strength Checker. It estimates how long a crack would take and flags common passwords, dictionary words, dates, repeats, and keyboard patterns. The check runs on your device. The password is not sent, stored, logged, or put in the address bar. Swapping letters for similar symbols, as in a pattern like p@ssw0rd, adds little, because cracking tools try those swaps. Length and randomness do more than a short string full of punctuation. A random 16-character password, or a passphrase of five or more random words, is the comparison the tool's own notes use.

Store the output of the Bcrypt Generator, not the password. On the Hash tab, set the cost and the prefix your platform expects, then copy the hash. Cost runs from 4 to 14. Cost 10 is the common default and runs the key setup 1,024 times. Cost 12 runs it 4,096 times and is a sound choice for many servers today. Pick the highest cost that keeps a login under about 250 to 500 milliseconds on your server. Browser timing will not match that machine.

The prefix is the version tag at the front. $2y$ is what you see from PHP password_hash(), Apache htpasswd -B, and Laravel. $2b$ is OpenBSD, Node, Python, and the current usual choice. $2a$ shows up in older libraries and Spring Security. The algorithm is the same. The prefix is how you line the string up with the verifier you already have.

A bcrypt hash looks like $2y$10$ followed by 53 characters: version, cost, a 22-character salt from 128 random bits, then 31 characters of hash. Only the first 72 bytes of the password are used. Longer input is cut, and the tool warns you. Verifying takes the salt and cost out of the stored hash, hashes the candidate again, and compares. You can do that on the Verify tab. Hashing runs in a background worker so a high cost does not freeze the tab. Nothing is uploaded.

Do not put a real user's password into a shared or logged machine to "try the hash." Generate and verify test values. On the server, store only the hash string the library returns.