JWT Decoder

Decode, validate and inspect JSON Web Tokens instantly. No data leaves your browser.

HEADER
.
PAYLOAD
.
SIGNATURE
Example JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Token Validation Results
Header
Payload
Signature
Claim Value Description

Security & Privacy

  • All processing happens locally in your browser
  • No data is sent to any server
  • Your JWT token never leaves your computer
  • This tool only decodes - it cannot verify signatures

JWT Decoder - Complete JSON Web Token Analysis Tool

Our JWT Decoder Tool allows you to instantly decode and analyze JSON Web Tokens. View the header, payload, and signature sections, validate standard claims, and understand JWT structure - all with complete privacy in your browser.

What is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. JWTs are commonly used for authentication and authorization in web applications. They consist of three parts separated by dots:

  1. Header - Contains token type and signing algorithm
  2. Payload - Contains the claims (user data, permissions, etc.)
  3. Signature - Used to verify the token hasn't been tampered with

Standard JWT Claims

Registered Claims

These are predefined claims recommended by the JWT specification:
iss (Issuer): Who issued the token
sub (Subject): Who the token is about
aud (Audience): Who the token is intended for
exp (Expiration Time): When the token expires
nbf (Not Before): When the token becomes valid
iat (Issued At): When the token was issued
jti (JWT ID): Unique identifier for the token

Public Claims

Claims that are defined in the IANA JSON Web Token Registry or use collision-resistant names. These are agreed upon by parties using the JWT.

Private Claims

Custom claims created to share information between parties that agree on using them. These are neither registered nor public claims.

Signature Algorithms

Common JWT signing algorithms include:
HS256: HMAC with SHA-256 (symmetric)
RS256: RSA with SHA-256 (asymmetric)
ES256: ECDSA with SHA-256 (asymmetric)
none: No signature (unsecured JWT)

Common JWT Use Cases

  1. Authentication - After login, server sends JWT that client sends with each request
  2. Authorization - Tokens contain user roles and permissions
  3. Information Exchange - Securely transmit information between parties
  4. Single Sign-On (SSO) - One login across multiple applications
  5. API Security - Protect API endpoints with token-based authentication
  6. Mobile Applications - Stateless authentication for mobile apps

Security Considerations

When working with JWTs, keep these security best practices in mind:

Frequently Asked Questions

Can this tool verify JWT signatures?

No, this tool only decodes JWT tokens and displays their contents. Signature verification requires the secret key or public key, which should never be shared with third-party tools for security reasons.

Is it safe to paste my JWT token here?

Yes! All processing happens locally in your browser. No data is sent to any server. However, be cautious as JWT contents are visible to anyone who can access them, so never share tokens containing sensitive information.

What's the difference between decoding and validating?

Decoding extracts and displays the token contents. Validating checks if the token is properly formed and its claims (like expiration) are valid. This tool does both but cannot verify cryptographic signatures.

Why does my JWT have 2 or 3 parts?

A JWT always has 3 parts (header.payload.signature). If you see 2 parts, it might be a JWS (JSON Web Signature) or an unsecured JWT (with "alg": "none" in header). If you see more than 3 parts, it might be a JWE (JSON Web Encryption) or nested JWT.

What does "Bearer" mean in Authorization headers?

"Bearer" is a type of token defined in RFC 6750. When you see "Authorization: Bearer <token>", it means the following token is a bearer token - anyone who possesses it can use it. This is why secure storage and transmission are crucial.

How long should JWT tokens be valid?

It depends on your use case. Access tokens are typically short-lived (15 minutes to 1 hour). Refresh tokens can be longer-lived (days to months). The shorter the token lifetime, the better for security, but balance with user experience.