Create SCRYPT output quickly with a client-only generator that runs in your browser—no installs required.
Hash will appear here once you click Hash.
Scrypt is a memory-hard password-based key derivation function (KDF) designed by Colin Percival in March 2009 and standardized as RFC 7914 in 2016. Unlike PBKDF2 and bcrypt, scrypt deliberately uses large amounts of RAM during computation so that attackers cannot cheaply parallelize attacks on GPUs, FPGAs, or ASICs — the memory bandwidth becomes the bottleneck.
128 * N * r * p bytes of RAM per hash. At N=2^17, r=8, p=1 that's ~128 MiB per attempt, making custom-silicon attacks economically impractical compared to bcrypt.crypto.scrypt() ships with Node 10+, OpenSSL 1.1+ exposes EVP_KDF-SCRYPT, and there are mature implementations for Go, Python, Rust, and Java without extra dependencies.| Property | scrypt | Argon2id | bcrypt |
|---|---|---|---|
| Year published | 2009 (RFC 7914 in 2016) | 2015 (PHC winner) | 1999 |
| Memory-hard | Yes (configurable) | Yes (configurable) | No (fixed ~4 KiB) |
| GPU/ASIC resistance | Strong (RAM-bound) | Strongest (RAM + side-channel resistant) | Weak — GPUs accelerate ~30x |
| Tunable parameters | N (CPU/mem), r (block), p (parallel) | memory, iterations, parallelism | cost factor (work) |
| Max password length | Unlimited | Unlimited | 72 bytes (silently truncated) |
| OWASP 2024 ranking | #2 fallback | #1 recommended | #3 legacy only |
| Standardized as | RFC 7914 | RFC 9106 | No formal RFC |
| Built-in to Node.js | Yes (crypto.scrypt) |
No (needs argon2 package) |
No (needs bcrypt package) |
For new applications in 2026, use Argon2id unless your runtime can't support it. For legacy systems already on bcrypt, don't migrate without need — just raise the cost factor.
| Profile | N | r | p | Memory per hash | Use case |
|---|---|---|---|---|---|
| Maximum | 2^17 (131,072) | 8 | 1 | ~128 MiB | OWASP default; high-security backends |
| Balanced | 2^16 (65,536) | 8 | 2 | ~64 MiB × 2 | Web apps with moderate auth load |
| Standard | 2^15 (32,768) | 8 | 3 | ~32 MiB × 3 | General-purpose password storage |
| Interactive | 2^14 (16,384) | 8 | 5 | ~16 MiB × 5 | Latency-sensitive logins |
| Constrained | 2^13 (8,192) | 8 | 10 | ~8 MiB × 10 | Embedded / low-memory environments |
All five rows are published in the OWASP Password Storage Cheat Sheet — they're equivalent in total work, just distributed differently between memory and parallel cores. Pick the row whose memory cost matches what your auth server can spare per concurrent login.
Use Argon2id if your platform supports it. The Password Hashing Competition selected Argon2 as the winner in July 2015 after a multi-year public review, and OWASP, NIST SP 800-63B-4, and IETF RFC 9106 all now position Argon2id as the default choice for password storage. The OWASP 2024 Password Storage Cheat Sheet recommends Argon2id with a preferred profile of m=46 MiB (46080), t=1, p=1 and a minimum of m=19 MiB (19456), t=2, p=1. Scrypt remains a perfectly acceptable second choice — it's memory-hard, well-studied, and battle-tested — but Argon2id resists side-channel attacks that scrypt does not, thanks to its hybrid data-dependent/independent mode.
The working-set RAM is approximately 128 * N * r * p bytes per hash. At the OWASP-recommended N=2^17, r=8, p=1, that's 128 * 131,072 * 8 * 1 = 134,217,728 bytes, or 128 MiB per concurrent hash operation. At the constrained profile (N=2^13, r=8, p=10), it's ~8 MiB per parallel lane × 10 lanes = ~80 MiB total. Plan capacity around peak concurrent logins, not total user count.
PBKDF2 is CPU-hard but not memory-hard. An attacker with a $5,000 consumer GPU can compute billions of PBKDF2-SHA256 hashes per second because each guess fits in a few hundred bytes of GPU register memory. Scrypt forces each guess to allocate tens or hundreds of megabytes of RAM that must be randomly accessed throughout the computation — GPUs run out of memory bandwidth long before they exhaust CPU. PBKDF2 remains acceptable only when FIPS-140 compliance is mandatory and no memory-hard alternative is approved.
Yes — always. A salt prevents two users with the same password from getting the same hash, defeats rainbow tables, and stops attackers from amortizing cracking work across an entire database. The salt must be unique per credential (not per application) and generated from a cryptographically secure source like crypto.randomBytes or /dev/urandom. 16 bytes (128 bits) is the standard minimum; 32 bytes is fine if you want extra margin. The salt is not secret — store it alongside the hash.
For password verification, 32 bytes (256 bits) is plenty — any longer and you're just storing extra bytes that don't increase security beyond the underlying primitive. If you're using scrypt as a key derivation function to feed AES-256-GCM, AES-256-CBC, or another 256-bit cipher, 32 bytes matches the cipher key size exactly. For ChaCha20-Poly1305 use 32 bytes; for combined encrypt + MAC schemes you may want 64 bytes split into two halves.
Weak passwords can always be cracked given enough time — scrypt slows the attacker down but doesn't make brute force impossible. The point of memory-hardness is to convert what would be a $1,000 GPU rig attack into a $50,000+ memory-bandwidth attack, buying you orders of magnitude more time. A 12-character random password hashed with OWASP-recommended scrypt parameters is computationally infeasible to brute force on any hardware available in 2026. An 8-character dictionary word, however, remains crackable in hours — no KDF saves you from bad password policy.
Scrypt returns a raw byte string of whatever length you requested. Most libraries serialize the full record as a PHC-style string: $scrypt$ln=17,r=8,p=1$<base64-salt>$<base64-hash>. Storing the parameters alongside the hash lets you upgrade cost over time — when N=2^17 stops being enough, you can verify old hashes at their original parameters and rehash at the new level on next login. Browser-based tools like the Authgear password hash generator and most server-side auth libraries follow this serialization convention so hashes are portable across implementations.
Because pasting production secrets into a remote API is a security mistake. This page runs the scrypt reference implementation compiled to WebAssembly entirely inside your browser tab. No request body containing your password is ever sent to xconvert servers — you can verify this by opening DevTools, switching to the Network tab, and clicking Generate. Use this generator for development, testing, parameter tuning, and educational purposes; for production password storage, call scrypt server-side from your auth backend with the same parameters.
Scrypt itself is not on the NIST FIPS 140-3 approved algorithm list as of 2026, which makes it inappropriate for some US federal and regulated-industry applications. NIST SP 800-63B-4 lists PBKDF2 as the FIPS-approved password hashing option, while acknowledging memory-hard KDFs (Argon2, scrypt) as cryptographically stronger. If you're building for a regulated environment, check your compliance requirements before choosing scrypt; for everything else, scrypt or Argon2id are stronger choices than PBKDF2.