JWT trust inspection

Decode is not the same as verify

A JWT can contain readable claims without providing trustworthy evidence. This tool first decodes a compact, three-part JSON Web Signature and labels the resulting header and claims as untrusted. Inspect without verifying does not import a key, contact a provider or accept a user identity. It is useful for examining token structure, finding malformed JSON and checking which claims were supplied. Duplicate JSON names, including names disguised with Unicode escapes, are rejected rather than interpreted differently by different parsers. Encrypted JWE tokens and detached payloads are outside this profile.

Verify with an independently trusted public key

The optional verification action supports RS256 and ES256 through the browser Web Crypto API. Select the expected algorithm yourself and paste one public JSON Web Key obtained independently from the intended issuer. The token must not decide the algorithm or where a trusted key comes from. Private keys, symmetric secrets and key-discovery URLs are rejected. The tool never downloads a JWKS, follows a jku or x5u header, or treats an embedded key as authority. Your key-provenance confirmation is an input declaration, not something this page can independently establish.

Choose the claim policy explicitly

Verification requires an expected issuer and audience, compared exactly, and an expiration claim under this diagnostic profile. A string audience or an array containing the expected audience is supported. Optional not-before and issued-at values are checked when present. NumericDate values may contain finite fractions. Evaluation uses this device’s current clock and a chosen tolerance between zero and 120 seconds, defaulting to zero. Expected type is optional; leaving it blank visibly records that type was not checked. Requiring expiration and checking issued-at against the clock are profile rules, not a claim that every JWT specification imposes them.

Read signature and policy outcomes separately

A token can have a valid cryptographic signature and still be expired or addressed to a different application. Those outcomes remain separate: signature validity does not turn a failed claim policy into success. Modified signatures and messages are rejected. A successful selected-check result means only that this key and policy matched at the recorded local time. It does not establish revocation, replay safety, subject ownership, nonce correctness, permission scopes, issuer availability or application authorization. It must not replace a maintained authentication implementation or a server-side permission check.

Privacy, limits and unsupported profiles

Token inputs are bounded to 32 KiB and public-key JSON to 16 KiB. JSON has independent nesting, value-count and string limits. RSA verification accepts 2048–4096-bit keys with exponent 65537; ES256 accepts P-256 and the 64-byte JWS signature format. Other algorithms and unsupported JOSE headers are reported rather than guessed. Crypto results have a five-second deadline. Cancellation cannot stop the browser’s internal crypto operation, but late results are ignored. The page loads site assets normally; after loading, inspection and verification work offline without admission, telemetry or token-related network requests. Its Content Security Policy also blocks network connections and form submissions.

Clear, export and reproduce carefully

Inputs and decoded results are held in page memory, not browser storage. Editing invalidates earlier results, and Clear or page lifecycle transitions remove displayed inputs. This is not guaranteed memory erasure, and it cannot protect against compromised browsers or extensions. The explicit export contains only the method, selected algorithm, clock tolerance, evaluation timestamp and enumerated check outcomes. It omits the token, claims, public-key material, key identifiers and fingerprints. Share that redacted diagnostic report rather than a live credential; use controlled fixtures when a developer needs the exact token to reproduce a failure.

Method references and related tools

RFC 7519 defines registered claims; RFC 7518 defines the algorithms. RFC 8725 addresses trust and algorithm selection. W3C Web Crypto specifies native signature verification.

Response stability monitor · All tools · Overall measurement methodology