JWT Parser
WebDecode and inspect JWT tokens (header, payload, expiry) with a signature structure check. Inspect auth claims and expiry without sending secrets or keys.
Related Tools
About JWT Parser
A JWT is a compact token made of three Base64URL segments, Header, Payload, and Signature, commonly used for sessions and API auth. For example you can paste an eyJ token to inspect its payload. Note it only displays content and does not verify the signature; sensitive tokens are never uploaded, so it is for local debugging rather than production verification.
How to Use
- Open the JWT Parser tool
- Paste the complete JWT string into the input field
- Header and Payload are automatically decoded and displayed as JSON
- Check expiration time, issued at time, and other key info
- Enter the secret key to verify the signature (HS256/384/512 only)
Use Cases
- Debug login state — When users report "login expired", paste the token to inspect expiry time and claims.
- Inspect OAuth / OIDC flows — Examine claims (sub, aud, iss, etc.) inside access_token and id_token issued by an identity provider.
- Validate token structure — Confirm a backend-issued token contains expected custom fields like user_id or role.
- Understand third-party SSO — Study tokens issued by Auth0, Firebase, Okta, or other identity providers.
- Troubleshoot 401 errors — Quickly see whether the token has expired (exp claim) or is not yet valid (nbf claim).
- Custom claim validation — Verify that your backend includes expected custom claims like permissions, tenant_id, or feature flags in the token payload.
- Token size audit — Measure the decoded payload size to identify unnecessarily large tokens that could impact request performance.
FAQ
Is a JWT encrypted?
No. JWTs are only Base64URL encoded by default (not encrypted) — anyone who gets the token can decode and read the payload. Use JWE for confidentiality, or simply do not put secrets in a JWT.
Does this tool verify the signature?
No. Signature verification requires the server's key or public key. This tool only decodes and displays. In production, verify on the backend using libraries like jose or jsonwebtoken.
How do I manually invalidate a JWT?
You cannot — without a server-side blocklist. This is an inherent JWT limitation, which is why access_tokens typically have short lifetimes (minutes) and are paired with refresh_tokens.
Are JWTs more secure than session cookies?
Not necessarily. JWTs suit stateless distributed systems, but HttpOnly + Secure session cookies are also safe. The choice depends on architecture, not security level.
Why is my JWT so long?
The bigger the payload, the bigger the token. Include only essential claims (sub, exp, aud, role). Since the token is sent on every request, oversized JWTs waste bandwidth.
Why does my access token expire so quickly?
Short-lived access tokens (minutes to an hour) are a deliberate, recommended design: they shrink the window a leaked token stays valid, and a refresh token quietly renews them before expiry to keep long sessions alive. It is not a misconfiguration. If it feels too fast, adjust the exp at issuance; the frontend should refresh on 401 or preemptively before exp instead of forcing repeated logins. Also confirm the server clock (NTP) matches issuance time, since drift can invalidate tokens instantly.
What should and should not go in the payload?
Keep it minimal and necessary: sub, exp, iat, aud, iss, role. Never put passwords, phone numbers, or other secrets — JWTs are only Base64URL encoded, so anyone who receives the token can read them. Do not trust client-editable fields such as prices or permissions; enforce them server-side and re-validate on the backend. If confidentiality is genuinely required, switch to JWE encryption or keep sensitive fields in a server session rather than in the token.