JSON Web Token (JWT) Decoder
Decode and inspect JSON Web Token headers, payload claims, and expiration timestamps locally without sending secrets over the network.
{
/* Header will appear here */
} {
/* Payload claims will appear here */
} Registered & Custom Claims Breakdown
| Claim | Value | Description |
|---|---|---|
| Paste a JWT to inspect registered claims | ||
Signature & Security Audit
About JSON Web Token (JWT) Decoder
JSON Web Tokens (JWT) are a compact, URL-safe standard (RFC 7519) for transmitting claims between parties in web applications. They are ubiquitous in modern OAuth, OpenID Connect, and session authentication flows.
This tool decodes and inspects the Header and Payload segments of a JWT without transmitting the token across the network. It parses standard claims, formats payload JSON, evaluates expiration timestamps against your local clock, and displays status indicators.
Local execution ensures that confidential session tokens, user email addresses, permission claims, and tenant identifiers are never exposed to remote logging services.
To audit security tokens, decode binary strings via the Base64 encoder and decoder and translate expiration timestamps with the Unix epoch converter.
Step-by-step practical guide
- Paste your encoded JWT string (starting with eyJ...) into the token input field.
- Inspect the Header panel to verify the signing algorithm (such as RS256 or HS256) and token type.
- Inspect the Payload panel to review user claims, roles, email addresses, and permissions.
- Check the expiration banner above the panels to see if the token is currently valid or expired.
- Use the Clear button to remove the token from the workspace when finished.
- Verify expiration dates to debug unexpected 401 Unauthorized API responses.
Engineering specifications and execution details
Decodes the Base64Url-encoded segments into UTF-8 JSON objects entirely in client memory without network transmission.
Parses standard RFC 7519 registered claims: exp (expiration time), iat (issued at), nbf (not before), sub (subject), iss (issuer), aud (audience), and jti (JWT ID).
Timestamps are parsed and compared against Date.now() to provide real-time expiration badges and elapsed/remaining duration countdowns.
Visual segmented token highlighter categorizes components into distinct colors (Header in red, Payload in purple, Signature in blue).
Formats decoded payload and header objects with readable two-space JSON indentation and one-click clipboard copying.
Inspects cryptographic algorithm headers (HS256, RS256, ES256) and flags insecure tokens configured with alg: "none".
Data privacy and memory isolation
All decoding runs strictly on your device inside the local browser JavaScript engine.
No JWT payloads, bearer tokens, or user claims are sent to remote servers or stored in cookies.
Common production use cases
- Frontend developers verifying claims and user roles returned by authentication providers like Auth0, Firebase, or Supabase.
- Backend engineers debugging token expiration timeouts and clock skew issues.
- QA testers inspecting session tokens during integration and API testing.
- DevOps teams validating service-to-service service account identity tokens.
- Security researchers inspecting token scopes and issuer configurations.
Edge cases and operational boundaries
- Zero signature verification: This tool is an in-browser decoder, not a cryptographic verifier. It decodes the claims so you can read them, but verifying the signature requires your application server public certificate or private secret key.
- Clock skew: If your computer system clock is inaccurate, the expiration banner may report expired or valid incorrectly.
- Malformed tokens: Tokens that lack three period-separated segments will trigger a syntax warning explaining the missing token components.
- Nested JWTs: If a token payload contains an encrypted inner token (JWE), only the outer structure is inspectable.
Frequently Asked Questions
Is it safe to paste sensitive tokens into this decoder?
Yes. All decoding runs purely in your local browser JavaScript engine. No token is ever uploaded, logged, or sent to any server.
Can this tool verify the signature of my token?
No. Signature verification requires either your private secret key (for HMAC) or public certificate (for RSA), which should never be pasted into public web tools.
Why is a JWT split into three parts?
A standard JWT consists of three dot-separated sections: Header (algorithm details), Payload (claims and user data), and Signature (cryptographic proof of authenticity).
How are expiration times stored in a JWT?
The exp claim stores a Unix timestamp representing the number of seconds since January 1, 1970 UTC.
What is the difference between HS256 and RS256?
HS256 uses a symmetric shared secret key to both sign and verify tokens. RS256 uses an asymmetric key pair: a private key signs the token, and a public key verifies it.
What does the "nbf" claim mean?
The "nbf" (Not Before) claim identifies the time before which the JWT must not be accepted for processing by the server.
Can an expired JWT still be decoded?
Yes. Expiration does not destroy token structure or prevent decoding; it simply informs verifying servers that the token is no longer valid.
What is the security risk of alg: "none"?
The "none" algorithm indicates an unsecured token with no digital signature. If a backend API accepts tokens with alg: "none", attackers could forge arbitrary administrative claims without signature verification.
How do I resolve unexpected 401 Unauthorized errors with my JWT?
Inspect the token in this tool: verify whether the exp timestamp has passed, check that the iss (issuer) and aud (audience) match API requirements, and confirm that required role or scope claims exist in the payload.