LicenseManagerJWT debugger
Paste a JSON Web Token to decode it, check its signature, and read its claims and dates in UTC and in your time zone. Edit it to sign a new one. Everything runs in your browser.
Encoded token
Header
Payload
Signature
What is a JWT?
A JSON Web Token (JWT, RFC 7519) is a compact way to pass claims between two parties, like who a user is and until when. It has three parts, base64url encoded and separated by dots: header.payload.signature.
The header says how the token is signed, in alg, and often which key signed it, in kid. The payload holds the claims. The signature covers both: change a single character and it no longer matches.
The payload is encoded, not encrypted: anyone holding a token can read it, like this debugger does. Never put secrets in it.
Registered claims
RFC 7519 defines seven claims. None is required, but libraries check them for you when they're present.
iss- Issuer. Who issued the token, often the URL of the authorization server.
sub- Subject. Who or what the token is about, like a user ID. Unique for the issuer.
aud- Audience. Who the token is for. A receiver should reject a token whose audience doesn't include itself.
exp- Expiration time. The token must be rejected after this date.
nbf- Not before. The token must be rejected before this date.
iat- Issued at. When the token was issued.
jti- JWT ID. Unique ID of the token, to detect replays or revoke it.
Dates are in seconds since January 1, 1970 UTC, not milliseconds. A date in milliseconds reads as a date tens of thousands of years from now.
Verifying a JWT in your code
Decoding a token is not verifying it. Before trusting its claims, check:
- The signature, with the issuer's secret or public key.
- The algorithm: accept only the one you expect. Never
none, and never HMAC when you expect RSA, or a public key becomes a secret anyone can sign with. - The dates:
expis in the future,nbfin the past, with a minute or two of leeway for clocks. - The audience and issuer:
audis you, andissthe issuer you expect.
LicenseManager uses JWTs signed with Ed25519 for offline license validation: the example above is one of them. Your app verifies it with a public key compiled into its code, and keeps working without a connection.
Questions
The debugger runs in your browser: tokens, secrets and keys are decoded, verified and signed on your device, and never sent to a server. Still, a token is a password for as long as it's valid: avoid pasting production tokens anywhere you don't need to.
The token was signed with another key, or changed after it was signed. Check that the secret or public key is the one of the issuer, and for HMAC secrets, whether the secret is base64 encoded. A JWKS works too: the key is picked by the kid of the header.
Not alone. Your code should also accept only the algorithm it expects, reject expired tokens and tokens used before their nbf date, and check the audience (aud) and issuer (iss).
HS256, HS384 and HS512 with a shared secret, RS256, RS384, RS512, PS256, PS384 and PS512 with RSA keys, ES256, ES384 and ES512 with elliptic curve keys, and EdDSA with Ed25519 keys. Public keys can be PEM, X.509 certificates, JWK or JWKS.
Edit the header or the payload: the token updates as you type, signed with the secret or private key of the Signature panel. Pick an algorithm to start from a new secret or key pair.
It reads their header only. The payload of a JWE is encrypted, and needs the recipient's private key to decrypt.
More free tools
Licenses that work offline
LicenseManager validates license keys with one request, and issues signed tokens your app checks without a connection.