What is a salt and why do I need one?

A salt is random data combined with a password before hashing. It ensures two users with the same password get different hashes and defeats precomputed rainbow-table attacks. A unique salt per password is mandatory for secure storage.

How big should a salt be?

The widely recommended minimum is 16 bytes (128 bits) of random data. Many key-derivation functions accept larger salts, and 32 bytes is also common, but 16 bytes is sufficient to guarantee uniqueness across realistic user counts.

Should each password have its own salt?

Yes, always. The whole point of a salt is uniqueness, so every password hash must use a fresh, independently generated salt. Reusing one salt for many users reintroduces the rainbow-table weakness salts are meant to prevent.

Can I store the salt with the hash?

Yes. Salts are not secret and are normally stored in plain text next to the hash they produced, often concatenated into the same field. Their security value comes from uniqueness and randomness, not from being hidden.

Is the salt generated securely and privately?

Yes. The tool uses crypto.getRandomValues, the browser's cryptographically secure RNG, and everything runs locally. No salt is transmitted or logged anywhere.

Password Salt Generator

A salt is a unique, random value mixed into a password before it is hashed. Salting is what stops two users who happen to choose the same password from sharing the same stored hash, and it makes precomputed attacks such as rainbow tables useless because the attacker would need a separate table per salt. Modern password hashing functions — bcrypt, scrypt, Argon2, PBKDF2 — all require a salt, and it must be generated from a cryptographically secure source. This tool produces salts using the Web Crypto API entirely in your browser.

How it works

The generator allocates a byte buffer and fills it with random data from crypto.getRandomValues, the browser’s cryptographically secure pseudo-random number generator:

Allocate a Uint8Array of your chosen size (16 bytes by default).
Fill it with crypto.getRandomValues(bytes) — never Math.random.
Encode the raw bytes as hex or base64 for storage.

You then store this salt alongside the resulting password hash. Salts are not secret: their security comes from being unique and unpredictable, so it is completely safe to keep them in plain text next to the hash.

Best practices

Generate a fresh salt for every password — never reuse a single salt across users.
16 bytes (128 bits) is the standard minimum; larger salts are fine but rarely necessary.
The salt is not a replacement for a slow hashing function. Always pair salting with a deliberately slow algorithm like Argon2 or bcrypt with a sufficient work factor.
Store the salt with the hash; you need it again to verify a login attempt.

Everything here runs locally, so generated salts never touch a network and stay private to your machine.