JWT Decoder

API security tool • 2026 standards

JWT Structure:

Decode Token

Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JSON Web Tokens (JWT) are compact, URL-safe tokens that enable secure information exchange between parties. They consist of three parts separated by dots: header, payload, and signature.

Best Practices:

  • Never store sensitive data in JWT payloads
  • Always verify signatures before trusting tokens
  • Implement proper expiration handling
  • Use strong signing algorithms
  • Validate all claims in the payload
  • Secure token storage on client side

Impact: Proper JWT handling improves API security, enables stateless authentication, and enhances user session management.

JWT Token Input

0 characters

Advanced Options

JWT Analysis

0
Parts
0
Characters
-
Algorithm
Ready
Status
Header
{"alg":"HS256","typ":"JWT"}
Payload
{"sub":"1234567890","name":"John Doe","iat":1516239022,"exp":1716239022}

Claims

Claim Value Type
Decode a token to see claims
Signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Token verification will appear here...

JWT Structure Fundamentals

JWT Components

JSON Web Tokens consist of three parts separated by dots: header, payload, and signature. Each part is Base64Url encoded.

Token Format

Header: Contains token type and signing algorithm

Payload: Contains claims (user data and metadata)

Signature: Verifies token integrity and authenticity

Structure: encodedHeader.encodedPayload.signature

Key Rules:
  • Header and payload are Base64Url encoded
  • Signature ensures token integrity
  • Never store sensitive data in payload
  • Always validate token expiration
  • Verify signatures before trusting tokens

Security Impact

JWT Security Benefits

Proper JWT handling improves API security, enables stateless authentication, enhances user session management, prevents CSRF attacks, and provides secure information exchange.

Common Claims
  1. sub: Subject (user identifier)
  2. exp: Expiration time
  3. iat: Issued at time
  4. nbf: Not before time
  5. iss: Issuer
  6. aud: Audience
Common Issues:
  • Token expiration not validated
  • Signatures not verified
  • Sensitive data in payload
  • Weak signing algorithms

JWT Security Learning Quiz

Question 1: Multiple Choice - JWT Structure

How many parts does a JWT token have?

Solution:

The answer is C) Three parts. A JWT token consists of three parts separated by dots: header, payload, and signature. Each part is Base64Url encoded.

Pedagogical Explanation:

JWTs follow the structure: encodedHeader.encodedPayload.signature. The header contains metadata about the token, the payload contains the claims (data), and the signature verifies the token's authenticity and integrity.

Key Definitions:

JWT: JSON Web Token

Header: Token metadata (algorithm, type)

Payload: Claims (user data and metadata)

Important Rules:

• Three parts separated by dots

• Header and payload are encoded

• Signature verifies integrity

• All parts are Base64Url encoded

Tips & Tricks:

• Remember: Header.Payload.Signature

• Use JWT libraries for production

• Always verify signatures

Common Mistakes:

• Thinking header and payload are encrypted

• Not verifying signatures

• Storing sensitive data in payload

Question 2: JWT Claims

Which claim represents the expiration time of a JWT token?

Solution:

The answer is A) exp. The "exp" (expiration time) claim identifies the time after which the JWT must not be accepted for processing. It's a Unix timestamp representing when the token expires.

Pedagogical Explanation:

Standard JWT claims (registered claims) have specific meanings. The "exp" claim is crucial for security as it prevents tokens from being used indefinitely. The value is a numeric date representing seconds since epoch.

Key Definitions:

exp: Expiration time claim

iat: Issued at time claim

nbf: Not before time claim

Important Rules:

• exp is mandatory for security

• Check expiration before accepting

• Value is Unix timestamp

• Always validate in production

Tips & Tricks:

• Always validate exp claim

• Use leeway for clock differences

• Refresh tokens before expiry

Common Mistakes:

• Not validating expiration

• Using expired tokens

• Not handling clock skew

Question 3: Word Problem - Security Vulnerability

You're reviewing a JWT implementation where the application stores sensitive user information like SSN and credit card numbers in the JWT payload. What security vulnerability does this represent?

Solution:

This represents a serious security vulnerability where sensitive data is stored in the JWT payload. The issue is:

  • JWT payloads are only encoded (not encrypted), so anyone with the token can read the data
  • Tokens may be stored in logs, browser storage, or network traces
  • The sensitive information is exposed to anyone who can access the token

Best practice: Never store sensitive information in JWT payloads. Only include non-sensitive data that can be safely exposed.

Pedagogical Explanation:

