Local JWT decoder, claims inspector and verification checklist
Decode a JSON Web Token locally, inspect the header and payload, read expiration and not-before dates, compare issuer and audience, review signature risk, split the Base64URL sections and prepare the checks needed before trusting a token in an API or application.
Decoding runs in your browser. This tool does not verify the signature with a secret, public key or JWKS endpoint, so decoded content is information, not proof.
A JWT decoder is only the first step
A JSON Web Token is easy to read once it is split into its Base64URL sections, but reading a token is not the same as trusting it. The header can say which algorithm and key identifier were intended. The payload can contain identity, audience, issuer, scope, roles, expiration and custom claims. The signature proves integrity only when the application verifies it with the correct secret or public key and rejects unsafe algorithms.
This JWT decoder is built for practical debugging. It shows the decoded header and payload, checks registered claims, converts Unix timestamps into readable dates, compares issuer and audience against the values you expect, highlights expired or not-yet-valid tokens, warns about alg: none, and explains why a visible signature segment is still not a verified signature. It is useful for API logs, OAuth flows, OpenID Connect debugging, local development and support tickets where you need to understand what a token claims.
How to read a JWT safely
Start with structure. A normal signed JWT has three dot-separated sections: header, payload and signature. The first two are JSON after Base64URL decoding. Then read the time claims. exp defines when the token should stop being accepted, nbf defines when it starts being valid, and iat tells when it was issued. Next, compare iss and aud with the exact service you expected. A token for another API should not be accepted simply because it decodes successfully.
- Header explains algorithm, token type and key selection hints such as
kid. - Payload contains registered claims and application-specific data.
- Claims timeline helps spot expired, future or suspiciously old tokens.
- Signature must be verified server-side or with a trusted public key before use.
- Issues highlights the checks that deserve attention before copying a token into code.
Common JWT debugging situations
If an API returns 401, decode the token and compare the audience, issuer, expiration and scope before changing backend code. If a frontend login loop appears, check whether the browser received an expired token or a token with nbf in the future because of clock drift. If a token has a kid, use the issuer metadata or a trusted JWKS URL to find the public key. Never accept a token because the payload looks correct; attackers can create readable payloads without a valid signature.
Common questions
Does this verify my JWT?
No. It decodes and inspects the token locally. Verification requires the correct secret or public key, strict algorithm rules and issuer/audience checks.
Is a JWT encrypted?
A normal JWT is signed, not encrypted. Anyone who has it can decode header and payload. Do not put secrets in a plain signed JWT.
What is Base64URL?
JWT sections use Base64URL, a URL-safe version of Base64 that replaces certain characters and often omits padding.
Does decoding a JWT verify it?
No. Decoding only Base64-decodes the header and payload. Verification means checking the signature against the secret or public key, which a decoder does not do.
Is it safe to put sensitive data in a JWT?
No. The payload is readable by anyone because it is not encrypted, only signed. Never store secrets in a JWT; include only data you are fine exposing.
Why does my JWT show as expired?
The exp claim is earlier than the current time. JWTs are time-limited; the client must obtain a new one with a refresh token or by re-authenticating.
