JWT Decoder
Paste a token and read what is inside it. The header and payload are base64url, not encrypted, so decoding needs no key and reveals every claim the issuer put there.
This page opens in decoder mode. Nothing is transmitted, which matters because a token you are debugging is usually still valid.
Reading the output
The header names the signing algorithm in alg. The payload carries the claims: sub for the subject, iss for the issuer, aud for the intended audience, and the time claims exp, iat and nbf.
Time claims are rendered as dates alongside their raw values, because they are Unix seconds and a number like 1516239022 tells you nothing at a glance. If a value resolves to a date tens of thousands of years out, the issuer built it from milliseconds - the most common JWT bug there is.
Decoding proves nothing about trust
A decoder will read a token forged in a text editor thirty seconds ago just as happily as a real one. The claims become trustworthy only once the signature is verified against a key, which is a separate operation.
Use the decoder to see what a token says while debugging. Never let a decoded-but-unverified claim decide whether a request is authorised - pin the expected algorithm server-side and reject anything else, including alg: none.
When a token will not decode
- It does not have exactly three dot-separated parts, usually because it was truncated on copy.
- A Bearer prefix or surrounding quotes came along with it.
- It is a JWE rather than a JWS - five segments, and genuinely encrypted.
- It is an opaque session identifier that merely looks like a token, with no structure to read.