JWT Decoder

How to decode a JWT

1. Paste the token into the box above, or click Load sample to see how it looks. It decodes automatically as you type. Paste only the token itself — remove any Bearer prefix copied from an Authorization header.
2. Read the header (the signing algorithm and token type) and the payload (the claims: user id, roles, expiry and so on). Both are shown as formatted JSON with a copy button.
3. Check the claims table, which turns the iat, nbf and exp timestamps into UTC dates and tells you whether the token has expired.

Anatomy of a JWT

A JSON Web Token is three base64url strings joined by dots: header.payload.signature. Base64url is base64 with - and _ in place of + and / and no trailing = padding, which keeps the token safe inside URLs and HTTP headers. The sample token decodes to a header of {"alg":"HS256","typ":"JWT"} and a payload with sub, name, role, iat and exp claims. The signature is the third segment, a cryptographic hash of the first two. It is shown as-is, because it is binary data, not readable text.

Common claims you will see

• sub — the subject, usually a user id.
• iss and aud — who issued the token and who it is meant for.
• iat, nbf, exp — issued-at, not-before and expiry, in Unix seconds.
• scope, roles or custom fields — permissions, defined by whoever built the API.

Decoding is not verifying

Anyone holding a token can read it, because the header and payload are only encoded, not encrypted. Decoding therefore proves nothing about whether the token is genuine. Verification means recomputing the signature with the secret (HS256) or the issuer's public key (RS256, ES256) and comparing it, and it also means checking that iss, aud and expiry are what your application expects. That belongs on your server, so this page never asks for a key and shows the signature as “not verified”. A token that decodes cleanly here may still be forged, so never trust claims you have only decoded. Because payloads are readable, never put passwords or other secrets in them.

Debugging a 401 with the claims table

When an API rejects a token, check three things in order. First, expiry: the table reads “expired 3 hours ago” or “expires in 12 minutes” so you can see at once if the token simply timed out. Second, audience and issuer: a token minted for one environment, such as staging, is often rejected by another. Third, clock skew: if iat or nbf is slightly in the future relative to the server, the server may reject a brand-new token.

Limits of this tool

• It reads iat, nbf and exp only when they are numbers in seconds. A value in milliseconds will show a date thousands of years away.
• Only exp is flagged as expired or valid; nbf is displayed but not judged.
• Encrypted tokens (JWE, five segments) cannot be read, because their payload is not plain JSON, and you will see an error instead.
• A token with an empty third segment (an unsigned token) still decodes, and the signature area shows “(none)”. Treat any unsigned token as untrusted.

Need to convert a timestamp from the payload by hand? Try the Timestamp Converter. To inspect other base64 text, use Base64 Encode & Decode.

Is it private and safe?

The token is decoded in your browser with JavaScript and is never uploaded, logged or sent anywhere. Many online JWT tools work differently, so check before pasting a live token anywhere. As a habit, prefer short-lived or test tokens when debugging, and treat any production token you have pasted into a website as exposed: log out or rotate it. Decoding only needs the first two segments, so you can delete the signature (the last dot and everything after it) before pasting; the claims still appear.

Related guides

Timestamps in claims are explained in Unix timestamps explained. If a payload will not parse, see how to fix JSON syntax errors, and tidy large payloads with the JSON Formatter.