JWT Token Inspector
Inspect headers, claims, and expiry without implying verification.
Working notes
Use JWT Token Inspector with the boundary visible.
JWT Token Inspector parses the encoded header and payload and explains registered time claims without claiming the token signature or issuer is trustworthy.
What is JWT Token Inspector?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe string that represents claims between two parties. It is defined by RFC 7519 and consists of three Base64url-encoded parts separated by dots: a header, a payload, and a signature. The header declares the signing algorithm (e.g. HS256, RS256, ES256). The payload carries the claims — key-value pairs such as the subject (sub), issuer (iss), audience (aud), and expiration time (exp). The signature ties the header and payload together cryptographically so the receiver can verify that the content has not been tampered with. JWTs are the standard authentication token in OAuth 2.0, OpenID Connect, and most modern API authentication flows. Because the payload is only Base64-encoded (not encrypted), anyone who intercepts a JWT can read its claims. This is by design — JWTs prove identity and authorization, not confidentiality. When you need to debug a JWT, you want to inspect the decoded header and payload, check the expiration and issued-at timestamps, and confirm the algorithm — all without sending the token to an external server.
When to use it
- Debugging authentication failures — decode the token to check whether it has expired, was issued for the wrong audience, or uses an unexpected signing algorithm.
- Inspecting OAuth tokens — view the scopes, roles, and custom claims embedded in access tokens or ID tokens from providers like Auth0, Okta, or Firebase.
- Verifying token structure before integration — when integrating a third-party SSO, decode sample tokens to confirm the claim names and formats match your expectations.
- Troubleshooting clock skew — compare the iat (issued at) and exp (expires) timestamps against the current time to identify server clock drift.
- Security auditing — check that tokens use strong algorithms (RS256, ES256) instead of deprecated ones (none, HS256 with weak keys).
How to use it
- 01Paste a compact JWT (three dot-separated parts) into the input field.
- 02The tool immediately decodes the Base64url header and payload and displays each claim with its type.
- 03Review the timing claims: exp (expiration), iat (issued at), and nbf (not before) are shown as human-readable dates with a countdown or elapsed indicator.
- 04Check the algorithm in the header to confirm it matches what your server expects.
- 05Verify signatures and issuer policy separately in the system that trusts the token — decoding is not verification.
Common mistakes
- Treating decoding as verification — decoding a JWT only reads its claims. It does not prove the token is authentic. Always verify the signature server-side with the correct key.
- Pasting production tokens into online tools — JWTs are bearer credentials. Sending them to third-party servers risks token theft. StackCache decodes locally, but treat production tokens with care.
- Ignoring the "none" algorithm — a token with alg: "none" has no signature. If your server accepts it, any attacker can forge tokens. Always reject the "none" algorithm in production.
- Confusing HS256 and RS256 — HS256 uses a shared secret (symmetric); RS256 uses an RSA key pair (asymmetric). Mismatching them causes verification failures or, worse, security vulnerabilities.
- Storing sensitive data in the payload — JWT payloads are encoded, not encrypted. Do not put passwords, credit card numbers, or PII in claims unless you use JWE (JSON Web Encryption).
Synthetic example
Inspect synthetic claims
Input
A synthetic JWT containing sub=demo-user and exp=2000000000
Result
Subject: demo-user Expiry: 2033-05-18T03:33:20.000Z
JWT vs session cookies vs API keys
| Feature | JWT | Session cookie | API key |
|---|---|---|---|
| Stateless | Yes | No (server stores session) | Yes |
| Contains claims | Yes (payload) | No (opaque ID) | No |
| Revocable | Not natively | Yes (delete session) | Yes (delete key) |
| Expiry built-in | Yes (exp claim) | Server-managed | Manual |
| Cross-domain | Yes (Authorization header) | Limited (SameSite) | Yes (header) |
| Size | ~300-1000 bytes | ~32 bytes | ~32-64 bytes |
Related standards
Limits and data boundary
- Decoding is not signature verification and does not establish authenticity.
- Treat production tokens as secrets; pasted content remains only in this tab.
Frequently asked questions
- What is a JWT token?
- A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It has three Base64-encoded parts: header, payload, and signature.
- Does this tool verify the JWT signature?
- No. The tool decodes and displays the header and payload but does not verify the cryptographic signature. Signature verification requires the signing key and should be done server-side.
- Is my token safe here?
- The token is decoded locally in your browser and never sent to any server. However, production tokens are sensitive — avoid pasting them into any online tool you do not trust.
- What does the "exp" claim mean?
- The exp claim is a Unix timestamp indicating when the token expires. After this time, the token should be rejected. The tool shows it as a human-readable date with a countdown.
- Can a JWT be tampered with?
- The payload can be read and modified by anyone, but the signature will no longer be valid after modification. The verifying server rejects tokens whose signature does not match the header and payload.
Keep working