Skip to content
BetterPass logo

Scrypt Hash Generator — Memory-Intensive Password Hashing

Hash or verify with tunable N, r, and p parameters — scrypt's memory-hard design defeats GPU and ASIC brute-force. Everything runs locally in your browser.

Result
Use a random salt (16+ bytes recommended).
≈ 128 MiB of RAM allocated per hash.

What is Scrypt Key Derivation?

Memory-hard by design — scrypt forces crackers to burn gigabytes of RAM, so GPU and ASIC brute-force fails. Protect passwords with a hash designed to consume lots of memory.

Scrypt is a memory-hard password-based key derivation function (KDF) designed by Colin Percival in 2009 to resist hardware acceleration attacks. Unlike fast hashes, scrypt forces attackers to commit large amounts of RAM per attempt — the memory you configure (typically 32-128 MB) becomes the attacker's bottleneck, defeating GPU and ASIC brute-force rigs. Use this tool to derive password hashes or encryption keys with tunable N, r, and p parameters, or to verify an existing scrypt hash. The computation runs entirely in your browser; nothing is sent to a server.

Memory-hard by design — the algorithm requires a configurable amount of RAM during hashing, which GPUs and ASICs can't easily parallelize.
Three tunable parameters — N (CPU/memory cost), r (block size), and p (parallelization) give fine-grained control over performance.
Self-describing hash strings — Hash mode can output a single encoded string ($scrypt$N=...,r=...,p=...,len=...$) that packs every parameter and the salt, so Verify mode can check it later with just the password.
Standardized in RFC 7914 — an IETF standard with well-defined security properties.

Zero-Server Tool Data Guarantee

All hashing and verification happens locally in your browser. Your password and salt are never sent to any server.

How to Use

01

Hash or Verify

Use Hash to generate a scrypt key, or Verify to inspect and test an existing encoded scrypt hash string.

02

Apply a Preset

Pick a cost preset (OWASP interactive N=131072, Encryption N=65536, or Lightweight N=8192) to set parameters in one click, or choose Custom to enter log2(N), r, p, and key length manually.

03

Generate or enter a salt

Use the Generate button for a cryptographically random 16-byte salt, or paste your own. The salt is required and must be stored with the hash.

04

Extract the Key

The derived key is calculated in your browser. Copy it as an Encoded string (recommended — includes parameters and salt), or as hex/base64 for use in your security implementations.

05

Inspect Parsed Params

In Verify mode, paste an encoded scrypt hash to see its parsed N, r, p, len, and salt before checking for a match.

Common Use Cases

Password Storage

Derive a storage-safe key from a user password. The memory-hard property makes GPU-based cracking farms impractical.

Encryption Key Derivation

Turn a passphrase into an AES-256 encryption key for encrypting files, databases, or backups.

Cryptocurrency Wallets

Protect crypto wallets with scrypt-derived keys, leveraging its resistance to specialized mining hardware.

Secure API Authentication

Derive short-lived API tokens from master credentials using scrypt with a per-request unique salt.

Implementation Examples

JavaScriptBrowser (scrypt-js)
import { scrypt } from 'scrypt-js';


async function deriveKey(password, salt) {
    const passwordBytes = new TextEncoder().encode(password);
    const saltBytes = new TextEncoder().encode(salt);
    
    const dk = await scrypt(passwordBytes, saltBytes, {
        N: 16384, r: 8, p: 1, dkLen: 32
    });
    
    return Array.from(dk).map(b => b.toString(16).padStart(2, '0')).join('');
}

Scrypt vs Bcrypt vs Argon2

FeatureScryptBcryptArgon2
Memory hardnessHigh (configurable)Low (4KB fixed)High (configurable)
GPU/ASIC resistanceStrongModerateStrongest
ParametersN, r, pCost factor onlyMemory, iterations, parallelism
Winner of Password Hashing CompetitionNoNoYes (2015)
Library availabilityGoodExcellentGood (growing)
Best forCrypto / high-securityWeb apps (simple)New projects (recommended)

Production Best Practices & Security

Use the OWASP preset for logins — N=131072, r=8, p=1 allocates ~128 MB and is OWASP's recommended minimum for interactive authentication in 2026. Why:These settings provide a good balance between security (about 100-200ms on modern hardware) and user experience.
Always use a unique, random salt — use the Generate button or provide at least 16 bytes of cryptographic randomness yourself. Why:Without a salt, attackers can use precomputed "Rainbow Tables" to instantly crack common passwords. A unique salt ensures that identical passwords have completely different hashes.
Increase N for high-value secrets — for encryption keys or master passwords, choose the Encryption preset (N=65536, ~64 MB) or higher. Why:Increasing N doubles the memory and CPU time required for each hash. This makes it exponentially more expensive for attackers to brute-force your most sensitive data.
Store the encoded string, not just the key — copy the Encoded output, which embeds N/r/p/len and the salt, so you can verify the password later without remembering parameters. Why:The derived key alone cannot be re-verified without its parameters and salt.
Set dkLen appropriately — 32 bytes is standard for most applications; use 64 bytes if you need a longer derived key. Why:The output length (Derived Key Length) should match the requirements of your next step, such as an AES-256 key (32 bytes).
Don't use scrypt for fast hashing — it's intentionally slow; use SHA-256 for checksums and data integrity. Why:Scrypt's memory-hard design is meant to stop attackers, but it also slows down your server. Using it for things that don't need password-level security is a waste of resources.
Benchmark your target hardware — tune parameters based on the weakest device your users will use (e.g., mobile phones). Why:If you set the cost too high, users on older smartphones might experience several seconds of lag during login, which can look like a bug or a frozen app.

Frequently Asked Questions

scrypt is a password-based key derivation function (KDF) designed by Colin Percival in 2009, originally created for the Tarsnap backup service.

Unlike fast hash functions like SHA-256 that can be computed billions of times per second, scrypt is deliberately memory-hard. It requires a configurable amount of RAM (typically 8-128 MB) to compute each hash.

This memory requirement is its key advantage. An attacker using a GPU or ASIC can't just throw more compute at the problem, because each parallel hash attempt needs its own chunk of memory. Memory bandwidth becomes the real bottleneck.

scrypt makes brute-force and dictionary attacks dramatically more expensive than algorithms like PBKDF2, which are compute-bound but not memory-hard.