Tools
JWT decoder, explained
Paste a token to see what it says and what each claim means, in plain words.
Beyond decoding, it checks the token against the IETF best practices and NIST IR 8587, and looks at it the way an AI agent would use it: delegation, binding and authority.
Everything runs in your browser. Your token never leaves this page.
🔒 Your token does not leave your browser. Prefer an expired or test token, and revoke it if it comes from production.
Or try a sample
Synthetic and expired, signed with throwaway keys.
Nothing to decode yet. Paste a token above, or pick a sample.
Working with SAML? The SAML decoder, explained →Designing access for AI agents? The architecture builder →Questions
Decode or verify?▾
Decoding only reads what the token says about itself. Anyone can write those words. Verifying checks the signature with a key the issuer published, plus the issuer, audience and dates. This page decodes and explains. Your API must verify.
Why does my token have 5 parts?▾
It is encrypted (JWE). A signed token (JWS) has 3 parts: header, payload, signature. An encrypted one has 5, and its claims can only be read with the decryption key.
What is an opaque token?▾
A random string with no readable content. The API asks the authorization server what it means, through token introspection (RFC 7662). It hides the claims from the client and makes revocation immediate, at the cost of a call per check or a cache.
Why one hour?▾
NIST IR 8587 recommends that access and identity tokens live no more than one hour, shorter for riskier resources. A stolen token works until it expires, so lifetime is the exposure window. Longer lifetimes need compensating controls such as revocation and proof of possession.
What does act mean?▾
It records delegation (RFC 8693): sub is who the token is for, act is who is acting for them. With AI agents, it is how a token says an agent acts for a person instead of letting the agent pass for that person.