How the JWT Inspector Works

The JWT Inspector takes a JSON Web Token string, splits it into its three parts (header, payload, and signature), Base64URL-decodes the header and payload, and displays the resulting JSON with human-readable formatting.

It also identifies standard JWT claims — such as iss, sub, exp, iat, and nbf — and converts Unix timestamps to readable dates so you can immediately see when a token was issued, when it expires, and whether it has already expired.

A JWT is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded segments separated by dots:

1. Header — a JSON object describing the token type and signing algorithm (e.g. HS256, RS256).
2. Payload — a JSON object containing claims: pieces of information about a user, session, or authorization context.
3. Signature — a cryptographic signature that allows the recipient to verify that the token has not been tampered with.

Because the header and payload are only Base64URL-encoded (not encrypted), anyone with the token can decode and read them. This is by design — JWTs are meant to carry verifiable claims, not to hide data.

This is an important distinction. Decoding a JWT means reading the header and payload — any tool (or a single line of code) can do this. Verifying a JWT means checking the signature against a secret or public key to confirm the token was issued by a trusted party and has not been modified.

The JWT Inspector only decodes. It does not verify signatures. This means you should never trust a decoded JWT payload on its own for authorization decisions — signature verification must happen on your server or in your authentication library.

Decoding is still useful for debugging: it lets you quickly see what claims a token carries, check expiration, and identify the signing algorithm — all common tasks during development and troubleshooting.

When you paste a JWT into the inspector, the processing happens entirely in your browser using JavaScript. The token string is split on the . characters, each segment is Base64URL-decoded using browser-native APIs, and the resulting JSON is parsed and displayed.

No API call is made. The page does not send your token to a server for decoding. You can verify this by opening your browser's developer tools and monitoring the Network tab — you will see no requests when you paste or decode a token.

The site itself is a static site served from Cloudflare Pages. Once the page loads, the decoder runs without any further network requests for processing.

JWTs frequently contain sensitive information: user IDs, email addresses, roles, permissions, session identifiers, and organization details. Pasting a production JWT into a server-side decoding tool means transmitting all of that data to a third party.

Local decoding reduces that exposure. Because the token never leaves your browser, it is designed for situations where you need to inspect a JWT quickly but prefer not to send it through someone else's infrastructure.

This is particularly relevant when you are working with:

• Access tokens from production authentication systems
• Tokens from customer-reported issues or support tickets
• Tokens containing PII such as email addresses or user names
• Tokens from internal services where the claims include system identifiers or resource permissions

The JWT specification defines several registered claim names. The inspector highlights these when present:

iss(Issuer)

Identifies who issued the token (e.g. your auth server URL).

sub(Subject)

Identifies the principal — typically a user ID.

aud(Audience)

Identifies the intended recipient (e.g. an API or client ID).

exp(Expiration Time)

Unix timestamp after which the token must not be accepted. The inspector shows whether the token has expired.

nbf(Not Before)

Unix timestamp before which the token must not be accepted.

iat(Issued At)

Unix timestamp when the token was created.

jti(JWT ID)

A unique identifier for the token, useful for preventing replay.

All timestamp claims are displayed both as raw Unix timestamps and as human-readable UTC dates.

Local processing reduces data exposure, but it is not a guarantee of absolute security. There are factors outside any browser-based tool's control:

• Browser extensions can read page content, including tokens pasted into input fields.
• Clipboard history managers may store tokens you copy and paste.
• Shared or public devices may retain browser data between sessions.
• Your organization may have policies restricting where production tokens can be processed.

Always follow your organization's security policies when handling production tokens, customer data, or any JWT that contains sensitive claims. If your company restricts the use of browser-based tools for certain data types, follow those guidelines.

• Debugging authentication flows — quickly inspect the claims in an access token or ID token returned by your auth provider to verify scopes, roles, and expiration.
• Checking token expiration — paste a token and immediately see whether it has expired and when.
• Inspecting tokens from logs — decode JWTs found in request logs, error payloads, or audit trails without sending them to an external service.
• Customer support triage — when a customer shares a token as part of a bug report, decode it locally to understand the context without exposing their data.
• Learning JWT structure — use the Sample button to generate a demo token and explore how headers, payloads, and claims work.