What this tool does
A token in, its header and payload out as JSON.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpM
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890"
}
}
Both segments are Base64URL, which is an encoding, not a cipher: anybody holding the token can read them, here or with three lines of code. The signature is shown nowhere because there is nothing to read in it — it is a proof, and proving needs a key.
Decoding is not verifying
The payload above says the subject is 1234567890. That it says so proves nothing: change the text, re-encode it, and you get a token that decodes just as cleanly and fails verification. This page cannot tell the difference, and neither can any decoder — that is the whole point of the signature.
So: use a decoder to see what a token claims, use your server and your key to decide whether to trust it. If the two ever disagree, the signature is right.
Three segments, and only three
Not a JWT: expected header.payload.signature, found 2 segments
A compact JWT has exactly three. Two or four used to be decoded all the same, so a token cut short by a copy-paste came back looking perfectly fine — a defect found while writing this page and fixed. Five segments is a different format: a JWE, whose payload is encrypted rather than encoded, and the message says so instead of failing on a decode.
Reading the payload
- Long numeric ids survive. A
subof twenty digits comes through digit for digit, rather than being rounded into a neighbour by a JavaScript number. exp,iatandnbfare Unix timestamps. Seconds, not milliseconds, by the specification. The Unix timestamp tool on this site turns them into dates.- The claims are whatever the issuer put there.
alg,typ,sub,issandaudare standard; the rest is a convention between your two ends.
Private by design
Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.