JWT Debugger

Decode and inspect JWT tokens

What is JWT Debugger?

JSON Web Tokens (JWT, defined in RFC 7519) are a compact, URL-safe way to transmit claims between two parties. A JWT encodes a JSON payload — typically user identity, roles, and expiration — into three Base64URL-separated segments: header, payload, and signature. The header declares the token type and signing algorithm. The payload carries the actual data claims. The signature allows the recipient to verify that the token has not been tampered with, provided they possess the signing secret or public key. JWTs are the dominant mechanism for stateless authentication in modern web and mobile applications.

How to Use

  1. Paste a JWT token into the input field — it should have two dots separating three segments.
  2. Click Decode to parse the token into its header, payload, and signature components.
  3. Inspect the decoded header to confirm the algorithm (alg) and token type (typ).
  4. Review the payload claims — look for sub, iat, exp, and any custom fields.
  5. Check the Token Timing section to see whether the token is expired, expiring soon, or still valid.
  6. Use Load Sample to examine a pre-built token with realistic claims.

Why Use This Tool?

Instantly decode JWT contents without manual Base64URL string splitting and decoding
Spot malformed or incorrectly structured tokens before they cause server-side errors
Debug authentication failures by inspecting claims like sub, role, and exp
Visual token timing shows expiration status at a glance with color-coded indicators
Learn JWT structure interactively by decoding sample tokens
All decoding happens in your browser — tokens containing sensitive data never leave your device

Tips & Best Practices

  • A JWT has three dot-separated parts: header.payload.signature — if you see fewer or more dots, the token is malformed
  • The header usually contains alg (algorithm) and typ (token type, normally JWT) — some tokens also include kid for key rotation
  • Standard registered claims include sub (subject), iat (issued at), exp (expiration), nbf (not before), iss (issuer), aud (audience), and jti (unique ID)
  • JWTs are encoded but not encrypted — anyone who intercepts the token can read the header and payload
  • The signature can only be verified with the secret key or public key used during signing — this tool decodes but does not verify signatures

Frequently Asked Questions

What information does a JWT header contain?

The JWT header (also called the JOSE header) typically contains two fields: alg specifying the signing algorithm (such as HS256 for HMAC-SHA256 or RS256 for RSA-PSS), and typ indicating the token type (usually JWT). Additional fields may include kid (key ID) for selecting among multiple signing keys during rotation.

What are the most common JWT payload claims?

Registered claims include iss (issuer), sub (subject or user ID), aud (intended audience), exp (expiration timestamp), nbf (not-valid-before timestamp), iat (issued-at timestamp), and jti (unique token identifier). Applications also add private claims like role, permissions, email, or organization ID.

Why can the signature not be decoded?

The signature is a cryptographic MAC or digital signature computed over the header and payload using a secret key. Unlike Base64 encoding (which is reversible), cryptographic signatures cannot be reversed without the key. This design ensures that only the party holding the secret can produce a valid signature, proving token authenticity.

When should I NOT use JWTs?

Avoid JWTs when you need immediate token revocation (JWTs are stateless and cannot be invalidated before expiry without a revocation list), when storing large amounts of data (tokens grow with payload size and are sent on every request), or when you need payload confidentiality (use JWE instead). For server-side session management with instant logout, traditional session cookies are often simpler and more appropriate.

Is my token data kept private when using this tool?

Yes. All JWT decoding is performed entirely in your browser using client-side JavaScript. Your token is never sent to any server, API, or external service. You can safely inspect tokens containing sensitive authentication data without any risk of exposure.

How do I check if a JWT is expired?

Look for the exp (expiration) claim in the payload. It is a Unix timestamp in seconds. Compare it to the current time — if the current time exceeds the exp value, the token has expired. The Token Timing section in this tool automatically calculates and color-codes the expiration status for you.

Real-world Examples

Debugging a Failed API Authentication Request

Your frontend receives a 401 error from an API. Decode the JWT to check whether the exp claim has passed or the sub claim contains the wrong user ID.

Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwicm9sZSI6InZpZXdlciIsImlhdCI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MTUzNjAwfQ.abc123signature
Output
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","role":"viewer","iat":1704067200,"exp":1704153600}
Token expired — exp is in the past

Verifying Claims Before Granting Access

Before allowing a user to perform an admin action, decode their token to confirm the role claim and ensure the token was issued by your auth service (iss claim).

Input
Token with role: admin, iss: auth.myapp.com
Output
Payload shows role: "admin" and iss: "auth.myapp.com" — claims match expected values, proceed with authorization check

Related Tools