JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload, and expiration. 100% client-side.

Warning: This tool decodes JWTs but does NOT validate signatures. Never trust a JWT without server-side signature verification.
JWT Token
Header
Payload
Signature
Paste a JWT token above to decode it.

How to Use the JWT Decoder

  1. Paste your JWT token into the input area above. The token should have three parts separated by dots.
  2. View the decoded header and payload — the header shows the algorithm and token type, the payload shows all claims and data.
  3. Check expiration — if the token contains exp, iat, or nbf claims, the Time Claims section shows human-readable dates and whether the token is expired.
  4. Switch to Raw Parts mode to see the original Base64url-encoded parts of each section.

Understanding JSON Web Tokens

JSON Web Tokens (JWTs, pronounced "jots") are an open standard (RFC 7519) for securely transmitting information between parties as a compact, self-contained JSON object. JWTs are widely used in modern web applications for authentication, authorization, and information exchange. When a user logs in, the server creates a JWT containing the user's identity and permissions, signs it with a secret key, and returns it to the client. The client includes this token in subsequent requests, and the server verifies the signature to authenticate the request.

JWT Structure

A JWT consists of three parts separated by dots (.):

  • Header — contains the token type ("typ": "JWT") and the signing algorithm ("alg": "HS256", "RS256", etc.)
  • Payload — contains the claims, which are statements about the user and additional metadata. Standard claims include sub (subject), iss (issuer), exp (expiration), iat (issued at), and aud (audience)
  • Signature — created by signing the encoded header and payload with the secret or private key using the specified algorithm

Common JWT Claims

  • sub (subject) — identifies the principal that is the subject of the JWT, typically a user ID
  • iss (issuer) — identifies who issued the JWT
  • aud (audience) — identifies the recipients the JWT is intended for
  • exp (expiration time) — Unix timestamp after which the token must not be accepted
  • iat (issued at) — Unix timestamp when the token was created
  • nbf (not before) — Unix timestamp before which the token must not be accepted
  • jti (JWT ID) — unique identifier for the token, useful for preventing token replay

Security Considerations

While JWTs are convenient, they come with security considerations. Never store sensitive information in the payload, as it is only Base64-encoded and not encrypted — use our Base64 Encoder to inspect the raw encoding. Always verify the signature on the server side before trusting a token's claims. Use short expiration times and refresh tokens to limit the window of compromise if a token is stolen. Consider using the HttpOnly and Secure cookie flags when storing JWTs in cookies to prevent XSS attacks.

JWT vs. Session Tokens

Traditional session-based authentication stores session data on the server and sends only a session ID to the client. JWTs are self-contained: all necessary information is encoded in the token itself, eliminating the need for server-side session storage. This makes JWTs ideal for stateless APIs, microservice architectures, and cross-domain authentication. However, JWTs cannot be easily revoked before expiration without maintaining a server-side blacklist, which is a trade-off to consider. To format the decoded JSON payload, paste it into our JSON Formatter, or convert exp and iat timestamps with the Timestamp Converter.

Frequently Asked Questions

A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties as a JSON object. JWTs consist of three Base64url-encoded parts separated by dots: a header (algorithm and type), a payload (claims and data), and a signature (for verification). JWTs are widely used for authentication and authorization in web applications.
No. This tool only decodes and displays the contents of a JWT. It does NOT validate the signature. Anyone can create a JWT with any payload, so you should never trust a JWT's contents without verifying its signature on your server using the appropriate secret or public key.
No. This JWT decoder runs 100% in your browser using JavaScript. Your token never leaves your machine. There is no server-side processing, no logging, and no data collection. However, be cautious about pasting production tokens — treat JWTs like passwords.
JWT claims are statements about the token subject. The exp (expiration) claim is a Unix timestamp after which the token should be rejected. The iat (issued at) claim records when the token was created. The nbf (not before) claim specifies the earliest time the token should be accepted. These time-based claims help ensure tokens are only valid during their intended window.
A JWT consists of three Base64url-encoded parts separated by dots: the header (specifies the algorithm and token type), the payload (contains the claims and data), and the signature (created by signing the header and payload with a secret or private key). The format is: header.payload.signature.