Introduction
Need to generate a scrypt hash in your browser without installing any software? This scrypt hash generator runs entirely client-side using the scrypt-js library, so your password never leaves your computer. Whether you are a developer testing key derivation parameters, a security engineer comparing memory-hard functions, or a student learning about password hashing, this tool gives you full control over N, r, p, and output length with instant feedback on computation time and memory usage.
What this tool does
- Derives a cryptographic key from a password using the scrypt key derivation function (RFC 7914).
- Lets you configure all four scrypt parameters: N (CPU/memory cost), r (block size), p (parallelism), and dkLen (output length).
- Generates a random 16-byte salt automatically, or lets you paste your own salt in hex.
- Reports elapsed computation time and approximate memory consumption so you can tune parameters for your target hardware.
- Outputs the derived key in hexadecimal format, ready to copy into your application or test harness.
How this tool works
Type or paste a password into the input field. Optionally provide a salt in hexadecimal format, or click Generate Salt to create a random 16-byte salt using the Web Crypto API. Select your scrypt parameters from the dropdowns: N must be a power of 2 and controls the overall memory and CPU cost, r sets the block size factor, p determines how many independent parallel chains run, and dkLen specifies the output key length in bytes. Click Generate scrypt Hash and the tool computes the derived key using the scrypt-js library, which implements the full RFC 7914 algorithm in pure JavaScript. The result appears as a hex string, along with the measured computation time in milliseconds and the approximate memory footprint (N * r * 128 bytes). Everything runs in your browser. No password, salt, or derived key is transmitted to any server.
How scrypt works
Scrypt is a password-based key derivation function designed by Colin Percival and published as RFC 7914 in 2016. Unlike simpler functions such as PBKDF2, scrypt is intentionally memory-hard: it requires a large amount of RAM to compute, which makes brute-force attacks using ASICs or GPUs prohibitively expensive. The algorithm works in three stages. First, it uses PBKDF2-HMAC-SHA-256 to expand the password and salt into p blocks of 128*r bytes each. Second, each block passes through a function called ROMix, which performs N sequential read-and-write operations on a large pseudo-random array, forcing the attacker to allocate and retain that array in memory. Third, the mixed blocks are fed back through PBKDF2-HMAC-SHA-256 to produce the final derived key. The OWASP Password Storage Cheat Sheet (2024 edition) recommends scrypt as a fallback when Argon2id is unavailable, with minimum parameters of N=2^17 (131072), r=8, p=1, which requires approximately 128 MB of memory. NIST SP 800-63B also lists scrypt as an example of a memory-hard function suitable for password storage. The parameters are tunable: increasing N raises memory and CPU cost proportionally, while increasing p adds parallelism without changing the per-chain memory requirement.
How to use this tool
- Enter the password you want to hash in the password field.
- Either leave the salt blank to auto-generate a random 16-byte salt, or paste your own hex salt.
- Select N (cost parameter). Higher values mean more memory and slower computation. OWASP recommends at least 2^17 for production use.
- Select r (block size factor). The default of 8 is standard in most implementations.
- Select p (parallelism). Use 1 for single-threaded environments, or higher values for multi-core systems.
- Select dkLen (output key length). 32 bytes (256 bits) is standard for most applications.
- Click Generate scrypt Hash. The derived key appears in hex format along with timing and memory metrics.
Real-world examples
Default OWASP-recommended parameters
Password: "correct horse battery staple", N=16384, r=8, p=1, dkLen=32. This requires about 16 MB of memory and takes roughly 100-200ms on a modern laptop. The output is a 64-character hex string representing the 256-bit derived key.
High-security configuration
Password: "my-secret-password", N=65536, r=8, p=1, dkLen=64. This allocates 64 MB of memory and may take 500ms or more. Suitable for password storage where the server can afford the latency.
Low-resource testing
Password: "test", N=1024, r=8, p=1, dkLen=16. Uses only 1 MB of memory and completes in under 10ms. Useful for development and unit tests, but not secure for production password storage.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| scrypt | Memory-hard, O(N*r) memory | Password storage, key derivation where ASIC resistance is needed |
| Argon2id | Memory-hard and side-channel resistant | Recommended first choice by OWASP (2024) for new systems |
| PBKDF2 | CPU-hard only, no memory requirement | FIPS-140 compliant environments, legacy systems |
| bcrypt | CPU-hard, small fixed memory | Legacy password storage, 72-byte password limit |
Limitations or considerations
Scrypt computation in the browser is single-threaded by default, so high values of N can freeze the UI for several seconds. The tool uses the scrypt-js library, which is a pure JavaScript implementation and slower than native bindings in Node.js or Go. For production password storage, use a server-side implementation with a well-tested library such as libsodium or the scrypt package in Node.js. This tool is intended for testing, learning, and parameter tuning, not for generating production password hashes.
Frequently asked questions
What values of N, r, and p should I use?
OWASP recommends N=2^17 (131072), r=8, p=1 as a minimum for production password storage. This uses about 128 MB of memory. If your hardware cannot handle that, you can trade memory for parallelism: N=2^16, r=8, p=2 uses 64 MB, or N=2^15, r=8, p=3 uses 32 MB.
Is scrypt better than Argon2?
Argon2id is the current OWASP first recommendation (2024) because it is both memory-hard and resistant to side-channel attacks. Scrypt is a solid second choice when Argon2 is not available. Both are far better than PBKDF2 or bcrypt for new systems.
Why does the computation take so long in the browser?
This tool uses scrypt-js, a pure JavaScript implementation. Native implementations in C, Go, or Rust are typically 5-10x faster. The browser also runs on a single thread, so the parallelism parameter p does not provide actual speedup here.
Should I store the salt alongside the hash?
Yes. The salt is not a secret. You must store it with the hash so you can recompute the same derived key for verification. Use a unique random salt for every password. Never reuse salts across accounts.
Conclusion
This scrypt hash generator gives you a convenient way to experiment with RFC 7914 parameters entirely in the browser. Tune N, r, and p to match your target hardware, verify that computation time falls within your acceptable range, and copy the hex output for testing. For production password storage, pair this tool with a server-side scrypt or Argon2id library and always use a unique random salt per password.