JWT Generator

Builds a JSON Web Token from a payload you write and signs it with HS256, HS384, HS512, RS256, or ES256, then shows the finished token alongside its decoded header, payload, and signature. Checkboxes add the standard time claims (iat, nbf, and an exp a chosen number of seconds out), and a clock override makes the result reproducible for tests. Verify mode goes the other way: paste a token and the matching secret or public key, and it reports whether the signature holds and whether the token is inside its validity window.

Write the claims as JSON in the input box, then put the signing key in the Secret or private key option: the shared secret for an HS algorithm, or a PKCS#8 PEM private key for RS256 and ES256. That option is masked, folds away behind a Reveal button once it holds a PEM block, and is never written to the address bar. For a quick asymmetric test with no key of your own, turn on the demo key pair option and both PEM blocks come back with the token. To check a token, switch Mode to Verify, paste the token into the input box, and put the secret or PEM public key in the same option; on Auto the algorithm is read from the token's own header, and picking one explicitly checks the token against that algorithm instead. The older form still works: leave the option empty and put the key below a line of three dashes.

The usual JWT playground is a hosted page that wants your signing key typed into a form field on somebody else's origin, and several of them keep the field's contents in the query string. Here the signing runs in the browser's own cryptography engine, the key stays in a masked field that is never written to the URL, and your files and inputs never leave your device. There is no server endpoint at all, on purpose, because a hosted signing endpoint would mean production keys crossing the network.

Which algorithm should I pick?

HS256 when one service both issues and checks the token, because it is one shared secret and nothing else. RS256 or ES256 when someone else has to verify tokens you issue: they only need your public key, so a verifier cannot mint tokens of its own. ES256 keys and signatures are far smaller than RSA ones, which matters if the token travels in a header. Never accept a token whose header says alg is none; this tool refuses to.

Why does it want a PKCS#8 PEM specifically?

Because that is the one private key format the browser's WebCrypto API imports. If your file starts with BEGIN RSA PRIVATE KEY or BEGIN EC PRIVATE KEY, it is the older PKCS#1 or SEC1 form, and one command converts it: openssl pkcs8 -topk8 -nocrypt -in key.pem -out key.pk8.pem. For verifying, the public key has to be the SubjectPublicKeyInfo form, which you get with openssl pkey -in key.pem -pubout.

Is a token I make here safe to use in production?

The token itself is a real, correctly signed JWT, so yes, technically. The judgment call is whether to type a production signing key into a browser tab at all. For a staging secret, a local development key, or a demo key pair generated right here, this is fine. For the key that guards a live system, sign on the server that owns it and use this tool with a throwaway key to work out the shape of the token first.

Why does the same ES256 payload give a different token every time?

ECDSA mixes a fresh random value into every signature, so two signatures over identical bytes never match. That is expected and does not weaken anything, as long as the randomness is good. RS256 and the HS algorithms are deterministic, so they do produce the same token twice for the same input, which is why the examples here pin an HS256 and an RS256 token but not an ES256 one.