JWT Decoder

Decode and inspect JWT (JSON Web Token) online instantly. View header, payload, and signature.

What is JWT?

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed using a secret (HMAC algorithm) or a public/private key pair (RSA or ECDSA). JWTs are widely used for authentication and information exchange in modern web applications, mobile apps, and APIs. First introduced in 2010 and standardized by the IETF in 2015, JWT has become the de facto standard for stateless authentication in distributed systems and microservices architectures.

History and Evolution of JWT

JSON Web Tokens emerged from the need for a compact, self-contained method of securely transmitting information in web applications. Before JWT, session-based authentication required server-side storage and lookup, limiting scalability. The JWT specification (RFC 7519) was published in May 2015, building on earlier standards like JSON Web Signature (JWS, RFC 7515) and JSON Web Encryption (JWE, RFC 7516). The standard was developed by the IETF JSON Web Token Working Group, led by Mike Jones from Microsoft, along with contributors from Google, Ping Identity, and others. JWT gained rapid adoption due to its simplicity, compactness, and ability to work seamlessly with RESTful APIs and Single Page Applications (SPAs). Today, JWT is supported by virtually every programming language and framework, with major platforms like Auth0, Firebase, AWS Cognito, and Okta using JWT as their primary token format.

JWT Structure and Components

A JWT consists of three parts separated by dots (.): Header.Payload.Signature. The Header contains metadata about the token, typically the type (JWT) and signing algorithm (HS256, RS256, ES256, etc.). The Payload contains the claims - statements about an entity (typically the user) and additional metadata like expiration time (exp), issuer (iss), audience (aud), and custom claims. The Signature ensures the token hasn't been tampered with and verifies the sender's identity. Each part is Base64URL-encoded (not encrypted), making the token URL-safe. Example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. JWTs are typically 200-500 bytes, much smaller than XML-based tokens like SAML.

Why Use JWT Decoder?

  • ✓Free unlimited JWT decoding
  • ✓Instant decode and inspection
  • ✓100% client-side, works offline
  • ✓No data sent to server, completely private
  • ✓Supports all JWT algorithms
  • ✓Validates JWT structure

Common JWT Claims

  • iss (Issuer): Identifies who issued the token
  • sub (Subject): Identifies the subject of the token (usually user ID)
  • aud (Audience): Identifies the intended recipient(s)
  • exp (Expiration): Token expiration timestamp (Unix time)
  • nbf (Not Before): Token not valid before this timestamp
  • iat (Issued At): When the token was issued
  • jti (JWT ID): Unique identifier for the token

JWT Signing Algorithms

HS256 (HMAC SHA-256)

Symmetric algorithm using a shared secret key. Fast and simple, ideal for internal APIs where both issuer and verifier share the same secret. Requires secure key distribution. Most commonly used algorithm, supported by all JWT libraries. Key size: 256 bits minimum.

RS256 (RSA SHA-256)

Asymmetric algorithm using RSA public/private key pair. The token is signed with a private key and verified with a public key. Ideal for scenarios where token issuers and verifiers are different parties (e.g., OAuth, OpenID Connect). Public key can be safely distributed. More CPU-intensive than HMAC. Key size: 2048 bits minimum (recommended 4096 bits).

ES256 (ECDSA SHA-256)

Asymmetric algorithm using Elliptic Curve cryptography. Provides same security as RSA with smaller key sizes and signatures, resulting in smaller tokens and better performance. Growing in popularity for mobile and IoT applications. Supported by modern JWT libraries. Key size: 256 bits provides equivalent security to RSA 3072 bits.

Common Use Cases

  • Authentication: Stateless user authentication in web and mobile apps
  • API Authorization: Secure API access with bearer tokens
  • Single Sign-On (SSO): Share authentication across multiple applications
  • OAuth 2.0: Standard token format for OAuth flows
  • Microservices: Pass user context between services
  • Mobile Apps: Persistent authentication without sessions

Security Best Practices

