JWT Decoder
Decode a JSON Web Token's header and payload without verifying the signature.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
A JSON Web Token is three Base64url segments joined by dots: header, payload, signature. This tool splits them and shows the decoded header and payload, with exp, iat and nbf claims rendered as readable dates and expired tokens flagged. It does not verify the signature — a clean decode means the token is well-formed, not that it is valid — and it warns when the header declares alg "none". Decoding happens locally, which makes it a safer way to inspect a token than pasting it into a site that could log it.
How it works
Token = header.payload.signature (three dot-separated parts) Header and payload = JSON.parse(Base64url.decode(segment)) Claim date = Unix timestamp in seconds × 1,000 → UTC
Paste the token itself to inspect its header and payload locally in your browser. Base64url is an encoding anyone can decode; this tool does not verify the signature, authenticate the issuer, or establish that claims are trustworthy. Numeric exp, iat and nbf claims are displayed as UTC dates, and exp is marked expired when it is earlier than your browser's current time. A successful decode is possible even with an arbitrary signature or an empty signature; alg none triggers a warning. Do not include the Authorization header's Bearer prefix.
| Question | Working | Answer |
|---|---|---|
| Decode eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.sig | Split at the two dots, Base64url-decode the first two segments, and parse their JSON. The sample signature sig is not verified. | Header: { "alg": "HS256" } Payload: { "sub": "1" } |
| Decode eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MDAwMDAwMDB9.sig: what does exp mean? | The payload is {"exp":1700000000}. Multiply by 1,000 to convert epoch seconds to milliseconds. At 2023-11-15 00:00 UTC, that date is in the past. | exp: 2023-11-14 22:13:20 UTC · expired (at the stated comparison time; this does not verify the signature). |
| Decode eyJhbGciOiJub25lIn0.eyJzdWIiOiIxIn0. with an empty signature | There are still three parts because of the trailing dot. The decoder accepts the JSON and warns that alg is none. | Header: { "alg": "none" } Payload: { "sub": "1" } Warning: the token claims to need no signature. Decoding does not establish authenticity. |
| Why does abc.def fail? | Splitting at the dot produces only two segments; the decoder stops before trying to decode their contents. | A JWT has 3 dot-separated parts (header.payload.signature) — this input has 2. |
| Why does eyJhbGciOiJIUzI1NiJ9.aGVsbG8.sig fail? | The payload segment decodes to hello, which is plain text rather than valid JSON. Base64url alone is insufficient. | Payload segment isn't valid base64url-encoded JSON. |
When to use it
Questions
Does decoding verify the signature?
No. Verification needs the appropriate secret or public key and can be performed by a relying application, such as the API receiving the token. For asymmetric signing, the issuer may publish public keys in a JWKS. A verifier must also enforce allowed algorithms and validate the expected issuer, audience and time claims. Anyone can change a token's header and payload and re-encode them, which is exactly why decoded claims prove nothing on their own.
Is it safe to paste a token here?
Decoding runs locally in your browser and the token is not transmitted. Treat any long-lived token as sensitive regardless: if it may have leaked, revoke it instead of hoping nobody recorded it.
Why does my token fail to decode?
This decoder expects the three-part compact JWS form: a Base64url-encoded JSON header, a Base64url-encoded JSON claims payload and a signature segment. The signature is not JSON and can be empty for an unsigned token, which the tool flags. Extra parts or invalid header/payload JSON produce a decoding error. Encrypted compact JWE tokens have five parts and need a different tool. Truncated copies are the usual culprit — paste the whole token, including the final segment.
What is the difference between a JWT's header, payload and signature?
The header names the signing algorithm and token type, the payload carries the claims, and the signature is what ties both to the issuer's key. The first two are plain Base64url — anyone can read them, which is why the decode is instant. The signature exists so the server holding the key can prove neither part was altered; decoding shows you the contents, never their authenticity.
What do the exp, iat and nbf claims mean?
All three are timestamps in seconds since the Unix epoch. iat is when the token was issued, nbf is the earliest time it counts as valid, and exp is when it stops being valid — after that date a server should reject it, and this tool flags the token as expired. If a token you were handed died sooner than expected, exp is the claim to read first.
What is the x5c header field?
In the JOSE header, x5c carries the signing key as an X.509 certificate chain (RFC 7517 §4.7) — the leaf certificate first, each entry standard base64 of a DER certificate. Reading the certificate only shows its stated identity; establishing trust requires certificate and key validation. The JWKS Key Set Viewer decodes x5c chains to readable PEM certificates; this tool deliberately stays decode-only.
Why does decoding my token show garbage or an error?
Two common causes. If the string is valid Base64 but the payload is unreadable, it is probably an encrypted token — a JWE — whose payload is ciphertext, not JSON; JWT only guarantees readable claims for a plain JWS token. If it does not decode at all, check for a truncated copy, a missing third segment, or a token from a non-JWT scheme that merely looks similar.