JWT Decoder - Decode & Validate JSON Web Tokens

What is a JWT (JSON Web Token)?

JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information between parties as a JSON object. This information can be verified and trusted because it is digitally signed using a secret (HMAC algorithm) or a public/private key pair (RSA or ECDSA).

A JWT consists of three parts separated by dots (.): Header.Payload.Signature. The header typically contains the type of token (JWT) and the signing algorithm (HS256, RS256, etc.). The payload contains the claims—statements about an entity (typically the user) and additional metadata. The signature is used to verify that the sender of the JWT is who it says it is and to ensure the message wasn't changed along the way.

JWTs are commonly used for authentication and authorization in modern web applications, mobile apps, and microservices architectures. When a user logs in, the server generates a JWT and sends it to the client. The client stores it (typically in localStorage or a cookie) and includes it in the Authorization header for subsequent requests. The server can verify the token without querying a database, making JWTs stateless and highly scalable.

How to Decode a JWT Token

Decoding a JWT token reveals its header and payload contents, allowing you to inspect claims, expiration times, and other metadata. Here's how to decode JWTs:

• Identify the JWT: JWT tokens are Base64URL-encoded strings with three parts separated by dots. They typically start with "eyJ" and look like: eyJhbGci...eyJzdWI...SflKxw
• Paste the token: Copy the complete JWT token from your application, API response, or browser storage and paste it into the decoder above.
• Decode automatically: The decoder splits the token into header, payload, and signature parts, then Base64URL-decodes the header and payload to reveal the JSON content.
• Inspect claims: Review standard claims like iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and custom claims specific to your application.
• Check expiration: The tool automatically detects exp and nbf (not before) claims and shows whether the token is currently valid or expired.
• Verify structure: Ensure the token has the correct format and that all required claims are present for your use case.

This decoder performs all operations client-side in your browser using JavaScript. Your JWT tokens are never uploaded to any server, ensuring complete privacy and security for sensitive authentication tokens.

JWT Expiration Checker

JWT tokens commonly include an expiration claim (exp) that specifies when the token becomes invalid. This is a critical security feature that limits the window of opportunity for token misuse if a token is compromised. The expiration time is stored as a Unix timestamp (seconds since January 1, 1970 UTC).

Our JWT decoder automatically checks for the exp claim and compares it to the current time. If the token is expired, you'll see a clear indicator showing when it expired and how long ago. If the token is still valid, you'll see how much time remains until expiration. This helps you troubleshoot authentication failures caused by expired tokens—a common issue in development and production environments.

The tool also checks the nbf (not before) claim if present, which specifies when the token becomes valid. A token used before its nbf time should be rejected. Additionally, the iat (issued at) claim shows when the token was originally created, helping you understand token lifecycle and detect tokens that have been in use for unusually long periods.

Understanding JWT Claims

JWT claims are pieces of information asserted about a subject. Claims are name-value pairs encoded in the JWT payload. There are three types of claims:

• Registered claims: Predefined claims recommended by the JWT specification to provide interoperability:
  • iss (issuer): Identifies who issued the token
  • sub (subject): Identifies the subject (usually the user ID)
  • aud (audience): Identifies the recipients the token is intended for
  • exp (expiration): Time after which the token expires (Unix timestamp)
  • nbf (not before): Time before which the token is not valid
  • iat (issued at): Time when the token was issued
  • jti (JWT ID): Unique identifier for the token
• Public claims: Custom claims defined in the IANA JWT Registry or as collision-resistant names (usually using namespaced URIs).
• Private claims: Custom claims agreed upon between parties to share information. These can be any key-value pairs relevant to your application (e.g., user roles, permissions, email).

When decoding JWTs, always validate that expected claims are present and have acceptable values. Missing or incorrect claims can indicate token tampering or misconfiguration.

JWT Security Best Practices

While JWTs are powerful and convenient, improper use can create security vulnerabilities. Follow these best practices:

• Always verify signatures: Never trust JWT content without verifying the signature using the correct algorithm and secret/public key. This decoder shows you the content but doesn't verify signatures (which requires the secret key).
• Use strong signing algorithms: Prefer RS256 (RSA with SHA-256) or ES256 (ECDSA with SHA-256) over HS256 when possible. Avoid the "none" algorithm entirely.
• Keep secrets secure: Never expose signing keys in client-side code, public repositories, or configuration files.
• Set short expiration times: Use short-lived access tokens (15 minutes to 1 hour) and implement refresh token flows for longer sessions.
• Validate all claims: Check iss, aud, exp, and nbf claims on every request. Reject tokens with unexpected values.
• Don't store sensitive data: JWTs are encoded, not encrypted. Anyone can decode them. Never include passwords, credit card numbers, or other sensitive data in JWT payloads.
• Use HTTPS: Always transmit JWTs over HTTPS to prevent interception and man-in-the-middle attacks.
• Implement token revocation: While JWTs are stateless, maintain a blacklist for revoked tokens or use short expiration times with refresh tokens.

Common JWT Use Cases

JWTs are versatile and widely adopted across modern web development:

• Authentication: After login, the server issues a JWT that the client includes in subsequent requests. The server validates the token instead of querying a session store.
• API Authorization: APIs use JWTs to verify that requests come from authorized clients and to identify the user making the request.
• Single Sign-On (SSO): JWTs enable SSO across multiple domains by sharing authentication state without shared session storage.
• Information Exchange: JWTs securely transmit data between services in microservices architectures, with signatures ensuring data integrity.
• OAuth 2.0 & OpenID Connect: These protocols use JWTs for access tokens and ID tokens, enabling federated identity management.