JWT Encoder & Decoder

🔐 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. JWTs are commonly used for authentication and secure information exchange in modern web applications and APIs.

A JWT consists of three parts separated by dots: Header.Payload.Signature. Each part is Base64 URL encoded, making it safe for transmission in URLs, HTTP headers, and cookies.

⚙️ How This JWT Tool Works

This professional JWT tool provides comprehensive encoding, decoding, verification, and analysis capabilities for JSON Web Tokens. Create new JWTs with custom claims or decode existing tokens to inspect their structure and verify signatures.

🔥 Key Features:

  • JWT Encoding: Create JWTs with custom header and payload
  • JWT Decoding: Automatically decode JWT structure as you paste
  • HMAC Signature: Generate and verify signatures with HS256/HS384/HS512
  • Three-Part Visualization: Clear separation of Header, Payload, and Signature
  • Expiration Checking: Automatic validation of exp, iat, and nbf timestamps
  • Claims Inspection: Display standard claims (iss, sub, aud, exp, iat, nbf)
  • Real-time Status: Visual indicators for expired or not-yet-valid tokens
  • One-Click Copy: Copy header, payload, signature, or generated token with a single click
  • Client-Side Only: All processing happens in your browser for security

🏗️ JWT Structure Explained

1. Header

The header typically consists of two parts: the token type (JWT) and the signing algorithm being used (e.g., HS256, RS256).

Example Header:

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

2. Payload

The payload contains the claims - statements about the entity (typically the user) and additional metadata. Claims are categorized into three types:

  • Registered Claims: Predefined claims like iss (issuer), exp (expiration), sub (subject), aud (audience)
  • Public Claims: Custom claims that should be collision-resistant
  • Private Claims: Custom claims agreed upon between parties

Example Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022,
  "exp": 1735689600
}

3. Signature

The signature is created by taking the encoded header, encoded payload, a secret (for HMAC) or private key (for RSA/ECDSA), and signing them using the algorithm specified in the header.

Signature Creation (HMAC):

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

🔑 Supported Algorithms

HMAC Algorithms (Symmetric) - WASM Compatible

  • HS256: HMAC with SHA-256 - Most commonly used, requires shared secret
  • HS384: HMAC with SHA-384 - Stronger hash, requires shared secret
  • HS512: HMAC with SHA-512 - Strongest HMAC variant, requires shared secret

When to use: Simple authentication scenarios, same secret shared between issuer and verifier. These are the most common algorithms for JWT and work perfectly in browser environments.

⚠️ Note on RSA/ECDSA Algorithms:

This tool currently supports HMAC algorithms only (HS256, HS384, HS512) for WebAssembly compatibility. RSA (RS256, RS384, RS512) and ECDSA (ES256, ES384) algorithms require native cryptographic libraries that are not available in browser environments.

However, you can still decode JWTs signed with any algorithm - you just won't be able to verify RSA/ECDSA signatures in the browser. The header and payload will be decoded correctly regardless of the algorithm used.

📋 Standard JWT Claims

Registered Claims

  • iss (Issuer): Identifies who issued the JWT (e.g., 'https://auth.example.com')
  • sub (Subject): Identifies the subject of the JWT (e.g., user ID '1234567890')
  • aud (Audience): Identifies the recipients the JWT is intended for
  • exp (Expiration Time): Unix timestamp after which the JWT must not be accepted
  • iat (Issued At): Unix timestamp when the JWT was created
  • nbf (Not Before): Unix timestamp before which the JWT must not be accepted
  • jti (JWT ID): Unique identifier for the JWT, prevents replay attacks

💼 Common Use Cases

1. 🔐 API Authentication

JWTs are widely used for API authentication, allowing stateless authentication without session storage on the server.

Workflow:

  1. User logs in with credentials
  2. Server generates JWT with user information
  3. Client includes JWT in Authorization header for subsequent requests
  4. Server verifies JWT signature and checks expiration

2. 🔄 Single Sign-On (SSO)

JWTs enable SSO by allowing users to authenticate once and access multiple services without re-authentication.

3. 📡 Secure Information Exchange

JWTs provide a secure way to transmit information between parties, with signature verification ensuring data integrity.

4. 🐛 Debugging & Testing

Developers use JWT tools to create test tokens, inspect tokens during development, troubleshoot authentication issues, and verify token structure.

🎯 Best Practices

  • Keep Secrets Secure: Never share HMAC secrets publicly or commit them to version control
  • Use Strong Secrets: Use long, random secrets (at least 256 bits for HS256)
  • Set Reasonable Expiration: Short-lived tokens (15-60 minutes) are more secure
  • Always Verify Signatures: Never trust JWT payload without signature verification
  • Check Expiration: Always validate exp, iat, and nbf claims
  • Don't Store Sensitive Data: JWTs are not encrypted - avoid storing passwords or sensitive data
  • Use HTTPS: Always transmit JWTs over HTTPS to prevent interception
  • Implement Token Refresh: Use refresh tokens for long-term access
  • Validate All Claims: Check iss, aud, and other claims beyond just signature
  • Consider Algorithm Choice: HMAC (HS256/384/512) is sufficient for most use cases and has excellent browser support

🔗 Related Tools

  • CRC Tool - Calculate CRC checksums with 100+ algorithms for data integrity verification
  • File Hash Calculator - Calculate MD5, SHA-1, SHA-256, SHA-512 hashes for files and text

Algorithm & Secret

Algorithm:
Secret Key:
Header (JSON)
Payload (JSON)