What Is a Salt in Password Hashing?

When you hash a password, two users with the same password produce the same hash — and that's a problem. A salt fixes it by adding unique random data to each password before hashing.

Why salts matter

Without a salt, an attacker who steals your hash database can look up hashes in a precomputed table (a "rainbow table") and crack them instantly. With a salt, every hash is different even if the underlying passwords are identical.

password123 → $2b$12$abc123...  (user A's hash)
password123 → $2b$12$xyz789...  (user B's hash, different salt)

A rainbow table precomputed for password123 is now useless — the attacker would need to rebuild it for every possible salt value.

How it works

1. Generate a random salt (typically 16+ random bytes) per user.
2. Concatenate the salt with the password.
3. Hash the combined value.
4. Store the salt alongside the hash.

On login, you retrieve the stored salt, apply it again, hash the candidate password, and compare.

Modern algorithms like bcrypt and argon2 handle this automatically — the salt is embedded in the output string, so you don't manage it separately.

Salt length matters

A short salt limits the benefit. If your salt is only 8 bits, an attacker can precompute tables for all 256 salt values and still crack your database. Use at least 128 bits (16 bytes) of cryptographically random data.

Salts vs peppers

A pepper is a secret constant added to all passwords, stored separately from the database (e.g. in an environment variable). A salt is unique per user and stored in the database. They can be combined: hash(salt + password + pepper). The pepper adds another layer — if the database leaks but the pepper doesn't, the hashes are still safe.

The right tools

Don't roll your own salt logic. Use bcrypt, argon2, or scrypt — they're designed for passwords, not speed. SHA-256 is fast by design, which is the opposite of what you want for passwords: see why MD5 and fast hashes aren't safe for passwords.

For non-password use cases (integrity checks, checksums), speed is fine. Explore how different inputs hash with the hash generator.

Quick rules

• Always salt passwords — no exceptions.
• Use a per-user, random salt (never a static global one).
• Prefer bcrypt/argon2 — they embed the salt, pick a good default length, and add tunable cost.
• Don't invent your own hashing scheme. Libraries exist. Use them.

Need a refresher on how hashing itself works? See what is a hash function.