JWT Decoder

Token analysis & validation tool • 2026 dev

JWT Structure:

Show the decoder

Header.Payload.Signature

Components:

  • Header: Algorithm and token type
  • Payload: Claims (iss, sub, exp, etc.)
  • Signature: Verification hash

Encoding: Base64Url encoded JSON objects

Example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoding reveals the JSON claims contained in the token.

JWT Token

Advanced Options

JWT Results

Valid Token
-
Expired
-
Algorithm
-
Execution Time
0ms

Header

Decoded

Payload

Decoded

Signature

Verified

Interpretation
Enter a JWT token to see analysis results.

Header

Payload

Claims

Claim Value Type

Comprehensive JWT Guide

What is JWT?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

JWT Structure

Three Parts Separated by Dots:

  • Header - Contains token type and signing algorithm
  • Payload - Contains claims (user identity, permissions)
  • Signature - Verifies token integrity

Example Claims:

  • iss - Issuer
  • sub - Subject
  • aud - Audience
  • exp - Expiration time
  • nbf - Not before
  • iat - Issued at
Common Use Cases
1
Authentication: User login tokens
2
Authorization: API access control
3
Information Exchange: Secure data transmission
Security Considerations

Important security practices:

  • Never store sensitive data: JWTs are not encrypted
  • Validate expiration: Always check exp claim
  • Secure signing keys: Store secrets safely
  • Set appropriate TTL: Short-lived tokens for security
  • Verify audience: Check aud claim matches expected value
Best Practices
  • Use HTTPS: Always transmit over secure connections
  • Keep payloads small: Reduce network overhead
  • Implement refresh tokens: For long-lived sessions
  • Validate all claims: Don't trust without verification
  • Monitor token usage: Track and audit access

JWT Fundamentals

What is JWT?

Compact token for secure data transmission.

Structure

Header.Payload.Signature

Base64Url encoded JSON objects.

Key Rules:
  • Always verify signatures
  • Check expiration times
  • Never store sensitive data

JWT Applications

When to Use JWT

For stateless authentication.

Common Uses
  1. User authentication
  2. API authorization
  3. Data exchange
  4. Session management
Considerations:
  • Token size impacts performance
  • Revocation is challenging
  • Security depends on implementation
  • Validate all claims

JWT Learning Quiz

Question 1: Multiple Choice - Understanding JWT Purpose

What is the primary purpose of JWT?

Solution:

The answer is C) To securely transmit information as JSON object. JWT is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JWS structure or JWE.

Pedagogical Explanation:

JWT stands for JSON Web Token and it's a standard for creating tokens that assert some number of claims. The tokens are signed using a cryptographic algorithm to ensure they haven't been tampered with. JWTs are commonly used for authentication and authorization in web applications.

Key Definitions:

JWT: JSON Web Token - compact token format

Claims: Statements about an entity (typically user)

JSON: JavaScript Object Notation

Important Rules:

• JWTs are compact

• Self-contained

• Digitally signed

Tips & Tricks:

• Use for stateless auth

• Verify signatures always

• Check expiration

Common Mistakes:

• Confusing JWT with encryption

• Not verifying signatures

• Ignoring expiration checks

Question 2: JWT Structure Application

What are the three parts of a JWT separated by dots?

Solution:

A JWT consists of three parts separated by dots:

  1. Header: Contains metadata about the token such as the signing algorithm
  2. Payload: Contains the claims (information about the user or application)
  3. Signature: Used to verify that the sender of the JWT is who it says it is

Structure: Header.Payload.Signature

Pedagogical Explanation:

Each part of the JWT is Base64Url encoded. The header and payload are JSON objects that are encoded, while the signature is created by combining the encoded header and payload with a secret and applying the specified algorithm. This structure allows for both verification of integrity and inspection of contents.

Key Definitions:

Header: Metadata about token (alg, typ)

Payload: Claims (user data, permissions)

Signature: Verification mechanism

Important Rules:

• Always 3 parts

• Separated by dots

• Base64Url encoded

Tips & Tricks:

• Header contains alg and typ

• Payload contains claims

• Signature verifies integrity

Common Mistakes:

• Forgetting the 3-part structure

• Confusing order of parts

• Not understanding Base64Url encoding

Question 3: Word Problem - JWT Claims

Which of the following are registered claims in JWT? Select all that apply: iss, sub, aud, exp, nbf, iat, jti, custom_claim

Solution:

The registered claims in JWT are:

  • iss (Issuer) - Identifies principal that issued the JWT
  • sub (Subject) - Identifies subject of the JWT
  • aud (Audience) - Identifies recipients that the JWT is intended for
  • exp (Expiration Time) - Defines time after which the JWT expires
  • nbf (Not Before) - Defines time before which the JWT must not be accepted
  • iat (Issued At) - Time at which the JWT was issued
  • jti (JWT ID) - Unique identifier for the JWT

