JWT Signer & Key Generator
What is a JWT Signer & Key Generator?
The JWT Signer & Key Generator builds a complete, cryptographically signed JSON Web Token from a header, a payload and a secret. Edit the two JSON objects, supply your signing secret, and a real HMAC signature is computed in your browser — the resulting token verifies against the same secret in any standard JWT library.
This is the tool you want when you need a valid token to test an API, reproduce an authentication bug, or seed an integration test, and you do not want to spin up your auth service to get one.
Anatomy of the token it produces
A JWT is three base64url segments joined by dots: header.payload.signature. The header declares the signing algorithm, the payload carries your claims, and the signature is an HMAC over the first two segments keyed with your secret. Changing a single character of the header or payload invalidates the signature — that is exactly what makes the token tamper-evident.
Supported algorithms
- HS256 — HMAC with SHA-256. The default and by far the most widely deployed.
- HS384 — HMAC with SHA-384.
- HS512 — HMAC with SHA-512.
Set the algorithm in the header's alg field and the signature is computed with it. Asymmetric families such as RS256 and ES256 require a private key and are deliberately rejected rather than silently signed as something else.
How to use it
- Edit the header JSON. Keep
typasJWTand setalgto HS256, HS384 or HS512. - Edit the payload JSON with your claims —
sub,iss,aud,exp, plus anything your application reads. - Enter the secret your verifying service uses.
- Copy the signed token. The "Signature verified" badge confirms it validates against the secret you entered.
Common claims worth setting
exp— expiry, as a Unix timestamp in seconds. Most libraries reject a token past this instant.iat— issued-at timestamp.nbf— not-valid-before timestamp.sub— the subject, usually a user ID.issandaud— issuer and intended audience, both commonly validated.
Related Developer & Utility Tools
- JWT Parser: decode an existing token and inspect its claims and expiry.
- Bcrypt Hash Generator: hash and verify passwords.
- HMAC Generator: compute a standalone HMAC over arbitrary data.
- Token Generator: generate a random secret to sign with.
Frequently Asked Questions
Does this tool really sign the token, or is the signature a placeholder?
It really signs it. The signature is a genuine HMAC computed over the base64url-encoded header and payload using your secret, so the token verifies in any standard JWT library. The page also re-verifies the token it just produced and shows a "Signature verified" badge.
Is my secret sent anywhere?
No. The header, payload and secret stay in your browser; signing happens locally in JavaScript. Nothing is transmitted to a server.
Which algorithms are supported?
HS256, HS384 and HS512. Set the one you want in the header’s alg field. RS256, ES256 and other asymmetric algorithms need a private key and are rejected with an explicit error rather than being silently downgraded.
Why did I get an "Unsupported alg" error?
The header requested an algorithm outside the HMAC family — typically RS256 or ES256. Change alg to HS256, HS384 or HS512, or sign with a library that has access to your private key.
How do I make the token expire?
Add an exp claim to the payload set to a Unix timestamp in seconds, for example {"exp": 1767225600}. Note it is seconds, not milliseconds — passing a millisecond value is the most common cause of a token that never seems to expire.
Should I use a token generated here in production?
Use it for testing, debugging and local development. Production tokens should be minted by your authentication service with a secret that has never been typed into a browser.
How long should the secret be?
RFC 7518 requires a key at least as long as the hash output — 32 bytes for HS256, 48 for HS384 and 64 for HS512. Short, guessable secrets make the signature trivial to forge offline.