JWT Decoder Pro: Verify Token Signatures & Analyze Claims

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is a standard (RFC 7519) for securely transmitting information between parties. It's commonly used for authentication and authorization in:

• Single-Page Applications (SPAs) — stateless user sessions
• REST APIs — bearer token authentication
• OAuth2 and OpenID Connect — issuing access and ID tokens
• Microservices — service-to-service authentication
• Webhooks — verifying sender identity

Unlike session cookies, JWTs are self-contained and don't require a database lookup to verify. The token itself holds the claims (user identity, permissions, etc.), and a cryptographic signature ensures it hasn't been tampered with.

The Three Parts of a JWT

Every JWT consists of three parts separated by dots:
header.payload.signature

1. Header

The header is a JSON object that specifies the token type and the algorithm used to sign it. Example:

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

This tells us the token is signed with HMAC SHA-256. Common algorithms include HS256, HS512 (HMAC-based) and RS256, RS512 (RSA-based).

2. Payload

The payload contains the actual claims—data about the user or application. Example:

{
  "sub": "user123",
  "name": "Alice Johnson",
  "iat": 1717747200,
  "exp": 1717833600,
  "role": "admin"
}

Standard claims include sub (subject), iat (issued at), and exp (expiration). You can also add custom claims likerole or permissions.

3. Signature

The signature is computed by taking the header and payload, combining them, and signing with a secret key (for HMAC) or private key (for RSA). It ensures the token hasn't been modified. If someone changes a single character in the header or payload, the signature becomes invalid.

Signature Verification: HMAC vs. RSA

Signature verification is critical for security. It proves the token came from a trusted issuer and hasn't been tampered with. There are two main families of algorithms:

HMAC (HS256, HS512)

How it works: A shared secret key is used to both sign and verify the token. Only the issuer and verifier know the secret.

Use case: Applications where the same service issues and verifies tokens. Simple, fast, but requires secure secret distribution.

Example: A single REST API that creates authentication tokens for its own clients.

RSA (RS256, RS512)

How it works: A private key signs the token; a public key verifies it. The public key can be distributed widely.

Use case: Distributed systems where many parties need to verify tokens issued by one authority (e.g., OAuth2 authorization servers).

Example: Google or GitHub OAuth2 tokens. Anyone can verify the signature using Google's public key, but only Google can create new tokens.

Which Should You Use?

• Use HMAC for internal services and simple setups. It's faster and requires less infrastructure.
• Use RSA for OAuth2, OpenID Connect, or any scenario where many services need to verify tokens from a central issuer.

Checking Token Expiry

Token expiry is controlled by the exp claim in the payload. It's a Unix timestamp (seconds since January 1, 1970, UTC) representing when the token is no longer valid.

Why expiry matters:

• Security: If a token is compromised, expiry limits the window for misuse.
• Session management: Forces periodic re-authentication.
• Compliance: Some regulations require session limits.

Typical Patterns

• Short-lived access tokens: 15 minutes to 1 hour. User re-authenticates via refresh token.
• Refresh tokens: 7 days to 1 year. User logs in once, refresh token grants new access tokens.
• API tokens: Days to years. For service-to-service authentication.

Related Claims

• iat — "issued at", the time the token was created
• nbf — "not before", earliest time the token is valid
• exp — "expiration", latest time the token is valid

Understanding JWT Claims

Claims are key-value pairs in the JWT payload. They come in two types:

Standard Claims (Registered)

Defined in RFC 7519, these are widely recognized:

• sub — Subject: who the token is about (usually a user ID)
• iss — Issuer: who issued the token
• aud — Audience: who should accept the token
• exp — Expiration time
• iat — Issued at time
• jti — JWT ID, a unique identifier for this token

Custom Claims

Applications can add their own claims. Common examples:

• role — User's role (admin, user, moderator)
• scope — Permissions (read, write, delete)
• email — User's email address
• permissions — Fine-grained access control

Best Practices

• Keep payloads small. JWTs are often passed in headers, which have size limits.
• Never include secrets in claims. JWTs are encoded, not encrypted. Passwords, API keys, etc. can be decoded.
• Verify claims at your application level. Just because a token is valid doesn't mean the user still has those permissions—check the database if permissions can change mid-session.

JWT Debugging with JWT Decoder Pro

JWT Decoder Pro simplifies token inspection and verification. Here's how to use it:

Decoding a Token

1. Paste your JWT into the input field.
2. Select "No Verification" if you just want to inspect the contents.
3. Click "Decode & Verify".
4. Review the header, payload, and signature sections.

Verifying a Signature

1. Paste your JWT.
2. Select the algorithm: HS256 / HS512 for HMAC, RS256 / RS512 for RSA.
3. For HMAC: Enter the secret key (the same key used to sign the token).
4. For RSA: Paste the public key in PEM format.
5. Click "Decode & Verify".
6. Look for the ✓ Valid or ✗ Invalid badge in the verification status section.

Checking Expiry

The tool automatically calculates:

• Whether the token is expired or still active
• Time remaining until expiration (or how long ago it expired)
• When it was issued (iat claim)
• How old the token is

Extracting Claims

Standard claims (sub, iss, aud, nbf) are highlighted in a dedicated section. All other claims are shown in the full payload JSON. You can copy any section with one click.

Real-World Use Cases

Debugging API Authentication Failures

A client calls your API with an authorization header, but gets a 401 Unauthorized response. Is the token expired? Is the signature invalid? Paste the token into JWT Decoder Pro to find out instantly.

Verifying OAuth2 Tokens

Your app receives an ID token from Google or GitHub. Before you trust the claims, verify the signature using the provider's public key. JWT Decoder Pro handles RSA verification automatically.

Inspecting Custom Claims

Your application issues JWTs with custom claims (user role, permissions, etc.). Decode a token to confirm the claims are correct or to understand why a user is denied access.

Debugging Token Refresh Flows

Your app issues short-lived access tokens and long-lived refresh tokens. Decode both to check expiry and understand when users will need to refresh.

Security Audits

Security teams verify that tokens:

• Are signed correctly (valid signature)
• Don't contain sensitive data (no passwords, API keys)
• Have reasonable expiry times
• Include expected claims

Next Steps

Try JWT Decoder Pro with your own tokens. Whether you're building APIs, integrating OAuth2, or debugging authentication issues, proper JWT handling is critical for security.

Remember: A valid signature means the token wasn't tampered with, but always verify claims at your application level. Just because a token is valid doesn't mean permissions haven't changed in your database.