100% local — your data never leaves your browser

JWT to JSON — Read the Claims Inside

Decode a JWT header and payload, signature unchecked. You read exp, iss and the scopes, which is usually what tells you why a token was refused.

Instant Private Zero cookies
Indentation

JWT input

JSON output

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 sub of twenty digits comes through digit for digit, rather than being rounded into a neighbour by a JavaScript number.
  • exp, iat and nbf are 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, iss and aud are 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.

Frequently asked questions

Does this check the signature?
No, and no browser tool can: verifying needs the secret or the public key, which is exactly what you should not paste anywhere. Decoding tells you what the token says; verifying tells you whether to believe it. The payload you see here could have been typed by anyone — Base64URL is encoding, not protection. Verify server-side, with your key.
Is my token sent anywhere?
No. The decoding runs in your browser, and nothing leaves the page — worth knowing, because a production token pasted into an online decoder is a credential handed to a stranger. Even so, prefer an expired or a test token when you can: this page cannot promise anything about the machine you are typing on.
Why is my token refused?
Because it does not have three segments. A JWT in compact form is `header.payload.signature`, and two or four segments used to be decoded anyway, which made a truncated token look like a valid one. Five segments is a JWE — its payload is encrypted, not merely encoded, and nothing can read it without the key. The message now says which case you are in.

Related converters