JWTs are often misunderstood as encrypted tokens, but the header and payload are only Base64Url encoded, not encrypted. This means anyone with the token can decode and read the payload contents.

Key Definitions:

Encoding: Transforming data format (reversible)

Encryption: Securing data with a key (requires key to decrypt)

JWT Payload: Contains claims (data) in the token

Important Rules:

• JWT payloads are encoded, not encrypted

• Never store sensitive data in payloads

• Treat JWTs as potentially readable

• Use server-side storage for sensitive data

Tips & Tricks:

• Store only public user ID

• Fetch sensitive data server-side

• Use JWE for encrypted payloads

Common Mistakes:

• Thinking JWTs are encrypted

• Storing sensitive data in payloads

• Not understanding encoding vs encryption

Question 4: Application-Based Problem - Signature Verification

A malicious user modifies the payload of a JWT token to change their role from "user" to "admin". What prevents this tampering from being successful?

Solution:

The signature prevents this tampering. The JWT signature is created by hashing the header and payload with a secret key. When the payload is modified:

  • The signature becomes invalid because it was computed with the original payload
  • Server verification will fail because the recomputed signature won't match the token's signature
  • The tampered token will be rejected

However, this only works if the server properly verifies the signature before trusting the token.

Pedagogical Explanation:

The signature is the security mechanism that ensures JWT integrity. It's computed as: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret). Any change to header or payload invalidates the signature.

Key Definitions:

Signature: Hash proving token integrity

Integrity: Data hasn't been altered

HMAC: Hash-based Message Authentication Code

Important Rules:

• Always verify signatures

• Never trust unsigned tokens

• Use strong secrets

• Rotate secrets periodically

Tips & Tricks:

• Use JWT libraries for verification

• Implement proper error handling

• Log signature failures

Common Mistakes:

• Not verifying signatures

• Using weak secrets

• Accepting "none" algorithm

Question 5: Multiple Choice - Algorithm Security

Which JWT algorithm is considered the most secure for production applications?

Solution:

The answer is B) RS256 (asymmetric). While all the listed algorithms (except "none") are secure, RS256 is generally preferred for production because it uses asymmetric cryptography. This allows the issuer to sign tokens with a private key while allowing verification with a public key, which is safer for distributed systems.

Pedagogical Explanation:

HS256 (HMAC) uses symmetric keys - both signing and verification require the same secret. RS256 (RSA) uses asymmetric keys - different keys for signing and verification. Asymmetric algorithms are preferred for distributed systems where you don't want to share secrets.

Key Definitions:

HS256: HMAC with SHA-256 (symmetric)

RS256: RSA with SHA-256 (asymmetric)

ES256: ECDSA with SHA-256 (asymmetric)

Important Rules:

• Never use "none" algorithm

• Use strong algorithms (HS256+, RS256+)

• Protect signing keys

• Consider key rotation

Tips & Tricks:

• Use RS256 for distributed systems

• HS256 for simpler setups

• ES256 for performance

Common Mistakes:

• Using "none" algorithm

• Weak secret keys

• Not rotating keys

jwt-decoder

FAQ

Q: What's the difference between JWT and JWS/JWE?

A: The differences are:

JWT (JSON Web Token): A compact, URL-safe means of representing claims to be transferred between two parties. It's a specification that can use JWS or JWE.

JWS (JSON Web Signature): Provides integrity protection for JSON content. JWTs are typically implemented using JWS for signed tokens.

JWE (JSON Web Encryption): Provides encryption for JSON content. Use JWE when you need confidentiality (encrypted payload).

Standard JWTs use JWS (signed), while encrypted JWTs use JWE. Most JWT implementations are JWS-based, meaning the payload is signed but not encrypted.

Q: How should I handle JWT expiration and refresh tokens?

A: Implement JWT expiration and refresh tokens as follows:

Access Token:

  • Short-lived (15-30 minutes)
  • Contains minimal user information
  • Used for API authentication
  • Expires frequently for security

Refresh Token:

  • Long-lived (days to weeks)
  • Stored securely (HttpOnly cookie or secure storage)
  • Used to obtain new access tokens
  • Should be revoked on logout

Best practices:

  • Check expiration before each API call
  • Implement automatic refresh before expiration
  • Use sliding expiration windows
  • Store refresh tokens securely server-side

This approach balances security (short-lived access tokens) with usability (refresh tokens).

About

Security Team
This JWT decoder was created
This calculator was created by our Web & Development Team , may make errors. Consider checking important information. Updated: April 2026.