JWT Generator and Verifier

How to create a signed JWT

1. Choose the Algorithm: HS256/384/512 (shared secret), RS256/384/512 or PS256/384/512 (RSA), ES256/384/512 (ECDSA on P-256, P-384 or P-521), or EdDSA (Ed25519, when your browser supports it).
2. Edit the Header (JSON) and the Payload (JSON claims). The alg field always follows the selected algorithm, and typ defaults to JWT.
3. Use the time claim buttons to add dates: iat = now, nbf = now, or pick a delay such as “in 1 hour” and click Set exp. The values are NumericDates: seconds since 1 January 1970 UTC.
4. Enter the Secret (HS algorithms, as text or Base64/Base64url under Secret format) or the Private key (PEM or JWK). No key yet? Click Generate test key.
5. Click Sign token, then Copy the result or click Verify this token to check it right away.

How to verify a JWT

1. Paste the token under Token to verify.
2. Pick the Expected algorithm. Leaving it on “From the token header” accepts whatever the header says, except none; choosing a specific algorithm makes the tool refuse any token signed differently, as a real server should.
3. Enter the secret, or the Public key (PEM or JWK): a PUBLIC KEY, RSA PUBLIC KEY or CERTIFICATE PEM block, a JWK, or a JWK Set (the key whose kid matches the header is used).
4. Optionally set a Clock leeway (seconds) to tolerate small clock differences, then click Verify token.

The result says whether the signature is valid, and then checks exp (expiration) and nbf (not before) against your computer’s current time. A token with a correct signature but an expiry in the past is reported as expired, not as valid.

Keys and formats

For signing, the tool accepts PKCS#8 PRIVATE KEY blocks, PKCS#1 RSA PRIVATE KEY and SEC1 EC PRIVATE KEY blocks (converted to PKCS#8 internally), and private JWKs. Password-protected keys must first be exported without a password. Generate test key creates a random secret of the hash size for HS algorithms, a 2048-bit RSA key pair for RS and PS, the matching curve for ES, or an Ed25519 pair. You get the keys as PEM and JWK, and they are filled in on both sides so a round trip works immediately.

Signatures follow RFC 7515 and RFC 7518: RSA-PSS uses a salt as long as the hash, and ECDSA signatures are the raw r||s concatenation. The implementation reproduces the HS256 example of RFC 7515, Appendix A.1.

Security notes

• Everything runs in your browser with the Web Crypto API. Neither the tokens nor the keys are sent anywhere, but still prefer test keys over production secrets.
• alg: none is never signed and never accepted.
• HMAC secrets should be at least as long as the hash (32 bytes for HS256). A shorter secret triggers a warning.
• A signature proves integrity and origin, not that the claims are appropriate: servers must also check iss, aud and the scopes.