Free Password Hasher

Password hashing is a one-way function that turns a password into a fixed-length string. Unlike encryption it cannot be reversed: a login is checked by hashing the attempt with the same salt and parameters and comparing the results. Password hashes are deliberately slow and, for Argon2 and scrypt, memory-hard, so guessing is expensive.

Argon2id, per OWASP’s Password Storage Cheat Sheet, with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism. Where Argon2 is unavailable use scrypt (N=2^17, r=8, p=1), then bcrypt with a cost of 10 or more. Use PBKDF2 (600,000 iterations with HMAC-SHA-256) only when FIPS 140 compliance requires it. Never use MD5, SHA-1 or a plain SHA-2 digest for passwords.

MD5 produces a 128-bit digest (32 hex characters) and is cryptographically broken: collisions can be made in seconds. SHA-256 produces a 256-bit digest (64 hex characters) and is still secure for integrity and signatures. Both are fast by design, which is exactly why neither should be used alone to store passwords.

A salt is a random value, unique to each password and stored alongside the hash, so identical passwords produce different hashes and precomputed rainbow tables are useless. bcrypt, Argon2 and scrypt generate and embed it automatically. A pepper is a secret shared by all passwords but kept outside the database, in configuration or a secrets manager, and applied with HMAC; a leaked table alone then cannot be cracked.

The cost is the base-2 logarithm of the number of key-expansion rounds: cost 10 is 2^10 = 1,024 rounds and each step up doubles the time. OWASP recommends a cost of 10 or more; choose the highest your login latency allows. Note that bcrypt reads only the first 72 bytes of a password, which this tool warns about.

They are version labels for bcrypt. $2a$ is the original; $2b$ (OpenBSD, 2014) fixed how long passwords wrap; $2y$ is PHP’s label for the same corrected algorithm. $2x$ marks hashes made by the pre-2011 implementation with the 8-bit character bug and should be rehashed. $2a$, $2b$ and $2y$ hashes of ordinary passwords verify interchangeably.

Start from OWASP’s minimum: Argon2id with m=19456 KiB (19 MiB), t=2, p=1. RFC 9106 suggests m=64 MiB, t=3, p=4 where memory allows. Fix the memory your servers can spare per login, then raise the iterations until one hash takes a few hundred milliseconds. The parameters are stored in the hash string, so they can be raised later and old hashes still verify.

The Password Hashing Competition string format stores everything needed to verify in one field: $argon2id$v=19$m=19456,t=2,p=1$salt$hash, with the salt and hash in unpadded Base64. Argon2 libraries in PHP, Node, Python, Go and Rust all read and write it, as passlib does for scrypt and PBKDF2.

No. A salted hash concatenates a salt with the message, which for SHA-256 and other Merkle-Damgard hashes is open to length extension. HMAC (RFC 2104) mixes a secret key in twice through inner and outer padding, which is the correct way to authenticate data or apply a pepper. Use HMAC when a key is involved, a password hash when a password is.

Structured strings name themselves: $2b$ is bcrypt, $argon2id$ is Argon2, $6$ is sha512crypt, pbkdf2_sha256$ is Django. A bare hex digest is identified by length only, and lengths overlap: 32 characters is MD5, NTLM, MD4 or LM; 64 is SHA-256, SHA3-256 or BLAKE2s. The Identify tab lists every candidate with its hashcat mode and John the Ripper format.

Yes. Every hash is computed in your browser with @noble/hashes (an audited, dependency-free library), bcryptjs and the Web Crypto API. Nothing you type or upload is sent to a server, logged or stored, and the page works offline once loaded. Even so, never paste a real production password or secret key into any website.