JWT Token Decoder

/ Developer Tools, Security Tools

JWT Token Decoder

Decode, verify, and debug JSON Web Tokens (JWT) with header, payload, and signature inspection. Essential for API development and authentication debugging.

Key Features

  • Instant Decoding – Parse JWT header and payload
  • Signature Verification – Validate with secret keys
  • Algorithm Support – HS256, RS256, ES256, and more
  • Claims Inspector – View all JWT claims
  • Expiration Check – Validate exp and nbf claims
  • Copy Components – Copy header/payload separately
  • Syntax Highlighting – Color-coded JSON display
  • Error Detection – Identify malformed tokens
  • Browser-Based – All processing done locally
  • No Data Storage – Tokens never leave your browser

Understanding JWT Structure

A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. Each part contains specific information about the token.

Header

Purpose: Token metadata
Contains: Algorithm (alg), token type (typ)

Example:

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

Purpose: Claims and data
Contains: User info, permissions, expiration

Example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

Signature

Purpose: Verification and integrity
Contains: Encrypted hash of header + payload

Formula:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Standard JWT Claims

Registered Claims

  • iss – Issuer (who created the token)
  • sub – Subject (user identifier)
  • aud – Audience (intended recipient)
  • exp – Expiration time (Unix timestamp)
  • nbf – Not before (Unix timestamp)
  • iat – Issued at (Unix timestamp)
  • jti – JWT ID (unique identifier)

Custom Claims

  • name – User’s full name
  • email – User’s email address
  • roles – User roles/permissions
  • scope – OAuth scopes
  • tenant – Multi-tenant identifier
  • custom_* – Application-specific data

Note: Custom claims should be kept minimal to reduce token size.

Common Signing Algorithms

HS256 (HMAC SHA-256)

Type: Symmetric (shared secret)
Security: Fast, simple
Key: Same secret for signing and verifying

Best for: Internal APIs, microservices, same-org communication

RS256 (RSA SHA-256)

Type: Asymmetric (public/private key)
Security: Very secure
Key: Private key signs, public key verifies

Best for: OAuth, OpenID Connect, third-party integrations, public APIs

ES256 (ECDSA SHA-256)

Type: Asymmetric (elliptic curve)
Security: Very secure, smaller keys
Key: Smaller keys than RSA

Best for: Mobile apps, IoT devices, performance-critical applications

JWT Security Best Practices

✅ Best Practices

  • Always verify signatures – Never trust unverified tokens
  • Set expiration times – Use short-lived tokens (15-60 min)
  • Use HTTPS only – Never send JWTs over HTTP
  • Store securely – Use httpOnly cookies or secure storage
  • Validate all claims – Check exp, nbf, aud, iss
  • Use strong secrets – 256+ bit keys for HS256

❌ Avoid These

  • Don’t use “none” algorithm – Security vulnerability
  • Don’t store sensitive data – JWTs are Base64, not encrypted
  • Don’t make tokens too long – Keep payload minimal
  • Don’t use weak secrets – Avoid dictionary words
  • Don’t skip algorithm validation – Prevent algorithm confusion
  • Don’t use localStorage – XSS vulnerable, use httpOnly cookies

Frequently Asked Questions

Are JWTs encrypted?

No, standard JWTs are Base64-encoded, not encrypted. Anyone can decode the header and payload to see the contents. The signature prevents tampering but doesn’t hide data. For encrypted tokens, use JWE (JSON Web Encryption) instead of JWT (JSON Web Token).

How long should a JWT be valid?

Access tokens: 15-60 minutes. Refresh tokens: days to weeks. Short-lived access tokens limit damage if compromised. Use refresh tokens to get new access tokens without requiring re-authentication. The exact duration depends on your security requirements.

Can I revoke a JWT before it expires?

Not directly – JWTs are stateless. Workarounds: maintain a blacklist/denylist of revoked tokens, use short expiration times with refresh tokens, include a version number in claims and invalidate old versions, or use Redis to store token state.

Where should I store JWTs in the browser?

Best: httpOnly cookies. Prevents JavaScript access, mitigating XSS attacks. Alternative: sessionStorage (cleared on tab close) or memory (Redux/Vuex state). Avoid: localStorage (XSS vulnerable, persists across sessions). For mobile apps, use secure storage (Keychain/KeyStore).

What’s the difference between JWT and session cookies?

JWT is stateless, sessions are stateful. JWT stores all data in the token (server doesn’t need to look up anything). Session cookies store only an ID, server looks up session data. JWTs scale better (no session store), but are larger and can’t be easily revoked.

Related Security Tools

🔗 Hash Generator

Generate cryptographic hashes using MD5, SHA-256, SHA-512, and other algorithms.

Generate Hash →

🔐 Password Generator

Generate cryptographically secure passwords with customizable length and character sets.

Generate Password →

🛠️ All Developer Tools

Explore our complete suite of free developer and security tools.

View All Tools →

Need Help with API Security?

Our security experts can help implement JWT authentication, OAuth flows, and comprehensive API security for your applications.

Contact Our Security Team