JWT Tools - Decode, Verify & Create JSON Web Tokens Online

JWT Token Input

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 information exchange in modern web applications and APIs.

A JWT consists of three parts separated by dots (.):

  1. Header: Contains metadata about the token, including the signing algorithm (alg) and token type (typ)
  2. Payload: Contains the claims - statements about an entity (typically the user) and additional data
  3. Signature: Ensures the token hasn’t been altered and verifies the sender’s identity

Example JWT structure:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The decoder tab allows you to analyze existing JWT tokens:

  1. Paste your token into the text area (or click “Load Sample JWT” for an example)
  2. Automatic decoding - The tool will automatically decode tokens with valid format
  3. View components - See the decoded header, payload, and signature
  4. Check expiration - Real-time countdown shows when the token expires
  5. Copy components - Click the copy button on any section to copy to clipboard

The creator tab helps you generate new JWT tokens for testing:

Beginner Mode (Recommended for learning):

  1. Optionally select a preset scenario (API user, service-to-service, etc.)
  2. Choose signing algorithm (HS256 or none)
  3. Fill in basic claims (subject, name, expiration time)
  4. Click “Generate JWT” to create your token
  5. Copy the token or send it directly to the decoder

Advanced Mode (Full control):

  • Access to all standard JWT claims (issuer, audience, issued-at)
  • Add custom claims as JSON
  • Full configurability for testing complex scenarios
Security Notice

Important: This tool runs entirely in your browser. While your tokens never leave your device, you should:

  • Never paste production tokens containing real secrets
  • Never use production secrets when creating test tokens
  • Use this tool only for testing, learning, and development
  • For production, always generate and sign tokens on your server

JWTs use registered claim names for common fields:

Claim Full Name Description Type
iss Issuer Who created/issued the token (usually auth server URL) String
sub Subject Who the token is about (user ID or identifier) String
aud Audience Who should accept this token (API or app identifier) String or Array
exp Expiration Time When the token expires (Unix timestamp) Number
nbf Not Before Token not valid before this time (Unix timestamp) Number
iat Issued At When the token was created (Unix timestamp) Number
jti JWT ID Unique identifier for the token String

JWTs are versatile and used across many authentication scenarios:

  • Authentication: After login, include the JWT in requests to access protected routes and resources
  • API Authorization: Secure REST APIs by validating JWT tokens in the Authorization: Bearer <token> header
  • Information Exchange: Securely transmit information between parties with signature verification
  • Single Sign-On (SSO): Enable authentication across multiple applications with a single token
  • Microservices: Service-to-service authentication in distributed systems
  • Mobile Apps: Stateless authentication without server-side sessions

This tool supports two signing algorithms:

  • Type: Symmetric signing
  • How it works: Uses a shared secret known by both issuer and verifier
  • When to use: Simple scenarios, service-to-service where both sides can securely share a secret
  • Security: Secret must be kept confidential by all parties
  • Type: Unsigned
  • How it works: No cryptographic signature is applied
  • When to use: Local debugging and learning only
  • Security: ⚠️ Never use in production - anyone can modify the token
Production Algorithms

For production systems, consider:

  • RS256 (RSA with SHA-256): Asymmetric signing with public/private key pairs
  • ES256 (ECDSA with P-256 and SHA-256): Elliptic curve signatures
  • PS256 (RSA PSS with SHA-256): RSA with probabilistic signature scheme

These algorithms require server-side implementation.

When working with JWTs in production:

DO:

  • Always use HTTPS to prevent token interception
  • Set appropriate expiration times - tokens should not live forever
  • Store tokens securely (avoid localStorage for highly sensitive data)
  • Use strong signing algorithms (HS256 minimum, RS256/ES256 recommended)
  • Validate tokens on every request server-side
  • Include aud (audience) and iss (issuer) claims for added security
  • Implement token rotation for long-lived sessions
  • Use short-lived access tokens with refresh tokens

DON’T:

  • Store sensitive data in the payload (it’s Base64-encoded, not encrypted)
  • Share signing secrets between unrelated applications
  • Trust tokens without signature verification
  • Use alg: none in production environments
  • Accept tokens without validating expiration (exp) claim
  • Expose tokens in URLs or logs
  • 🔍 Automatic header and payload decoding
  • ⏰ Real-time expiration countdown for valid tokens
  • ✓ Visual status indicators (Valid, Expired, No Expiration)
  • 📋 One-click copy for header, payload, and signature
  • 🔄 Auto-decode on paste/input
  • 📝 Detailed claims information with human-readable dates
  • ⚠️ Clear error messages for invalid tokens
  • ✨ Guided JWT creation wizard for beginners
  • 🎯 Use-case presets (API user, service-to-service, ID token, debug)
  • 🔐 HS256 cryptographic signing using Web Crypto API
  • 🧠 Human-friendly explanation of generated tokens
  • 🔁 One-click flow: create → send to decoder → analyze
  • 🎓 Beginner/Advanced mode toggle
  • 📝 Custom claims support with JSON validation
  • ⏱️ Flexible expiration time configuration
  • 🔐 100% client-side processing - your tokens and secrets never leave your browser
  • 🚫 No server communication - all operations happen locally
  • 🗑️ Nothing is stored or logged
  • 🌓 Dark/Light theme support
  • 📱 Fully responsive design for mobile and desktop

Yes. Our tool runs entirely in your browser using JavaScript. All decoding, analysis, and token creation happens client-side using the Web Crypto API for cryptographic operations. No tokens, secrets, or data are transmitted to any server, stored in databases, or logged. Your sensitive authentication data remains completely private.

Simply paste your JWT token into the decoder tab’s text area. The tool will automatically detect valid tokens (3 parts separated by dots) and decode them instantly, showing the header, payload, signature, and expiration status.

  1. Switch to the “JWT Token Creator” tab
  2. (Optional) Select a preset scenario or start from scratch
  3. Choose a signing algorithm (HS256 for testing, with a test secret)
  4. Fill in the claims (subject, name, expiration time)
  5. Click “Generate JWT” to create your token
  6. Copy the token or send it directly to the decoder

This tool directly supports:

  • HS256: HMAC with SHA-256 (symmetric signing with shared secret)
  • none: No signature (for local debugging only)

For production environments, you should use server-side libraries that support:

  • RS256, RS384, RS512 (RSA signatures)
  • ES256, ES384, ES512 (Elliptic Curve signatures)
  • PS256, PS384, PS512 (RSA PSS signatures)

No. This tool is designed for testing, learning, and development only. In production:

  • Always generate tokens on your server
  • Never use secrets entered into browser-based tools
  • Implement proper key management and rotation
  • Use established JWT libraries (jose, jsonwebtoken, etc.)

The decoder checks the exp (expiration) claim against the current time. If Date.now() is past the expiration timestamp, the token is marked as expired. This is a security feature - expired tokens should be rejected by your API.

Beginner Mode: Simplified interface showing only essential fields (subject, name, expiration). Perfect for learning JWT basics.

Advanced Mode: Full access to all standard claims (issuer, audience, issued-at, custom claims JSON). Use when you need precise control over token structure.

This tool decodes tokens and displays their contents, but signature verification requires the signing secret or public key. For security, you should never paste production secrets into browser tools. Signature verification should be done server-side.

Explore our other DevOps tools:


Need help? All code is open-source. Visit our GitHub or contact us with questions or feedback.