Readable claims are not authenticated claims
A JSON Web Token often consists of three base64url-encoded parts: a protected header, a payload and a signature. The header and payload are designed to be readable. Anyone holding an ordinary signed JWT can decode them without knowing the signing key. That convenience is also a source of mistakes when decoded claims are treated as proof before a signature and the application’s validation rules have been checked.
This inspector separates those steps. It decodes the token, reviews selected time claims and optionally verifies an HS256 or RS256 signature using a key you supply. It does not discover a trusted key from an untrusted token or decide that an issuer is acceptable for your application. A valid signature is evidence that the token matches the supplied key, not that every claim should be acted on.
Decode the header and claims without granting trust
The header normally identifies the signing algorithm with an alg field. The payload can contain standard claims such as sub, iss, aud, exp, nbf and iat, as well as application-specific fields. These values are untrusted input until the verifier applies the correct signature and claim-validation rules. A role named administrator in a decoded payload has no authority by itself.
This tool expects the three-part compact representation of a signed JWT. It does not support encrypted five-part JWE tokens, arbitrary critical extensions or unencoded payloads. Invalid base64url and invalid JSON are rejected rather than displayed as if a partial decode were a valid token.
Time claims use NumericDate values in seconds since the Unix epoch. Millisecond timestamps and numeric-looking strings are common integration errors. The inspector flags nonnumeric values and compares exp and nbf with the current device time. That clock can be wrong, and production applications may apply a narrowly defined clock-skew allowance. The diagnostic timestamp is not a substitute for your server’s validation policy.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Supply a key from an independent trust source
For HS256, the key field is interpreted as the exact UTF-8 bytes of the shared secret you enter. It is not automatically base64-decoded. If your application stores a base64 representation of a binary key, account for that difference before comparing results. A mismatch between key representation and actual key bytes can make a legitimate signature fail verification.
For RS256, supply an SPKI PEM public key with BEGIN PUBLIC KEY markers. The tool imports it through Web Crypto and verifies the signature. Do not paste an RSA private key; verification needs only the public part. The tool does not fetch a URL from the token’s header or trust a key merely because the token includes it.
Production verification should pin acceptable algorithms and select keys through an established trust configuration. This inspector dispatches between its explicitly supported algorithms for a diagnostic check; that is not a complete application acceptance policy. A token signed by a valid but unrelated key must still be rejected by an application that does not trust that issuer.
Keep application validation separate from the signature
After a valid signature, the application still needs to verify issuer, audience, token purpose, time limits and any relevant session or revocation state. A token intended for one service should not automatically be accepted by another. An access token and an identity token can have different purposes even when both are formatted as JWTs.
This tool reports decoded claims so that you can inspect them, but it does not know your allowed issuer, expected audience or business rules. It also does not contact an identity provider to determine whether a user has been disabled or a session revoked. Those checks belong in the relevant application and authentication system.
Use disposable test tokens whenever possible. Real tokens can contain personal information or provide active access. The exported report contains the decoded claims, so remove sensitive fields before sharing it. A failed signature should lead you to inspect algorithm, key representation, key rotation and token integrity; it should never be fixed by skipping verification in the application.
What the verifier does and does not establish
| Result | Meaning |
|---|---|
| Decoded successfully | The header and claims are readable JSON; their origin is not established. |
| Signature valid | The signed bytes match the supplied key and supported algorithm. |
| Token expired | The numeric exp value is before the current device time. |
| Algorithm none | Unsigned tokens are not accepted for verification. |
| Issuer / audience | Displayed for inspection; your application’s expected values are not supplied here. |
Strengths and limitations
What this is useful for
The tool makes decoding and verification visibly different operations. It supports real HMAC and RSA signature checks through Web Crypto, highlights common time-claim mistakes and keeps the key out of the exported report. The decoded data is useful for debugging token construction and key-rotation issues.
What to keep in mind
It is not a production authentication service or a complete JWT acceptance policy. Supported algorithms are limited to HS256 and RS256, the HMAC key is literal UTF-8, and issuer, audience, revocation and application-specific claims remain your responsibility. A trusted key source is essential.
Common questions
Can I verify a token without a key?
You can decode ordinary signed JWT claims without a key, but you cannot verify their signature that way. Public-key algorithms require a trusted public key, while HMAC algorithms require the shared secret. The tool explicitly labels an inspection without a key as verification not requested.
Why does a token with a valid signature still fail login?
The application may reject its issuer, audience, token type, expiration, not-before time or session state. The user may also lack required authorisation. Signature validity establishes integrity relative to a key; it does not automatically satisfy every authentication and business rule.
Are my token and key uploaded?
No. Decoding and supported signature verification occur in the tab using Web Crypto. The verification key is excluded from the JSON report, but decoded claims are included. Clipboard managers, browser extensions and screenshots can still expose material you paste, so prefer test credentials.
Why is my HS256 result different from the server’s?
Check the exact key bytes and signing input. This tool treats the entered secret as literal UTF-8, preserving spaces. A server may decode a base64 secret or use another stored representation. Also verify that the token was not altered and that the expected key version is being used.