Using a JWT Inspector: Read Any Token Instantly

Using a JWT Inspector: Read Any Token Instantly

During debugging, a JWT inspector Base64Url-decodes the three dot-separated sections of a signed JWT and renders them as human-readable JSON.¹² The header section reveals the signing algorithm and key ID; the payload reveals the claims the issuer included, such as user ID, expiry, roles, and custom data. Paste any JWT into the decoder above to inspect it instantly. The tool requires no server connection and transmits no token data, making it safe to use with production tokens you cannot expose to third-party websites.

Inspecting rather than verifying is the right move during debugging. You do not need to know the signing key to read the contents of a JWT: the payload is only encoded, not encrypted. Seeing the raw claims confirms whether the expected fields are present, whether the exp timestamp has passed, and whether the algorithm matches what your server expects.³ Because offline inspection reveals no secret, you can safely inspect tokens from staging, QA, and production without risk of credential exposure.

What the inspector shows

Pasting a JWT into an inspector reveals three distinct panels. The header panel shows the signing algorithm (alg) and token type (typ), with an optional kid claim that identifies which key to use for verification. The payload panel renders all claims in formatted JSON: standard fields like iss, sub, exp, and iat, alongside provider-specific claims like realm_access (Keycloak) or cognito:groups (AWS Cognito). Furthermore, the inspector highlights exp in human-readable format: 'Expires in 14 minutes' is more useful than a raw Unix timestamp during an active debugging session, because the relative time remaining tells you immediately whether expiry is the cause of a 401 error.

Header vs payload

The JWT header specifies how the token was signed, not who signed it. alg tells you the algorithm: HS256 for symmetric HMAC, RS256 for RSA, ES256 for ECDSA.³ kid identifies the specific key among potentially many in the issuer's JWKS, enabling your verifier to select the correct public key when the provider rotates signing keys. Conversely, the payload contains the actual claims: sub identifies the subject (user or service), iss names the issuer, and exp marks the expiry boundary that determines when the token must be rejected.

Both header and payload are Base64Url-encoded structures that are readable by anyone with access to the raw token string, which is why an inspector can show you every claim without needing the issuer's private key or JWKS endpoint. Only the signature section requires cryptographic verification, because the signature is a mathematical proof that binds the header and payload to the issuer's private key and detect any single-character alteration.

Reading alg without trusting it

The alg value tells your verifier which algorithm to expect, but it should not be the only control. Your server should reject unexpected algorithms and compare kid against the issuer's current key set. An inspector makes the header visible; your verification code decides whether the token is valid. Hard-coding the expected algorithm list in your verification middleware, rather than reading alg from the incoming token header, prevents algorithm confusion attacks where an attacker swaps RS256 for HS256 to exploit a known server-side vulnerability.

When to use a browser inspector

Use a browser-based JWT inspector whenever you need to examine a token without transmitting it to a server. Debugging an expired token, confirming a missing claim, or verifying that a custom claim was injected correctly all require only the decoded payload: no signature check needed. Yet for security-sensitive operations, never rely solely on inspection: always verify the signature server-side before trusting claims, because a decoded payload provides visibility into what the token contains but zero proof that the issuer actually created it.⁴

Inspecting in the browser is the debugging layer; server-side verification is the security layer. Both steps serve different purposes and neither replaces the other, which is why production applications should always include a verification step even after the development team has confirmed the token shape through inspection. CapyToolkit's offline decoder fits the first role perfectly: it reads the payload locally so you can diagnose claims, algorithms, and expiry without ever exposing the token to a third-party service.

What the inspector cannot tell you

A browser JWT inspector shows the exact claims the token carries, but cannot confirm whether those claims are trustworthy. The decoded sub, role, or email values are accurate only if the issuer's private key signed the token and no character was altered in transit. An inspector that skips signature verification cannot distinguish a genuine Auth0 token from one constructed by hand with the same format, which is why the decoded payload must always be treated as unverified data until your backend confirms the cryptographic proof.⁴

For production: inspection is not authorization

For debugging, this limitation rarely matters: you control the token source and trust the content. For production access control, it matters entirely. Never route an access decision through decoded-but-unverified claims in server code. CapyToolkit's decoder is an inspection tool, not a verification tool: its value is speed during debugging, not security during authorization. After inspecting, always verify in your backend before trusting any claim the decoder displayed. A decoded payload that shows the correct sub, iss, and exp values is only genuinely trustworthy once your server has confirmed the cryptographic signature matches the issuer's published key material.

Support workflow considerations

For support workflows, ask the customer to paste only the minimum token needed for debugging, then remove it from the ticket after review. The inspector can reveal whether the token has the expected shape, but it cannot prove issuer trust. Pair that inspection with backend logs from jwtVerify so your team confirms both the claim shape and the cryptographic validity, which prevents a support agent from making authorization decisions based on unverified payload data.

Asking the customer for the minimum token needed protects their other sessions while still letting you reproduce the problem locally. The decoded shape confirms whether the issue is a missing claim or an expiry problem before you open backend logs. Closing the loop with server-side verification means support never authorises an action on inspection alone, which keeps the debugging process safe for customer data.

When to use this

Use this inspector when you need to read a JWT payload during development or debugging: checking whether a claim is present, confirming an expiry time, or diagnosing a missing field without running your full backend stack. Paste a suspect token into the decoder for reading a JWT payload instantly, and read both side by side before you write a single line of debug code.

Examples