b2KIT

Scrypt Hash Generator

Generate scrypt password hashes with configurable CPU/memory cost parameters and salt generation.

Tested tool guide Tested browser tools Checked August 16, 2026

What Scrypt Hash Generator does, with a checked example

Scrypt is a key derivation function built to be slow and memory-hungry, so password hashing costs an attacker real hardware, not just CPU cycles. This tool runs scrypt in the browser with controls for the memory cost (N), block size (r), parallelization (p), output length, and a salt you supply or have the tool generate. It returns the derived bytes as hex or base64. The common surprise: the output is a bare digest with no parameters inside it. Without the exact N, r, p, salt, and password, the hash cannot be reproduced - and nothing in the bytes will tell you a parameter was wrong.

Worked example

A concrete input and expected output from the current implementation.

Input

password: "password", salt: "NaCl", N=1024, r=8, p=16, output length 64 bytes

Expected output

fdbabe1c9d3472007856e7190d01e9fe7c6ad7cbc8237830e77376634b3731622eaf30d92e22a3886ff109279d9830dac727afb94a83ee6d8360cbdfa2cc0640

This is test vector 2 from RFC 7914, so the result is independently checkable against the specification. Any single change - even one character of the salt - produces completely different bytes, which is why the salt and parameters must be stored alongside the hash.

How the result is produced

1

The three cost parameters

N is the CPU/memory cost and must be a power of two; memory use is roughly 128 x N x r bytes, so N=16384 with r=8 needs about 16 MiB per hash. r sets the block size and p the parallelization factor; p=1 is enough for most uses. Doubling N doubles both memory and time. The tool takes a salt - unique per password - and the derived-key length in bytes.

2

What the output is

Inside, scrypt runs PBKDF2-HMAC-SHA256 with an intermediate memory-hard mixing step (ROMix, built on the Salsa20/8 core) that repeatedly reads and writes a buffer of the size set by N and r. The final step derives dkLen bytes of output. The same password, salt, and parameters always give the identical output, so the hash is reproducible by any compliant scrypt implementation - this tool's result should match them byte for byte.

Good uses

  • Create a per-user password hash for a login database: generate a fresh salt for the new account, hash the password, and store the salt, the parameters (N, r, p), and the hash together.
  • Derive a symmetric encryption key (for example 32 bytes for AES-256) from a human-remembered password, rather than producing a stored password hash.
  • Check that a scrypt implementation in another language or library produces output identical to a reference, using known test vectors such as the ones in RFC 7914.

Limits and checks

  • The output encodes no parameters. A scrypt result is a bare byte string: N, r, p, and the salt must be stored separately or the hash can never be reproduced, and it will not match hashes from systems using different settings.
  • N must be a power of two. Values like 1000 are not valid per RFC 7914, and memory grows as 128 x N x r bytes - a high N with a large r can consume hundreds of megabytes or freeze a browser tab.
  • This is a generator, not a verifier. There is no way to reverse a scrypt hash back into the password, and the tool does not check passwords against hashes; verification means re-deriving the hash with the stored salt and comparing the bytes.

Common questions

Why does hashing the same password twice give different results?

If the tool generated a fresh random salt on the second run, the inputs differed, so the outputs differ - that is by design, and it is why the salt is stored next to the hash. With the exact same salt and parameters the output is always identical, which is what makes verification possible.

What parameters should I use?

There is no single right answer; pick values your hardware can bear and your attackers cannot. N=16384 with r=8 and p=1, about 16 MiB of memory per hash, is a widely used starting point for interactive logins, and many systems raise N as hardware improves. Compute memory as 128 x N x r bytes and test the delay in your own browser before committing.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.