Guide · Developer
How to Decode a JWT and Read Its Claims Safely
See what is inside a JSON Web Token, check when it expires, understand the standard claims, and learn why decoding is not the same as verifying.
- Author
- VoltKit
- Published
- Reading time
- 2 min read
A JSON Web Token (JWT) is the string an app sends with each request to prove who the user is. It looks like random text, but two of its three parts are plain JSON that you can read. Decoding one tells you which user it belongs to, what it allows, and when it expires, which is the first step in debugging most login problems.
Step 1: Find the token
Tokens usually travel in an Authorization: Bearer … header, a cookie, or your app's local storage. In the browser's developer tools, open the Network tab, select a request to your API, and copy the value after Bearer.
Step 2: Paste it into the decoder
The decoder accepts the raw token or the whole Bearer … value. As soon as you paste, it shows the header, the payload and the signature segment in different colours.
Step 3: Read the claims
The payload is a set of claims. The standard ones are:
| Claim | Meaning |
|---|---|
iss | Issuer: who created the token |
sub | Subject: the user or account it is about |
aud | Audience: which service should accept it |
exp | Expiry time as a Unix timestamp (seconds) |
iat | Issued-at time |
nbf | Not valid before this time |
jti | Unique token id |
The decoder converts exp, iat and nbf to readable dates and flags an expired token. To convert other timestamps, use the Unix Timestamp Converter.
Step 4: Check the warnings
The tool warns when a token is expired, not yet valid, has no expiry, or uses the algorithm none. A token with "alg": "none" is unsigned and must never be trusted by a server.
Decoding is not verification
The signature at the end is computed with a secret or private key that only the issuer has. Reading the payload does not check that signature, so anyone can hand-craft a token that decodes perfectly. Access decisions belong on the server, after verification with the key. Use a decoder to understand tokens, never to trust them.
Common problems
- "Not valid Base64-encoded JSON". The token was truncated when copied, or it is not a JWT at all (opaque session ids look similar).
- Five parts instead of three. That is a JWE, an encrypted token. Its contents cannot be read without the decryption key.
- Dates in the wrong time zone. Timestamps are UTC; the decoder shows your local time plus a relative time so you can compare quickly.
Frequently asked questions
Can I tell if a JWT is valid by decoding it?
No. Decoding shows the contents; validity depends on the signature, which only the server holding the key can verify. A decoded token that looks fine may still be forged or revoked.
Why does my token show an expiry in the past?
The exp claim is a Unix timestamp in seconds. If it is earlier than now, the token has expired and the server will reject it. Request a new one.
Is it safe to paste a production token into a decoder?
VoltKit's decoder never sends the token anywhere, but a token is a credential. Prefer test tokens, and never paste tokens into tools that upload them.