SHA-256 hash generator with salt
Enter a value and a salt below, choose how they should be combined, and generate a salted SHA-256 hash.
Why combine SHA-256 with a salt
SHA-256 on its own is a pure, deterministic function: identical input always produces identical output. For many uses (checksums, deduplication) that's exactly the desired behavior. But whenever the input is something secret — a password, an API token, a personal identifier — that same determinism lets an attacker precompute the SHA-256 of every value in a dictionary or common-password list and instantly reverse-match any hash that shows up in a breach. A salt defeats this by mixing in a unique, unpredictable value before hashing.
Three combination modes, explained
| Mode | Formula | Best for |
|---|---|---|
| Append | SHA256(input + salt) | Quick prototyping, legacy compatibility |
| Prepend | SHA256(salt + input) | Equivalent security profile to append; some systems prefer it by convention |
| HMAC-SHA256 | HMAC(key = salt, message = input) | Recommended — the standard, formally analyzed way to combine a key and a message with SHA-256 |
HMAC-SHA256 specifically is what you'll find used throughout modern security standards — webhook signature verification (Stripe, GitHub, and most API providers sign payloads with HMAC-SHA256), JWT signing (the "HS256" algorithm), and API request signing all rely on it. If you're implementing any of those integrations and need to sanity-check a signature by hand, this tool's HMAC mode reproduces that exact computation.
Real-world use cases for salted SHA-256
- Verifying webhook signatures from third-party services that sign their payloads with your shared secret via HMAC-SHA256.
- Generating deterministic, non-reversible identifiers from personal data (an email address, say) combined with an application-wide secret, for use in analytics or deduplication without storing the raw value.
- Building a custom token or API-key scheme where a secret needs to be verifiable without being stored in plaintext.
Still not a password-storage recommendation
Salting closes the rainbow-table gap but doesn't change the fact that SHA-256 is fast to compute, which keeps targeted brute-force attacks cheap. PBKDF2-HMAC-SHA256, which applies this exact HMAC construction tens of thousands of times in a loop, is the NIST-approved way to turn SHA-256 into something appropriate for password storage — see our note on this in the SHA-256 for passwords page, or use bcrypt directly for a simpler, equally solid option.
Frequently asked questions
What is HMAC-SHA256 used for in real applications?
Most commonly for verifying webhook payload signatures, signing JSON Web Tokens (the HS256 algorithm), and signing API requests — anywhere two parties share a secret and need to confirm a message wasn't tampered with.
Is HMAC-SHA256 the same as encrypting with SHA-256?
No — SHA-256 cannot encrypt anything; it only produces a one-way digest. HMAC-SHA256 combines a secret key with a message to produce a verifiable signature, but the original message still needs to be sent separately for the recipient to check against it.
Can I use this to verify a Stripe or GitHub webhook signature by hand?
Yes — set the mode to HMAC, paste your webhook secret as the salt/key and the raw payload as the input, and compare the resulting hash to the signature header, matching the exact algorithm the provider documents.