Decoding a JWT does not verify its signature
Read JWT claims without treating them as trusted, check time units and understand algorithm and issuer validation.
Separate inspection from authentication
A typical signed JWT has three dot-separated parts: header, payload and signature. The first two commonly use Base64url encoding, which is readable without a secret. Anyone who can construct a string can write a payload claiming an administrator role. Seeing that role in a decoder proves only what the supplied token says. Authentication requires signature verification and application-specific claim checks.
Check time claims in seconds
The exp, nbf and iat claims use NumericDate values expressed in seconds since the Unix epoch. JavaScript Date expects milliseconds, so multiply an ordinary integer timestamp by 1000 before displaying it. Confirm the timezone shown. An expired token should not become acceptable because a viewer renders the date in another locale. Servers may use a small documented clock tolerance; a client-side decoder does not define that policy.
Verify with trusted configuration
The receiving service must restrict allowed algorithms and obtain verification keys through a trusted configuration. Validate the issuer and intended audience as well as the signature. Do not choose a key or algorithm solely because untrusted header fields request it. A token with alg set to none must not be accepted where the application expects signed tokens. The exact rules depend on the identity provider and service.
Use the decoder responsibly
The linked decoder inspects the token locally and explicitly reports that the signature is not verified. Use a sample token when documenting a bug, and remove access tokens from screenshots, tickets and shared logs. A JWT may contain readable personal information even when its signature is valid. A five-part encrypted token uses a different structure and cannot be treated as the usual three-part signed token.