custom_claim is not a registered claim - it's a public or private claim defined by the application.

Pedagogical Explanation:

Registered claims are predefined claim names that are commonly used and understood by the JWT ecosystem. They are not mandatory but have agreed-upon meanings. Public claims are defined by the application, and private claims are agreed upon between parties without collision risk.

Key Definitions:

Registered Claims: Predefined claim names (iss, sub, aud, etc.)

Public Claims: Application-defined claims

Private Claims: Agreed-upon custom claims

Important Rules:

• Registered claims have standard meanings

• Use registered claims when possible

• Avoid collisions with registered names

Tips & Tricks:

• Remember: ISS, SUB, AUD, EXP, NBF, IAT, JTI

• Always check exp and iat

• Verify aud matches expected value

Common Mistakes:

• Not understanding claim types

• Forgetting to validate required claims

• Using reserved names for custom claims

Question 4: Application-Based Problem - Security Implications

A developer stores sensitive user information (like social security number) in a JWT payload. What security issue does this create and why?

Solution:

Storing sensitive information in a JWT payload creates a security vulnerability because:

  • JWT payloads are Base64Url encoded, not encrypted
  • Anyone with the JWT can decode the payload and view the sensitive information
  • The token might be stored in logs, browser storage, or other insecure locations
  • Even with signature verification, the data is still exposed in plaintext

The correct approach is to store only non-sensitive information in JWTs, such as user ID, roles, and permissions. Sensitive data should be stored server-side and referenced by the token if needed.

Pedagogical Explanation:

This is a common misconception about JWT security. The signature only ensures integrity and authenticity, but does not provide confidentiality. The payload is always readable by anyone who has the token, regardless of whether it's signed or not.

Key Definitions:

Integrity: Ensuring data hasn't been tampered with

Confidentiality: Ensuring data is not readable by unauthorized parties

Authentication: Verifying identity of token issuer

Important Rules:

• JWTs provide integrity, not confidentiality

• Never store sensitive data in payloads

• Use for identification, not sensitive data

Tips & Tricks:

• Store user ID, not personal details

• Use server-side session storage for sensitive data

• Treat JWTs as publicly readable

Common Mistakes:

• Assuming JWTs are encrypted

• Storing sensitive data in payloads

• Not understanding the difference between integrity and confidentiality

Question 5: Multiple Choice - JWT Algorithms

Which algorithm is considered more secure for JWT signing?

Solution:

The answer is C) RS256 (RSA with SHA-256) or D) ES256 (ECDSA with SHA-256). Both RS256 and ES256 are asymmetric algorithms that provide better security for certain use cases. RS256 is widely used and well-supported. While HS256 is secure when implemented correctly, asymmetric algorithms provide advantages for distributed systems where the public key can be shared freely while keeping the private key secure.

Pedagogical Explanation:

HS256 is symmetric (same key for signing and verification), while RS256 and ES256 are asymmetric (different keys for signing and verification). Asymmetric algorithms allow for better key management in distributed systems since the public key can be shared without compromising security.

Key Definitions:

Symmetric: Same key for signing and verification

Asymmetric: Different keys for signing and verification

RSA: Rivest-Shamir-Adleman cryptographic algorithm

Important Rules:

• Never use "none" algorithm in production

• Prefer asymmetric for distributed systems

• Always keep secrets secure

Tips & Tricks:

• Use RS256 for distributed systems

• HS256 for simpler applications

• Never expose private keys

Common Mistakes:

• Using "none" algorithm in production

• Hardcoding secrets in code

• Not rotating signing keys

JWT Decoder

FAQ

Q: Can JWTs be encrypted to protect the payload?

A: Yes, JWTs can be encrypted using JWE (JSON Web Encryption). A regular JWT (JWS - JSON Web Signature) is only signed, not encrypted. An encrypted JWT (JWE) would have five parts: protected_header.encrypted_key.iv.ciphertext.authentication_tag. However, JWEs are more complex to implement and are less commonly used than signed JWTs.

For most applications, if you need to protect sensitive data, it's better to store only non-sensitive information in the JWT and keep sensitive data server-side.

Q: How do I handle JWT token revocation since they are stateless?

A: JWT revocation is indeed challenging since tokens are self-contained. Common approaches include:

  • Short expiration times: Reduce window of opportunity for misuse
  • Refresh tokens: Maintain server-side refresh token blacklist
  • Token blacklisting: Store revoked token IDs in a database
  • Re-issuance: Issue new tokens regularly

The most effective approach is usually to use short-lived access tokens (15-30 minutes) with longer-lived refresh tokens that can be properly managed server-side.

About

Developer Team
This calculator was created
This calculator was created by our Developer Tools Team , may make errors. Consider checking important information. Updated: April 2026.