JWT security is critical for application safety. Always validate the signature to prevent token tampering. Use strong secrets (minimum 256 bits for HMAC) or proper key management for asymmetric algorithms. Always verify 'exp' (expiration) claim to prevent token replay attacks. Use short expiration times (15-60 minutes) for access tokens and refresh tokens for extended sessions. Never store sensitive data in JWT payload as it's Base64-encoded, not encrypted - anyone can decode it. Use HTTPS to prevent token interception during transmission. Implement token revocation for logout and security events, using blacklists or short-lived tokens. Validate 'aud' (audience) and 'iss' (issuer) claims to prevent token misuse. Consider using JWE (JSON Web Encryption) for sensitive payload data. Rotate signing keys regularly. Be aware of algorithm confusion attacks - always verify the algorithm matches expectations. This decoder tool runs entirely in your browser - tokens are never transmitted to any server.

JWT Performance and Efficiency

JWT offers excellent performance characteristics for modern applications. Token validation is extremely fast as it only requires signature verification using cryptographic algorithms, typically completing in microseconds. Unlike session-based authentication requiring database lookups, JWT validation is stateless and O(1) constant time. This makes JWT ideal for high-traffic applications and microservices. Token size ranges from 200-500 bytes for typical payloads, which is negligible for modern networks. However, large payloads can impact performance - keep claims minimal. HMAC algorithms (HS256) are faster than RSA (RS256), processing 10-100x more tokens per second on the same hardware. ECDSA (ES256) provides a good balance between security and performance. For optimal performance: use short-lived tokens, cache public keys for RSA/ECDSA validation, consider token compression for very large payloads, and implement token refresh strategies to minimize re-authentication overhead.

How to Use

  1. Paste your JWT token into the input field
  2. Click 'Decode JWT' button
  3. View decoded header and payload
  4. Inspect claims and verify token structure

Frequently Asked Questions

What's the difference between JWT and session-based authentication?

JWT is stateless - all user information is contained in the token itself, requiring no server-side session storage. Sessions require server memory/database to store session data, limiting horizontal scalability. JWT tokens can be verified by any service with the secret/public key, making them ideal for distributed systems and microservices. Sessions require sticky sessions or shared session storage in load-balanced environments. JWT enables true stateless REST APIs. However, sessions are easier to revoke immediately, while JWT requires additional mechanisms like token blacklisting. JWT is better for: APIs, microservices, mobile apps, cross-domain authentication. Sessions are better for: traditional web apps, scenarios requiring immediate logout, highly sensitive applications.

Is JWT secure? Can it be tampered with?

JWT is cryptographically secure when properly implemented. The signature ensures that any modification to the header or payload will invalidate the token. However, the payload is only Base64-encoded, not encrypted - anyone can decode and read it. Never store sensitive information like passwords or credit card numbers in JWT. Use HTTPS to prevent token interception. The security depends on: (1) Secret key strength - use minimum 256-bit random keys for HMAC, (2) Algorithm verification - always validate the algorithm to prevent 'none' algorithm attacks, (3) Expiration validation - always check 'exp' claim, (4) Signature verification - never skip signature validation. Common vulnerabilities: weak secrets, algorithm confusion attacks, missing expiration checks, storing tokens in localStorage (XSS vulnerability). Best practice: store in httpOnly cookies or memory for SPAs.

Why can I decode JWT without a secret key?

JWT payload is Base64URL-encoded, not encrypted. This is by design - encoding makes the token URL-safe and allows anyone to read the contents. The signature prevents tampering, not reading. Think of JWT like a sealed envelope: you can see the outside (header and payload), but can't modify the contents without breaking the seal (signature). This design allows: (1) Receivers to read claims before verification, (2) Debugging and troubleshooting, (3) Client-side decision making based on claims, (4) Faster processing as encryption/decryption isn't needed. If you need to hide the payload contents, use JWE (JSON Web Encryption) which encrypts the entire token. For most use cases, encoding is sufficient as the signature prevents malicious modifications.

What happens when JWT expires?

When a JWT's 'exp' (expiration) claim passes, the token becomes invalid and should be rejected by the server. The application should handle this by: (1) Returning 401 Unauthorized error, (2) Prompting the user to re-authenticate, or (3) Using a refresh token to obtain a new access token. Typical JWT architecture uses two tokens: short-lived access tokens (15-60 minutes) for API requests, and long-lived refresh tokens (days/weeks) for obtaining new access tokens. This balances security (short access token lifetime limits damage if compromised) with user experience (users don't re-login frequently). Implementation: Client receives both tokens → Uses access token for API calls → When access token expires, uses refresh token to get new access token → Repeats until refresh token expires or user logs out. Never extend JWT expiration on the client side - 'exp' is cryptographically signed.

