JWT Decoder Online

Q: What does the JWT exp claim mean and why does it matter?

The exp (expiration) claim is a Unix timestamp (seconds since January 1, 1970) indicating when the token becomes invalid. Your server should reject any request with a token where the current time exceeds the exp value. Short-lived tokens (15 minutes to 1 hour) limit the damage window if a token is stolen — an attacker has only until expiry to misuse it. Refresh tokens (longer-lived, typically 7-30 days) are used to obtain new access tokens without re-authentication. Common debugging issue: if exp has 13 digits instead of 10, the issuer used milliseconds — divide by 1000 to get the correct Unix timestamp. The decoder automatically converts exp to human-readable date and shows "expired X minutes ago" or "expires in X hours."

Decode and inspect JWT tokens instantly — view header, payload, and signature in a formatted, human-readable structure. Free browser-based JWT decoder with no data sent to servers.

Why Decode JWT Tokens?

Debug authentication issues: When login or authorization fails, decoding the JWT reveals expired claims, wrong audiences, incorrect roles, or missing required fields — the most common root causes of auth failures.
Inspect token contents during development: Verify that your auth server is issuing tokens with the correct claims before integrating with protected APIs — catch misconfiguration early in the development cycle.
Verify token expiry: Check the exp claim to determine when a token expires — essential for debugging sessions that unexpectedly end or for understanding token refresh timing.
Validate token structure: Confirm that a JWT is well-formed (three Base64URL-encoded segments separated by dots) and that the algorithm in the header matches what your server expects.
Security auditing: Audit JWTs from third-party identity providers to confirm they're issuing only the claims your application needs — over-provisioned tokens with unnecessary sensitive claims present security risks.

Decode Now

How to Decode a JWT Token

Copy the JWT: Obtain your token from a browser's localStorage, the Authorization header in network requests, a cookie value, or your application's auth response — it looks like three Base64URL strings separated by dots.
Paste into the decoder: Paste the full JWT (including all three segments) into the input field — the decoder automatically identifies the three parts.
Read the header: The first segment decodes to the algorithm (alg) and token type (typ) — for example {"alg":"HS256","typ":"JWT"}.
Read the payload: The second segment contains the claims — standard claims like sub (subject/user ID), iat (issued at), exp (expiry), aud (audience), and any custom application claims.
Note the signature: The third segment is the cryptographic signature — it cannot be decoded into readable text, but the decoder confirms whether the token structure is valid.

Real-World Use Case

A developer integrating with a third-party OAuth provider finds that their API calls return 403 Forbidden despite successful authentication. Decoding the JWT from the Authorization header reveals: the aud (audience) claim is set to "api.thirdparty.com" but the developer's API validates tokens where audience must be "api.myapp.com". The payload also shows exp is a Unix timestamp 3 hours in the past — the token is expired and no refresh token was provided. Both issues are invisible without decoding the JWT. The developer fixes by implementing token refresh before expiry and configuring the correct audience in the OAuth provider's settings. The entire debugging session took 5 minutes using the JWT decoder versus hours of server-side log analysis.

Best Practices

Never paste production tokens containing sensitive data: Even though this decoder is client-side, avoid pasting tokens from production that contain PII (names, emails, SSNs) or sensitive permissions — use test/staging environment tokens for debugging.
Verify expiry before debugging auth errors: Always check the exp claim first — most auth failures are simply expired tokens, saving time before investigating more complex issues.
Understand that decoding ≠ verification: Decoding shows the payload contents but does NOT verify the signature — any claim can be in a decoded JWT regardless of whether the token is valid or forged. Only server-side validation with the secret key verifies authenticity.
Check the algorithm field: The alg header should never be "none" in production tokens — this indicates a misconfigured auth server vulnerable to algorithm confusion attacks.
Validate standard claim formats: The exp and iat claims are Unix timestamps (seconds since epoch, not milliseconds) — if they look like a 13-digit number, the issuer is using milliseconds incorrectly.

Performance & Limits

