JWT Secrets and Signing with HS256/384/512

A JSON Web Token (JWT) is a compact, signed container for claims — facts such as "this is user 1234, and the token expires at 5pm." Servers issue JWTs after login and clients send them back on later requests. The signature is what makes a JWT trustworthy, and the quality of your signing secret is what makes the signature trustworthy.

Anatomy of a JWT

A JWT has three Base64URL-encoded parts separated by dots: header.payload.signature.

• Header — metadata, including the algorithm, e.g. {"alg":"HS256","typ":"JWT"}.
• Payload — the claims, e.g. {"sub":"1234","exp":1710000000}.
• Signature — computed over header.payload using the chosen algorithm and your secret.

Crucially, the header and payload are only encoded, not encrypted — anyone can read them. Never put passwords or sensitive data in a JWT payload.

HS256, HS384, and HS512

The HS* algorithms sign tokens with HMAC plus a SHA-2 hash and a single shared secret. The same secret both creates and verifies the signature, so it must stay on the server.

• HS256 — HMAC-SHA-256, the most common choice.
• HS384 — HMAC-SHA-384.
• HS512 — HMAC-SHA-512.

There are also asymmetric algorithms (RS256, ES256) that sign with a private key and verify with a public key — useful when many independent services need to verify tokens without holding the signing secret.

How big should the secret be?

For HMAC, a good guideline is to make the secret at least as large as the hash output:

• HS256 — at least 256 bits (32 bytes).
• HS384 — at least 384 bits (48 bytes).
• HS512 — at least 512 bits (64 bytes).

And it must be random. A short, human-chosen secret like mysecret can be brute-forced offline against any token you have ever issued. Generate the secret from a CSPRNG and store it as an environment variable or in a secret manager.

Common JWT pitfalls

• Weak secrets. The number-one JWT vulnerability is a guessable HMAC secret.
• Accepting alg: none. Always pin the expected algorithm; never trust the algorithm the token claims for itself.
• Skipping expiry. Always set and verify exp, and validate iss/aud where relevant.
• Treating JWTs as private. The payload is readable; don't store secrets in it.
• No revocation plan. Stateless tokens can't be un-issued — keep lifetimes short and use refresh tokens.

Generate, sign, and decode JWTs

The JWT tab generates strong signing secrets sized for HS256/384/512. The JWT Tools tab lets you sign a token from header and payload JSON and decode any token's header and payload — all locally, so no token or secret leaves your browser.