Practical usage guide
What this tool does
A JSON Web Token commonly contains three dot-separated Base64URL segments: a header, a payload, and a signature. This page decodes the first two segments so you can inspect claims and converts numeric exp, nbf, and iat values from Unix seconds into readable times.
Decoding is not verification. A malicious sender can alter the header or payload and leave an invalid signature, so decoded claims must never be trusted until a server verifies the expected algorithm, key, issuer, audience, and timing rules.
Quick start
Paste the complete compact token
Use the three-segment value from a trusted debugging context. The page does not need or request your signing secret.
Read header and payload separately
Confirm alg and typ in the header, then review identifiers, roles, issuer, audience, and custom claims in the payload.
Check time-based claims
Compare exp, nbf, and iat with the current time and remember that the JWT standard represents these values in seconds.
Common use cases
Debug authentication flows
Inspect why a token appears expired, has the wrong audience, or lacks an expected application claim.
Review identity-provider output
Compare token claims with the documented issuer, client, scopes, and role mapping during integration work.
Translate JWT time fields
Turn epoch seconds into readable UTC and local dates without sending the token to a decoding service.
Limitations and important notes
Signatures are not verified
The output proves only that the first two segments are decodable JSON. It does not prove authenticity, integrity, or authorization.
JWT payloads are usually readable, not encrypted
Do not place secrets or unnecessary personal data in a signed JWT payload. Anyone holding the token can often decode it.
Avoid production tokens on shared devices
Processing is local, but browser extensions, screen recording, clipboard history, or another person using the device may still expose a live token.