Why it matters
Testing an API that uses JWTs means making tokens: one that's expired, one with the wrong audience, one signed with a rotated key. Doing that with a script for each case is slow, and pasting real signing keys into websites is risky.
This tool signs tokens with your browser's WebCrypto, so keys never leave the page, and can generate a throwaway key pair with a matching JWKS for your test server. The verifier applies the same checks a careful API should: signature, expiry, not-before, issuer and audience. The JWT Decoder reads tokens; this one creates and verifies them.
How it works
- InputClaims and a secret or key
- In your browserSigned or verified with WebCrypto
- OutputA JWT, its public key and a verification report
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Algorithm | Signature characters | Token characters |
|---|---|---|
| HS256 | 43 | 105 |
| RS256 | 342 | 404 |
| PS256 | 342 | 404 |
| ES256 | 86 | 148 |
| ES384 | 128 | 190 |
| EdDSA | 86 | 148 |
How to use it
- Choose the algorithm.
- Edit the header and claims, using the buttons for times and IDs.
- Enter a secret, or generate a test key pair.
- Copy the token, or verify a token in the section below.
FAQ
Which algorithm should I use?
ES256 or EdDSA for new systems: small tokens and fast. RS256 where clients need it. HS256 only when the same service signs and verifies.
How long should an HS256 secret be?
At least 32 random bytes. Short or guessable secrets can be cracked offline from a single token. The Random secret button makes a strong one.
Is it safe to paste a production key?
The key stays in your browser, but treat production signing keys as too sensitive for any website. Use test keys here.
Why does verification say expired?
The exp claim is in the past (with 30 seconds of allowed clock skew). Add a new exp with the buttons and sign again.
