GO KALI FREE

Development Tools

JWT Decoder

Decode and inspect JSON Web Tokens (JWTs) with header/payload decoding, pretty-printed JSON output, and expiration timestamp analysis.

What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for transmitting claims between parties. JWTs consist of three Base64url-encoded parts separated by dots: the header (algorithm and token type), the payload (claims and data), and the signature (integrity verification). Unlike session cookies, JWTs are self-contained, carrying all necessary information within the token itself, which makes them popular for stateless authentication in APIs and single-page applications.

For security professionals, JWTs are both a useful tool and a common attack surface. The header and payload are Base64url-encoded, not encrypted, meaning anyone with the token can read its contents. The signature prevents tampering but does not provide confidentiality. Understanding this structure is essential for identifying vulnerabilities like algorithm confusion, weak signing keys, and insecure claim handling.

This decoder parses JWTs locally in your browser, showing the header, payload, and signature in readable JSON format. It identifies the signing algorithm, checks expiration status, and highlights security-relevant claims so you can quickly assess token validity and identify potential issues.

JWT Security Vulnerabilities

The most critical JWT vulnerability is algorithm confusion. When a server accepts the algorithm specified in the token header without validation, an attacker can change the algorithm from RS256 (asymmetric) to HS256 (symmetric) and sign the token with the public key, which is often publicly available. This allows token forgery. Always validate that the algorithm matches what the server expects.

Weak signing keys are another common vulnerability. If a JWT is signed with a short or predictable secret, attackers can brute-force it offline. A 256-bit random secret is recommended for HS256. For production systems, use asymmetric algorithms (RS256 or ES256) with properly managed key pairs, as the private key never needs to be shared with resource servers.

Other vulnerabilities include accepting expired tokens, not validating the issuer and audience claims, storing sensitive data in the payload (which is readable by anyone), and failing to implement token revocation for logout and compromised token scenarios.

Interpreting JWT Claims

JWT claims are predefined fields in the payload that provide standardized information. The most common are iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Understanding these claims helps you verify token validity, check authorization scope, and identify misconfigurations.

The exp claim is critical for security. Tokens without expiration remain valid indefinitely, which is dangerous if they are compromised. Best practice is to set short expiration times (15-60 minutes) for access tokens and use refresh tokens for renewal. This decoder highlights expired tokens and flags missing or unusual claim values.

Custom claims can carry any data, but storing sensitive information like passwords, credit card numbers, or private keys in a JWT payload is a serious vulnerability because the payload is Base64url-encoded, not encrypted. Anyone who intercepts the token can decode and read the payload. Use JWTs for authentication claims, not for data confidentiality.

How to decode a JWT

  1. 1
    Paste the JWT
    Enter a complete JWT (three Base64url-encoded parts separated by dots) into the decoder.
  2. 2
    Review the header
    Check the algorithm (alg) and token type (typ) fields. Note the signing algorithm used.
  3. 3
    Inspect the payload
    Review standard claims like iss, sub, aud, exp, and iat, plus any custom claims in the payload.
  4. 4
    Check expiration
    The decoder shows whether the token is expired, valid, or not yet valid based on the exp and nbf claims.
  5. 5
    Analyze the signature
    The signature section shows the signing algorithm and whether the token's integrity can be verified.

Frequently Asked Questions

What is a JWT used for?

JWTs are used for stateless authentication in APIs and web applications. They carry claims (user identity, permissions, expiration) in a self-contained token that servers can verify without looking up session state.

Is a JWT encrypted?

No. JWTs are Base64url-encoded, not encrypted. Anyone with the token can decode and read the header and payload. Only the signature prevents tampering. For confidentiality, use JWE (JSON Web Encryption).

What is algorithm confusion?

Algorithm confusion occurs when a server accepts the algorithm specified in the token header without validation. An attacker can change the algorithm to forge tokens. Always validate that the algorithm matches what the server expects.

How long should a JWT be valid?

Access tokens should have short expiration times (15-60 minutes). Use refresh tokens for renewal. Tokens without expiration remain valid forever if compromised.

Can I use this decoder for debugging?

Yes. Paste a JWT into the decoder to see its header, payload, and signature details. This is useful for debugging authentication flows and inspecting tokens during API testing.

What does the exp claim mean?

The exp (expiration) claim is a Unix timestamp indicating when the token expires. After this time, the token should be rejected by the server. Tokens without an exp claim never expire.

Should I store sensitive data in a JWT?

No. JWT payloads are Base64url-encoded, not encrypted. Anyone who obtains the token can read the payload. Store only non-sensitive authentication claims in JWTs.

What is the difference between JWE and JWS?

JWS (JSON Web Signature) provides integrity and authenticity but not confidentiality; the payload is readable. JWE (JSON Web Encryption) encrypts the payload so only the intended recipient can read it. Use JWE when the JWT carries sensitive data.

How do I secure JWT signing keys?

Store signing keys in a secrets manager, rotate them regularly, use asymmetric algorithms (RS256 or ES256) so the private key stays server-side, and never embed keys in client-side code. Monitor for key exposure in logs and repositories.

Can a JWT be revoked?

Standard JWTs are stateless and valid until expiry. To revoke tokens, implement a server-side blocklist, use short expiry with refresh tokens, or store session state on the server. Token revocation is essential for logout and compromised credential scenarios.