Developer / TOOLKIT
JWT Decoder
Inspect the JSON header and claims of a three-part compact token. Read time claims in UTC. Decoding does not verify a signature or authorize access.
Free to use · No account needed
Synthetic sample only. The sample signature is a placeholder and is not verified.
Inspect a test token
- Use a synthetic token, a redacted test value, or the built-in sample.
- Select Decode to read the header and payload JSON.
- Check
exp,nbfandiatin the readable UTC display. Then validate the actual token in your application’s trusted verification library.
The sample contains invented claims and a placeholder signature. It demonstrates decoding only; it is not a valid credential.
Worked example: a time claim
Given a synthetic payload {"sub":"test-user","exp":1704067200}, the expiry display is 2024-01-01 00:00:00 UTC. The number uses seconds since the Unix epoch, not JavaScript milliseconds. That value is expired relative to today, but an expiry display alone says nothing about who issued the token.
If your claim uses milliseconds by mistake, the displayed year will be far in the future. Compare the original number with your issuer’s expected format rather than treating that date as evidence of validity.
What decoding can and cannot tell you
| Check | What this page shows | What still needs validation |
|---|---|---|
| Header | The declared algorithm and token type | Whether the algorithm is allowed by your verifier |
| Claims | The supplied subject, issuer, audience and time values | Trusted issuer, expected audience, signature and policy |
| Expiry | A readable date and current time comparison | Whether the verified token meets all acceptance rules |
A client can verify an asymmetric signature using a trusted public key; HMAC verification uses a shared secret. It is incorrect to say that only a server with a secret key can verify every JWT. This decoder accepts no key and performs neither operation.
Supported format and privacy
This interface expects three dot-separated compact JWS parts and JSON objects for header and payload. It does not decrypt five-part compact JWE tokens. A two-part string is incomplete for this interface; an unsecured alg: none compact JWS still has a third, empty signature part.
Use test data and avoid exposing live bearer credentials. Input is decoded on this device and is not uploaded by the decoder. Optional site analytics is subject to your privacy choice. A previously loaded page can decode without a new request; fresh offline loading or refresh is not guaranteed.
Sources and review scope
RFC 7519: JWT and NumericDate, RFC 7515 §3.1: compact JWS, and RFC 7516 §3.1: compact JWE. Reviewed October 11, 2026 for this page’s implemented decoding scope. No signature verification or penetration test is claimed.
Boundary and failure cases
A readable header and payload never prove authenticity. Compact JWS is three base64url segments; anyone can mint a token with alg set to none or with a public key they control. Signature verification, algorithm allow-lists, issuer and audience checks belong in your trusted server library.
Encrypted tokens (JWE) use five segments and will not decode as JWS here. Likewise, nested JWTs, non-compact serializations and unusual critical header parameters are out of scope. Treat an error message as a format mismatch, not as evidence that the token is safe.
Time claims (exp, nbf, iat) are compared against this browser's clock when shown. Clock skew, missing claims and untrusted claim values remain your application's problem. Never paste a live production bearer token into any online decoder — including this local page if the device is shared.