JWT Decoder
Decode JWT tokens and inspect their contents
Understanding and decoding a JWT
A JSON Web Token has three dot-separated parts: header, payload and signature. The header names the signing algorithm (alg) and token type (typ); the payload carries claims such as the subject, roles, issued-at time (iat) and expiry (exp). The first two parts are only Base64URL encoded, so their contents can be read without any key.
Paste a token here and the header and payload are shown as formatted JSON, with the signature displayed as-is. When the payload contains an exp claim, the tool reads it and tells you whether the token is still valid or has expired. That is often the quickest way to tell whether an API returning 401 is rejecting an expired token or an unexpected set of claims.
This tool decodes only — it does not verify the signature. Verification requires the secret or public key and belongs on the server. The flip side is that a readable payload is exactly how JWTs are designed to work, which is why confidential data must never be placed inside one. Decoding happens in your browser and the token you paste is never transmitted.
Frequently asked questions
- Is a JWT encrypted?
- In a standard JWT the header and payload are only Base64URL encoded, not encrypted. Anyone holding the token can read them, so never put secrets such as passwords inside.
- Can it verify the signature?
- No, this is a decoder. Verification needs the signing key and should be done server-side, so it is deliberately out of scope here.
- How is expiry determined?
- By reading the exp claim (a UNIX timestamp) from the payload and comparing it with the current time.
- Is the token I paste sent anywhere?
- No, decoding is entirely local. Do remember that a valid token is a live credential, so close the page after use on a shared machine.
