Scrypt Hash Generator and Verifier

Features

• Both directions: generate a hash, or verify a password against one
• Adjustable parameters: exponent of N (ln), block size r, parallelism p
• Output as a PHC hash string, the derived key in hex or Base64, or all three
• Verification reads the parameters from the hash, so nothing has to be recorded separately
• Live memory readout for the current settings; when over budget it states the N actually used, rather than changing it silently
• Constant-time comparison, so it never returns early on a matching prefix

How to use

1. Choose the mode: generate or verify
2. When generating, adjust parameters (defaults ln=15 / r=8 / p=1, 32 MB) and pick the output format; when verifying, paste the hash
3. Paste the password into the input box
4. Press Ctrl/⌘ + Enter or click Run, then copy the result

FAQ

Scrypt or bcrypt — which should I choose?

Both are acceptable today; they differ in what they consume. Bcrypt spends only CPU, so a GPU can run thousands of instances at once. Scrypt also spends memory, each instance taking 128 × r × N bytes, which exhausts VRAM quickly — that is the whole advantage. In cryptographic terms the recommended order is Argon2id > scrypt > bcrypt, and all three are far better than any fast hash (storing passwords with plain SHA-256 is simply wrong). This tool offers both because bcrypt has far more installed base in existing systems.

How do I tune ln, r and p?

ln is the main dial: N = 2^ln, and both memory and time scale linearly with it, so each step doubles the cost. The default of 15 (N=32768, 32 MB) is the conventional choice and the default in passlib and similar libraries. r sets how much of the cost lands in memory versus computation (higher leans toward memory); leave it at 8. p splits the input into parallel streams and multiplies total memory by p — but a browser runs this on one thread, so p above 1 only increases the cost without getting faster. Leave it at 1.

Why do I not have to supply the parameters when verifying?

Because they are written into the hash string itself — the `$scrypt$ln=15,r=8,p=1$…` part. That is the point of the PHC format: the verifying side needs nothing but the hash to recompute, with no separate parameter record to fall out of sync. This tool reads ln / r / p from the hash and ignores the three inputs on the page, so changing them will not alter the outcome.

Can other programs use the hashes this produces?

Yes. The PHC format is the common spelling across passlib (Python), node-scrypt and others, with the salt and hash in unpadded standard Base64. Store the whole string; when verifying, hand it back to this tool or to one of those libraries. Conversely, if another system hands you a scrypt hash that does not look like `$scrypt$…` — a JSON blob, or the older `$7$` form — this tool will not recognise it and will say so clearly.

Which output should I pick: PHC, hex or Base64?

For storing passwords use PHC — it is the only form that carries the salt and parameters, so a single string is enough to verify. Hex and Base64 are the raw derived key (32 bytes by default) with no salt and no ln/r/p, so on their own they verify nothing; their purpose is to feed that key into something else, such as an HMAC key or another KDF. This is also why the same password yields a different PHC string each time (the salt is random), whereas under one salt and parameter set the hex and Base64 are two spellings of the same key and decode byte-for-byte identically.