Keys & Secrets
Five tools that produce similar-looking strings and follow completely different rules. The table below is the difference.
All 5 tools
Which one do you want?
An API key, a secret key, a JWT secret and a salt are all random bytes in an encoding. Confusing them is easy and occasionally expensive, so it is worth being precise about what actually separates them.
| Tool | Sent over the network? | Secret? | Length decided by |
|---|---|---|---|
| API Key | Every request | Yes | Characters |
| Secret Key | Never | Yes | Bits |
| JWT Secret | Never | Yes | The signing algorithm |
| Salt | Stored beside the hash | No | Bits, for uniqueness |
| Hash | Not a secret at all | No | The algorithm |
The row that catches people out
A salt is the only one in the table that is not a secret. It sits in your database in plain sight, next to the hash it belongs to, and an attacker is assumed to have it. Its size is chosen so that no two are ever the same, not so that nobody can guess it.
That is why its page reports how many salts you could draw before a repeat becomes likely rather than a strength band — and why it opens by telling you that if you use bcrypt or Argon2, the library already made one and you do not need the page at all.
Bits, not characters
Three of these five are measured in bits, and it matters: sixteen characters is 64 bits in hex and 96 in Base64. Advice given in characters is ambiguous by construction, which is why the secret key and salt tools ask for a bit size and then tell you how many characters that turns into.
The JWT secret generator goes one step further and lets the algorithm decide: RFC 7518 says an HMAC key must be at least as long as the hash output, so HS512 will not accept a 256-bit key and the tool removes the option rather than warning about it.
The one that is not a generator
The hash generator takes input rather than producing a secret. It sits here because hashing and key material turn up in the same afternoon, and because the two most common questions about it belong next to these tools: why a digest does not match, and why SHA-256 is the wrong way to store a password.
The short answer to the second one is speed. Every algorithm on that page is fast by design, and a password hash has to be slow on purpose. Use bcrypt, scrypt or Argon2 — all three make their own salt too.
Frequently asked questions
Which one should I use for my application?
Match the tool to where the value goes. A key your server signs or encrypts with is a secret key; the signing secret for HS256, HS384 or HS512 tokens is a JWT secret; a credential your clients send with each request is an API key. A salt is only needed when you build a password hash by hand, and the hash generator checks digests rather than making secrets.
Can one secret be used for several purposes?
It should not be. Give each purpose its own key — one for signing sessions, another for tokens, another for encryption. Then a leak or a rotation affects one thing rather than everything, and a weakness in how one system handles its key cannot be carried over to the others.
Is a browser a safe place to generate a production key?
The randomness is the same kind your server’s standard library provides, and nothing generated here is transmitted. What remains is the machine you are on: browser extensions, clipboard managers, a shared screen. For a key that guards production, running openssl rand -hex 32 on the server that will use it keeps the key off your clipboard entirely.
What is the difference between hashing, signing and encrypting?
Hashing turns data into a fixed-length fingerprint and uses no key, so anyone can compute it and nobody can reverse it. Signing — what an HMAC does for a JWT — uses a secret key to prove who produced a message and that it was not changed. Encrypting uses a key to make data unreadable until the same key, or its pair, decrypts it.