Can I revoke or invalidate a JWT before it expires?

JWT tokens are stateless, so immediate revocation is challenging. However, several strategies exist: (1) Token Blacklist - maintain a list of revoked tokens (identified by 'jti' claim) in Redis or database, check before validating. Fast but requires storage. (2) Short expiration times - 5-15 minute tokens limit exposure window. Combine with refresh tokens. (3) Version claims - include user version number in token, increment on logout/password change, reject old versions. (4) Real-time validation - check user status in database on each request (defeats stateless benefits). (5) Event-driven invalidation - notify all services when user logs out. Best practice: Combine short-lived tokens (15-60 min) with refresh token rotation. When user logs out, blacklist refresh token and wait for access token to expire naturally. For critical security events (password change, suspicious activity), implement immediate blacklist checking.

Should I store JWT in localStorage or cookies?

Both have trade-offs. httpOnly cookies are more secure: not accessible to JavaScript (prevents XSS attacks), automatically included in requests, can use SameSite attribute for CSRF protection. However, cookies are vulnerable to CSRF attacks (mitigated with SameSite and CSRF tokens) and don't work well for cross-domain requests. localStorage is vulnerable to XSS attacks - any JavaScript can access it, making XSS attacks more dangerous. Benefits: works across domains, easier implementation for SPAs, full JavaScript control. Best practices: (1) For web apps: Use httpOnly, secure, SameSite cookies for maximum security, (2) For SPAs/mobile: Store in memory (state management) and use refresh tokens in httpOnly cookies, (3) Never use localStorage for sensitive tokens in production, (4) Implement Content Security Policy (CSP) to mitigate XSS, (5) For cross-domain: Use OAuth/OIDC flows with proper CORS configuration. Modern recommendation: httpOnly cookies for web apps, memory + secure refresh mechanism for SPAs.

What's the maximum size of a JWT token?

JWT has no strict size limit in the specification, but practical limits exist. Recommended maximum: 4KB-8KB to fit in HTTP headers. Browser URL limits: ~2KB (if passed in URL). Cookie limits: 4KB per cookie. HTTP header limits: typically 8KB-16KB depending on server. Larger tokens cause: (1) Performance degradation - larger network transfers, (2) Header size errors if too large, (3) Cookie rejection by browsers, (4) Slower parsing and validation. Typical JWT sizes: Minimal token (sub, exp, iat): ~200 bytes. Standard token with common claims: ~300-500 bytes. Token with custom claims: ~500-1000 bytes. Keep tokens small by: (1) Using claim abbreviations (avoid long claim names), (2) Not including large arrays or objects, (3) Referencing data by ID rather than embedding, (4) Using separate API calls for large data. If you need large payloads, store data server-side and include only a reference ID in the token.

What JWT signing algorithm should I use?

Choice depends on your use case: HS256 (HMAC SHA-256): Best for internal APIs where issuer and verifier are the same system or trusted parties sharing a secret. Pros: Fast, simple, well-supported. Cons: Requires secure secret distribution. Use when: microservices within same organization, simple applications, performance is critical. RS256 (RSA SHA-256): Best for distributed systems where token issuers and verifiers are different parties. Pros: Public key can be safely shared, widely supported in OAuth/OIDC. Cons: Slower than HMAC, requires key management. Use when: public APIs, OAuth 2.0, OpenID Connect, multi-tenant systems. ES256 (ECDSA SHA-256): Best for modern applications needing smaller tokens and better performance than RSA. Pros: Smaller signatures, faster than RSA, strong security. Cons: Less universally supported than RS256. Use when: mobile apps, IoT, performance-critical systems. Recommendation for 2025: ES256 for new projects, RS256 for OAuth/OIDC compatibility, HS256 for internal services. Avoid: 'none' (no signature), weak algorithms (HS1, RS1).

Related Tools

🔗

URL Encoder/Decoder

Encode and decode URL strings for web development

🚀

API Tester

Test REST APIs instantly - Like Postman, but in your browser

64

Base64 Encoder/Decoder

Encode and decode Base64 strings easily

⏰

Timestamp Converter

Convert between Unix timestamp and human-readable date

🧪

STUN/TURN Server Test

Test and validate STUN/TURN server configuration for WebRTC

#

Hash Generator

Generate MD5, SHA-1, SHA-256 hashes from text