JWT Parser & Inspector: The Complete Guide

What is a JWT?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined by RFC 7519. It encodes claims (statements about a user or entity) as a JSON object that is digitally signed or encrypted. JWTs are the backbone of modern authentication and authorization in web applications, API security, and single sign-on (SSO) systems.

JWTs are self-contained — all the information needed to verify a user's identity is embedded in the token itself, eliminating the need for server-side session storage. Every JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. Our JWT Parser & Inspector decodes these parts instantly so you can inspect the token contents without writing code.

JWT Structure: Header, Payload, Signature

A typical JWT looks like this (line breaks added for readability):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header

The header typically contains the token type (typ) and the signing algorithm (alg):

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

Common algorithms include HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), and ES256 (ECDSA with SHA-256). The parser displays the header in a formatted, syntax-highlighted view for quick inspection.

2. Payload

The payload contains the claims — statements about the user and additional metadata. This is the most commonly inspected part of a JWT:

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

3. Signature

The signature is created by taking the encoded header and payload, combining them with a secret key (for HMAC) or a private key (for RSA/ECDSA), and signing them with the algorithm specified in the header. The signature verifies that the token was not tampered with during transmission.

Standard Claims (Registered Claim Names)

The JWT specification defines several registered claims that provide interoperability across implementations:

In addition to registered claims, JWTs commonly carry custom claims defined by each application, such as role, email, permissions, or tenant_id. The parser displays all claims — both standard and custom — in a formatted JSON view.

Expiration Validation

One of the most important features of a JWT parser is expiration validation. The exp claim contains a Unix timestamp (seconds since January 1, 1970). The parser compares this timestamp against the current time and displays a clear status indicator.

// Example: Token that expires at 1516242622
// Which is January 18, 2018 1:50:22 AM UTC

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

The parser shows:

• Expiration date/time in human-readable local time
• Status badge: "Valid" (green) if not expired, "Expired" (red) if past the expiration
• Remaining time: How much time is left before the token expires

Understanding the Signature

The signature is the security backbone of a JWT. Here is how it works at a high level:

1. Encode the header and payload using Base64URL encoding (URL-safe, no padding).
2. Combine them with a dot separator: base64UrlEncode(header).base64UrlEncode(payload)
3. Sign the combined string using the algorithm and key specified in the header.
4. Base64URL encode the resulting signature and append it as the third segment.

The parser displays the raw signature bytes and the algorithm used, allowing you to:

• Verify the signature server-side using your secret or public key
• Identify what algorithm the token uses at a glance
• Detect algorithm confusion attacks (e.g., a token claiming "alg": "none" or switching from RS256 to HS256)

// Algorithm confusion warning
// If a server expects RS256 but the token says HS256,
// an attacker could use the public key as an HMAC secret.
// Always validate the algorithm against an allowlist!

Practical Examples

Debugging an Authentication Flow

Your application's login flow is returning 401 errors. Copy the JWT from the Authorization header, paste it into the parser, and inspect it immediately. You might discover that the exp claim is set in the past, the aud claim doesn't match your server, or a custom claim like role has an unexpected value.

// Example: Debugging a 401 error
Header: Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

// After parsing, you discover:
{
  "sub": "user_abc123",
  "exp": 1617000000,  // Already expired!
  "scope": "read:reports"
}

Inspecting Third-Party Tokens

When integrating with Auth0, Firebase, or other identity providers, use the parser to inspect the tokens they issue. Verify that the claims match your expectations and that the token structure follows the JWT standard.

Educational Tool for Learning JWT

The parser is an excellent teaching tool. Students can paste a JWT, see the three parts decoded in real time, and understand how the header, payload, and signature relate to each other. The formatted JSON output makes the token contents immediately understandable.

Validating Webhook Payloads

Some services sign webhook payloads as JWTs. Use the parser to decode the token and inspect the claims before processing the webhook, ensuring the payload is authentic and not expired.

JWT Best Practices

• Never expose secrets client-side: JWTs should be transmitted over HTTPS, but the signing secret or private key must never be exposed in client-side code. The parser is a decode-only tool for inspecting tokens you already have.
• Always validate the signature: Decoding a JWT (Base64URL decoding) is trivial — anyone can do it. Always verify the signature on your server before trusting the contents.
• Check the algorithm allowlist: Always validate that the alg header matches an expected value from an allowlist. Reject tokens with "alg": "none" or unexpected algorithm values to prevent algorithm confusion attacks.
• Validate expiration: Check the exp claim and reject expired tokens. Consider also checking nbf (not before) if your issuer uses it.
• Keep tokens small: JWTs are typically passed in HTTP headers, which have size limits. Avoid storing large amounts of data in custom claims. Store a user ID and fetch additional data from your database as needed.
• Use short expiration times: Access tokens should expire in 15-60 minutes. Use refresh tokens with longer lifetimes for persistent sessions.
• Include a jti for replay prevention: The jti (JWT ID) claim provides a unique identifier that helps detect token replay attacks.