Token size: Supports JWTs up to 100KB — handles even large tokens with extensive claims or embedded certificates.
Algorithms displayed: Shows the algorithm field from the header (HS256, RS256, ES256, PS256, etc.) — does not perform signature verification.
Timestamp conversion: Automatically converts Unix epoch timestamps (exp, iat, nbf) to human-readable date/time — includes relative time ("expires in 2 hours" or "expired 3 hours ago").
Nested JWTs: Detects and decodes JWE (encrypted JWTs) structure — payload decryption is not supported without the decryption key.
Malformed token detection: Identifies and reports common JWT format errors — missing segments, invalid Base64URL encoding, or incorrect padding.

Common Mistakes to Avoid

Confusing decoding with validation: A JWT decoder shows the payload — it does NOT verify that the token is authentic, unexpired, or from a trusted issuer. Always implement server-side JWT validation; never trust client-side decoded claims for authorization decisions.
Sharing production tokens in bug reports: Never include actual JWT tokens in GitHub issues, Slack messages, or support tickets — they grant access equivalent to the user's session and can be exploited until they expire.
Using algorithm "none" in any environment: The alg: "none" value means no signature verification — never accept unsigned tokens in any environment, even testing, as it trains developers to skip critical security checks.
Storing sensitive data in JWT payload: JWT payloads are only Base64URL encoded, not encrypted — any party who intercepts the token can decode and read all claims. Never store passwords, PII, or sensitive business data in JWT payloads.

Privacy & Security

100% client-side processing: JWT tokens are decoded entirely in your browser using JavaScript — the token text never leaves your device or reaches any server.
No token storage: Pasted tokens are not logged, stored, or associated with any session — they exist only in browser memory while you're on the page.
No account required: Decode tokens without registration or any personal information.
Session-only: Token data clears immediately when you navigate away or close the tab — no persistence between sessions.

Frequently Asked Questions

What is a JWT token and what does it contain?

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information as a JSON object. A JWT has three parts separated by dots: the header (Base64URL-encoded JSON with algorithm and token type), the payload (Base64URL-encoded JSON with claims about the user and session), and the signature (cryptographic hash of header + payload using the server's secret key). Common payload claims include: sub (subject/user identifier), iat (issued at timestamp), exp (expiration timestamp), aud (intended audience), iss (issuer), and custom application claims like roles, permissions, or user attributes. The payload is readable by anyone — it's encoded, not encrypted.

Is it safe to paste my JWT token into an online decoder?

It depends on the decoder. This decoder processes tokens entirely in your browser with no server communication — verified by checking the Network tab in browser DevTools, which shows no outbound requests when you decode. For production tokens containing sensitive user data, even client-side tools carry risk if the tool's JavaScript is compromised via supply chain attack. Best practices: use this tool for development and staging tokens; for production debugging, use jwt.io with the network tab open to verify no server calls, or decode manually using browser console (atob(token.split('.')[1]) decodes the payload). Never decode tokens containing passwords, SSNs, or financial account data in any online tool.

What does the JWT exp claim mean and why does it matter?

The exp (expiration) claim is a Unix timestamp (seconds since January 1, 1970) indicating when the token becomes invalid. Your server should reject any request with a token where the current time exceeds the exp value. Short-lived tokens (15 minutes to 1 hour) limit the damage window if a token is stolen — an attacker has only until expiry to misuse it. Refresh tokens (longer-lived, typically 7-30 days) are used to obtain new access tokens without re-authentication. Common debugging issue: if exp has 13 digits instead of 10, the issuer used milliseconds — divide by 1000 to get the correct Unix timestamp. The decoder automatically converts exp to human-readable date and shows "expired X minutes ago" or "expires in X hours."

What is the difference between HS256 and RS256 JWT algorithms?

HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification — fast and simple, but requires that both the issuer and verifier share the same secret securely. Suitable for single-server architectures where the same application signs and verifies tokens. RS256 (RSA-SHA256) uses a private key to sign and a public key to verify — the public key can be distributed freely without compromising security. Suitable for microservices and distributed systems where multiple services need to verify tokens issued by a central auth server. ES256 (ECDSA with P-256) provides similar public/private key separation as RS256 but with shorter key sizes and faster computation. Always prefer RS256 or ES256 over HS256 in distributed architectures to avoid sharing secrets across services.