JWT Parser

Break a token down claim by claim, with iat/exp/nbf decoded into real dates and an expiry verdict.

Security ToolsRuns in your browserFree, no sign-up

JWT

Claim breakdown

Output appears here as you type.

Ctrl + Enter to run

About the JWT Parser

Breaks a token into its parts and renders the claims as readable fields, with the registered ones — `exp`, `iat`, `nbf`, `iss`, `aud`, `sub` — resolved into dates and labelled rather than left as raw epoch numbers.

That is usually what you want when debugging an auth failure, because the answer is very often simply that `exp` has passed or `aud` does not match what the API expects. Everything runs in your browser, so a live token is not transmitted anywhere.

Frequently asked questions

How is this different from the JWT Decoder?

Same token, different question. The decoder shows you the raw JSON, which is what you want when copying a payload. The parser answers "what does this token actually say?" — every claim labelled with its registered meaning, and every timestamp converted from a Unix number into a date plus a relative age. Both share one decoding engine.

Which claims are standard?

RFC 7519 registers seven: iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at) and jti (token ID). Everything else is application-specific. The parser labels the registered ones and shows the rest verbatim.

My token says it is expired but still works. Why?

Expiry is only enforced if the verifier checks it. Some libraries require you to opt in to exp validation, and many allow a clock-skew tolerance of a minute or two. If an expired token is being accepted in production, that is a bug worth fixing in the verifier.