A decoded JWT is still untrusted
Readable claims are a debugging aid. They are not evidence of identity, permission or a valid signature.
Understand the three pieces
A compact signed JWT normally contains a base64url header, a base64url payload and a signature segment separated by dots. Decoding the first two segments reveals JSON, without requiring a signing key. Anyone can construct JSON that says they are an administrator.
This inspector renders those objects as text. It does not retrieve keys, visit jku or x5u addresses, verify a MAC or signature, or decide whether the issuer should be trusted. An alg field is a claim made by the token, not an instruction your verifier should blindly follow.
Use timing claims carefully
The exp, nbf and iat claims use NumericDate: seconds relative to the Unix epoch. They are not JavaScript millisecond timestamps. A value of 1 represents one second after 1970-01-01T00:00:00Z.
The tool compares times to the browser clock and shows UTC or local display. A skewed local clock can change the warning. Missing or correctly timed claims do not compensate for a bad signature.
exp <= browser time → expired warning nbf > browser time → not-yet-active warning iat > browser time → future-issued warning
What actual validation needs
In your application, use a maintained JWT verification library with trusted keys and an explicit allowed-algorithm policy. Check issuer, intended audience, timing and application-specific restrictions. Those checks belong where the authorization decision is made.
For a safe debugging fixture, load the unsigned demo. It is deliberately expired and labeled unverified. Never treat a token copied from a tutorial as a usable credential, and clear real tokens from the page after inspection.
Inspect an explicitly unsigned, expired JWT
Debug the structure of a synthetic token without treating the decoded claims as proof of identity.
Input
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJzeW50aGV0aWMtdXNlciIsImV4cCI6MX0.
Expected output
{
"header": {
"alg": "none",
"typ": "JWT"
},
"payload": {
"sub": "synthetic-user",
"exp": 1
}
}The header says alg=none, the signature is empty, and exp=1 is 1970-01-01T00:00:01Z. The inspector warns that it is unsigned, expired and NOT signature-verified. Real authorization requires trusted keys, an algorithm policy, issuer, audience and timing validation.
Keep the references close
Primary documentation supports the technical details above. Check it alongside the behavior of your own runtime and deployment.
Open JWT inspector →