JWTs show up everywhere: login sessions, API calls, SSO, and service-to-service auth.
When something breaks, the fastest way to debug is usually to decode the token and look at the claims.
Start here:
- Open the JWT Decoder.
- Paste the token.
- Read the decoded header and payload.
Textavia decodes JWTs in your browser. Your token is not uploaded.
What decoding a JWT does (and what it does not)
A JWT has three base64url-encoded parts:
header.payload.signature
Decoding a JWT means:
- turning
headerandpayloadinto readable JSON
Decoding does not mean:
- verifying the signature
- proving the token is authentic
- proving the token is not expired
A token can be decoded even if it was tampered with.
If you are debugging an auth system, decoding is step one. Verification is step two.
Quick start: decode a JWT and spot the problem
- Open the JWT Decoder.
- Paste the token.
- Look for these fields:
exp(expiration)nbf(not before)iss(issuer)aud(audience)sub(subject / user id)
- If
explooks wrong, convert it with the Unix Timestamp Converter.
Common JWT claims (what you are usually looking for)
| Claim | Meaning | Why it breaks |
|---|---|---|
exp | expiration time | clock skew; wrong unit; token is old |
nbf | not valid before | client clock is behind |
iss | who issued it | wrong environment (dev vs prod) |
aud | intended audience | wrong API/resource id |
scope / roles | permissions | missing role; wrong scope string |
Examples
Example 1 (beginner): check if a token is expired
If the payload contains exp, it is usually a Unix timestamp.
- Decode the JWT.
- Copy the
expvalue. - Convert it with the Unix Timestamp Converter.
If the token is expired, that is the bug.
Example 2 (professional): debug an "invalid audience" error
If your API expects aud: "api://billing" but you see aud: "api://core", you are using a token minted for a different service.
Fix the client configuration or token issuer settings.
Example 3 (professional): confirm signing algorithm
Look at the header:
algtells you the signing algorithm
If you expected RS256 but see HS256, your systems might be using different keys or libraries.
Common JWT decoder errors
"Invalid JWT format"
A JWT must have exactly 3 parts separated by dots.
If you only have 2 parts:
- you might be looking at a JWS variant or a truncated token
- or the token was copied incorrectly
"Invalid Base64 encoding"
JWTs use base64url encoding.
If the token was URL-encoded inside a query string, decode it first with the URL encoder/decoder.
"Malformed JSON"
If decoding succeeds but JSON parsing fails, the token is corrupted or not a JWT.
Common mistakes that cause security bugs
- Treating decoded claims as trusted without verifying the signature
- Putting sensitive data in the payload (anyone who has the token can decode it)
- Using long-lived tokens without rotation or revocation
If you need to see the contents for debugging, decode it. If you need to trust it, verify it.
If you only do 3 things
- Decode to inspect claims.
- Verify signature before trusting anything.
- Convert
exp/nbftimestamps to human time.
Sources and further reading
- RFC 7519: JSON Web Token (JWT)
- RFC 7515: JSON Web Signature (JWS)
Related tools
- Decode base64url fragments with the Base64 tool.
- Format JSON output with the JSON formatter.
Privacy and security
Textavia's JWT decoder runs locally in your browser. Your token is not uploaded to a server.
Still: treat JWTs like credentials. Avoid decoding tokens on shared computers.