How to Decode and Inspect JWT Tokens
JSON Web Tokens (JWTs) are the most common way to handle authentication in modern web applications. When something goes wrong with auth — a user gets logged out unexpectedly, permissions are wrong, or an API returns 401 — decoding the JWT is usually the first debugging step.
What is inside a JWT
A JWT has three parts, separated by dots:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
Header — contains the algorithm (HS256, RS256, etc.) and token type.
{"alg": "HS256", "typ": "JWT"}
Payload — contains claims (data assertions) about the user and token.
{"sub": "1234567890", "name": "Alice", "exp": 1700000000}
Signature — a cryptographic hash that verifies the token has not been tampered with. You cannot read this without the signing key.
Common JWT claims
| Claim | Full name | What it contains |
|---|---|---|
sub |
Subject | User ID or identifier |
exp |
Expiration | Unix timestamp when token expires |
iat |
Issued At | Unix timestamp when token was created |
iss |
Issuer | Who created the token (your auth server) |
aud |
Audience | Who the token is intended for |
nbf |
Not Before | Token is not valid before this time |
jti |
JWT ID | Unique identifier for the token |
How to decode a JWT
- Paste your token — enter the complete JWT (header.payload.signature format) into the decoder.
- View the decoded sections — the tool displays the header (algorithm), payload (claims), and signature as formatted JSON.
- Check the claims — examine the expiration time, issuer, subject, and any custom claims.
Debugging with JWTs
Token expired? Check the exp claim. Convert the Unix timestamp to a human-readable date. If it is in the past, the token has expired and needs to be refreshed.
Wrong permissions? Look for role or scope claims in the payload. These vary by implementation but often look like "role": "admin" or "scope": "read write".
User identity issues? The sub claim identifies the user. Verify it matches the expected user ID.
Token not accepted? Check the aud (audience) claim. If the API expects a specific audience value and the token has a different one, it will be rejected.
Important security notes
- JWTs are not encrypted — anyone can decode the payload. Do not put passwords, API keys, or other secrets in a JWT.
- Always verify signatures on the server — a decoder shows you what the token claims, but only signature verification proves it has not been tampered with.
- Check expiration — expired tokens should always be rejected. If your app is accepting expired tokens, that is a security bug.
Frequently Asked Questions
Can I verify a JWT signature with a decoder?
No. Signature verification requires the signing secret or public key, which is kept on your server. A decoder shows you what is inside the token, but cryptographic verification must happen on your backend. Never trust an unverified JWT in production.
Is it safe to paste a JWT into an online tool?
Yes, when the tool runs in your browser. Browser-based decoders process the token locally — nothing is sent to a server. Avoid tools that make network requests with your token.
What is the exp claim?
The exp (expiration) claim is a Unix timestamp indicating when the token expires. After this time, the token should be rejected. Always check this claim when debugging authentication issues.
Can JWTs be encrypted?
Standard JWTs (JWS) are signed but not encrypted — anyone can decode the payload. JWE (JSON Web Encryption) tokens are encrypted, but they are less common. Never put sensitive data (passwords, secrets) in a standard JWT payload.