SHA256 Generator With Salt: When Salting Helps and When It Does Not

What the salt buys you

A salt is extra input, random and unique per record, that goes into the hash with the data, as in sha256(salt + input). It is stored in the clear next to the digest. Its job is to make equal inputs look different, so a table of salted digests does not reveal which rows hold the same value.

That also defeats rainbow tables and every other precomputed list: they are built for unsalted SHA-256, and building one per salt is not worth anyone's time.

What it does not buy you

Time. A salted SHA-256 costs no more to compute than an unsalted one, and SHA-256 is fast by design. Given the database, an attacker runs a wordlist against each salt in turn, and weak passwords still fall quickly.

For passwords, reach for Argon2id, scrypt or bcrypt instead. They generate the salt and store it inside the hash string for you, so there is no salting code of your own to get wrong.

Where salted SHA-256 fits

Anonymised identifiers: hashing an email with a per-dataset salt lets you join records without storing the address, while making cross-dataset correlation harder.

Cache and shard keys that must not collide across tenants. Deterministic pseudonyms in analytics. Anywhere the digest being guessed is inconvenient rather than dangerous.

If you need a keyed digest rather than a salted one — where the secret must stay server-side — use HMAC-SHA256, not concatenation. Hashing a secret prefix directly is vulnerable to length extension.

Generating the salt

Use a cryptographic random source and at least 16 bytes. A counter, a username or a timestamp is not a salt — it is predictable, which removes the only guarantee a salt provides:

$salt = random_bytes(16);                    // PHP
salt = os.urandom(16)                        # Python
const salt = crypto.getRandomValues(new Uint8Array(16)); // JS

To check a salted digest by hand in the hash generator, remember that it has no separate salt field and hashes the text box as UTF-8. Paste the salt and the input in the same order your code concatenates them. That only reproduces your result if the code also treats the salt as text: a salt stored as the hex string c0ffee and hashed as the three raw bytes it represents gives a different digest from the six characters c0ffee.

Frequently asked questions

Does the salt need to be secret?

No. Salts are stored alongside the hash. A secret mixed in is called a pepper and serves a different purpose.

Is salted SHA-256 acceptable for passwords?

No. It is far too fast. Use Argon2id or bcrypt.

How long should a salt be?

16 random bytes is the common recommendation and is plenty.