{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
Choose the relying-party context that will consume this token.
Comma-separate exact JOSE names, for example RS256, PS256, ES256, or EdDSA.
Blank records an incomplete local comparison; it does not trust the token's own issuer value.
Use one recipient or a comma-separated accepted audience list.
Profile changes load a practical review default; edit it to match deployed policy.
minutes
Auto detect chooses JSON when the first non-space character is “{”; otherwise it uses compact JWT or Bearer parsing.
Claims remain untrusted until the relying party verifies the signature and applies its own policy.
{{ sourceMeta }}
{{ sourceStatus || 'Browser-local reactive review; maximum source size 256 KiB.' }}
{{ workflowFeedback }}
Leave blank for “JWT review”.
Use the same tolerance as the relying party when it is known.
seconds
Blank is neutral and keeps the current page-load review time.
Enable only when server-side replay, revocation, or incident correlation acts on token IDs.
{{ require_jti ? 'Enabled' : 'Disabled' }}
Comma-separate organization-specific claim-name fragments. Blank adds nothing.
ControlSignalSeverityObservedEvidenceNext actionCopy
{{ row.control }}{{ row.status }}{{ row.severity }}{{ row.observed }}{{ row.evidence }}{{ row.action }}

{{ row.control }}

{{ row.severity }}

{{ row.action }}

Evidence: {{ row.evidence }}

No Fail or Warn rows are present. Keep verifier-side signature, issuer, audience, type, clock, revocation, and authorization checks in place.

This queue prioritizes local review evidence. It does not verify a signature, trusted key, revocation state, or effective authorization.

AreaClaimTypeValueInterpretationCopy
{{ row.area }}{{ row.claim }}{{ row.type }}{{ row.value }}{{ row.interpretation }}
JWT Decoder Decode a compact or Bearer JWT locally and inspect readable claims with focused checks for timing, identity, lifetime and unverified signatures.
SAML Assertion Timing Checker Check SAML assertion timing from XML or encoded captures, apply clock-skew and expiry rules, and separate bearer from replay and session evidence.
HTTP Security Headers Checker Audit pasted HTTP security headers for browser policy, session protection and exposure risks with local scoring and a prioritized fix order.
CSP Header Policy Checker Check a Content-Security-Policy header for risky script sources and missing baseline directives, with reporting and rollout blockers explained.

A JSON Web Token (JWT) carries claims about a subject in a compact form that fits HTTP headers and application messages. Common claims identify the issuer, subject, intended audience, issue time, activation time, expiration, and permissions. Those fields influence access decisions, so a token can be correctly encoded and still be unsafe for a particular API or client.

Compact JWTs normally have a Base64URL-encoded header, payload, and signature separated by dots. Encoding is not encryption. Anyone who obtains a typical signed token can decode its header and payload, which makes passwords, API keys, personal data, and excessive authorization grants inappropriate claim content.

Trust comes from the relying party that consumes the token. It must verify the signature with a trusted key, restrict acceptable algorithms, bind that key to the expected issuer, check that the audience names the recipient, enforce time claims, and apply its own authorization policy. Reading the claims is useful review evidence, but it cannot replace those acceptance checks.

  • Identity fit: do iss, sub, and aud match the application and principal expected here?
  • Time fit: are exp, nbf, and iat valid NumericDate values for the relying party's clock and allowed lifetime?
  • Replay and authorization: does the token carry the identifier, nonce, scope, or role controls required by its use?
  • Disclosure: would decoded claim names or values reveal secrets, personal information, or more privilege than the request needs?

The expected answers change with token purpose. An OpenID Connect ID token has different replay cues from an API access token, while a client assertion normally needs a much shorter lifetime and a replay identifier. A generic “valid JWT” label therefore says too little; acceptance must be tied to one explicit token profile and one relying-party policy.

How to Use This Tool:

Review a token against the policy of the API, client, or session that will consume it.

  1. Choose the Token use profile. The profile sets required-claim expectations and a practical default maximum lifetime; replace that lifetime with the deployed policy when it differs.
  2. Enter the trusted Allowed algorithms, Expected issuer, and Expected audience. Leaving issuer or audience blank records an incomplete comparison rather than trusting the token's own value.
  3. Paste one compact JWT, Bearer line, decoded payload object, or decoded header-and-payload object into JWT or claims source. Select a source format only when automatic detection chooses the wrong path.
  4. Set Clock skew allowance to the same tolerance used by the relying party. Use the review epoch override only to reproduce an earlier or future review, and require jti when token-specific replay or revocation controls depend on it.
  5. Review Fail and Warn items before the numeric score. Follow the remediation queue, then verify the original token's signature, key ownership, type, revocation state, and effective authorization in the real relying party.

Interpreting Results:

A Critical or High label identifies claim evidence that should stop or redirect a token review. A Review label means at least one warning remains, even when the point score is high. Low claim risk means the configured local checks produced no Fail or Warn item; it does not mean the token is authentic or authorized.

  • Prioritize Critical findings such as alg=none, then High failures for algorithm, signature shape, expiration, lifetime, issuer, audience, or secret-like claim paths.
  • Compare the observed issuer and audience with trusted configuration. A value merely appearing in the token is not evidence that it is acceptable.
  • Read decoded claim values as untrusted data until cryptographic verification succeeds.
  • Treat sensitive-path detection as a prompt for inspection. It matches configured words in claim paths, so it can miss sensitive values under neutral names and can flag harmless fields with risky names.

Technical Details:

JWT review has two different mechanisms. First, compact or decoded JSON is parsed into a JOSE header and claim set. Second, ordered policy checks compare that untrusted content with explicit local expectations. A three-part compact value proves only that a signature segment exists; no cryptographic operation is performed here.

Rule Core:

Area Rule Important boundary
Structure Accept a two- or three-part compact JWT-like value, decoded payload JSON, or decoded header-and-payload JSON. A five-part compact value is treated as encrypted JWE and must be decrypted elsewhere.
Algorithm Compare the received alg with the trusted allow-list. none is Critical; an unlisted algorithm is High.
Time Interpret exp, iat, and nbf as NumericDate seconds. exp ≤ review time − skew fails; nbf > review time + skew fails. Lifetime is exp − iat.
Issuer and audience Compare issuer exactly and require at least one received audience to match the accepted list. A blank expected value is a warning, not a pass.
Replay Expect jti for refresh-like tokens and client assertions, or when the override is enabled. Expect nonce for the ID-token profile. Presence alone does not prove replay storage or nonce comparison.
Payload exposure Flatten nested claim paths and compare their names with built-in and additional sensitive terms. More than 4,096 payload bytes, more than 35 top-level claims, or more than four nested claims also produces a complexity warning.

Remote key headers such as jku and x5u receive a High warning because token-supplied locations must not control key retrieval. Suspicious path, whitespace, or injection-like characters in kid receive a Medium warning. Broad authorization values are detected by patterns such as wildcard, admin, root, delete, write, manage, or owner; the result is a review cue rather than a full authorization proof.

Formula Core:

Every Fail uses the full weight for its severity. Every Warn uses 60% of that weight rounded to the nearest integer. Pass and Info items add zero risk points. Critical, High, Medium, Low, and Info weights are 28, 18, 10, 4, and 0.

score = max(0, min(100, 100− ∑in pointsi ))
OrderLabelCondition
1Critical claim riskAny Critical failure, or score < 55
2High claim riskAny other failure, or score < 75
3Review claim riskAny warning, or score < 92
4Low claim riskNo earlier condition matched

The label rules are evaluated in order, so one Critical failure outranks the remaining score and any failure prevents a Review or Low label. The weights and bands are a transparent local triage model, not an IETF or OpenID Connect scoring standard.

Profile Defaults:

ProfileDefault maximum lifetimeAdditional expectation
API access token15 minutesScope-like authorization is expected.
OpenID Connect ID token60 minutesA nonce is expected.
Refresh-like JWT10,080 minutesjti is required.
Client assertion5 minutesjti is required.
Browser session JWT480 minutesNo extra replay claim is required by the profile.

Security and Privacy Notes:

The token source is decoded and reviewed in the browser, but production tokens are still bearer credentials and should not be pasted into shared machines, recordings, screenshots, tickets, or chat. Use a redacted or short-lived test token whenever possible.

  • No signature, trusted-key ownership, token type, revocation state, or server-side authorization is verified.
  • Decoded JSON lacks compact-signature evidence; a two-part value lacks a normal signature segment.
  • The review time defaults to the page-load epoch. Set an explicit epoch when reproducing a historical decision.
  • Sensitive-name matching is heuristic and cannot establish data classification or confidentiality.

Worked Examples:

Well-shaped access token at a fixed review time

An access token using RS256 has the expected issuer and orders-api audience, an issue time 5 minutes before review, an expiration 10 minutes after review, a jti, and the narrow scope read:orders. With a 15-minute lifetime limit, the local checks produce 0 risk points and Low claim risk. The signature segment is still only present, not verified, so acceptance remains conditional on the API's cryptographic and authorization checks.

References: