JWT Encoder
Compose a token from scratch: choose the claims, supply a secret, and get a signed JWT back. Useful for producing a fixture for a test suite or reproducing a token shape a service is rejecting.
This page opens in encoder mode, with signing performed locally so the secret never leaves your machine.
Claims worth setting deliberately
- exp - expiry, in Unix seconds. Without it the token is valid forever, which is almost never what you want.
- iat - issued-at, also seconds. Lets a verifier reason about token age independently of expiry.
- sub - who the token is about, usually a stable user identifier rather than an email.
- iss and aud - who minted it and who is meant to accept it. A verifier that ignores aud will accept a token issued for a different service.
Seconds, not milliseconds
Every time claim in the spec is seconds since the epoch. JavaScript hands you milliseconds, so a token built from Date.now() without dividing by 1000 expires roughly 50,000 years from now and never rejects.
The rendered date next to each claim makes the mistake obvious immediately, which is the fastest way to catch it.
exp: 1767225600 → 2026-01-01 correct
exp: 1767225600000 → year 57907 milliseconds by mistakeTokens minted here are real
A token signed with your production secret is a production credential regardless of where it was generated. For anything beyond local testing, mint tokens from the service that owns the key, and treat anything produced here as disposable.
Algorithm choice is part of the token
The alg header travels with the token, which means a verifier that trusts it can be told which algorithm to use by an attacker. Pin the expected algorithm on the verifying side and reject anything else.
When generating here, pick the algorithm your verifier already expects rather than assuming it will adapt.