JWT Claim Risk Brief
{{ summaryPrimary }}
{{ summaryLine }}
{{ riskLabel }} Fail {{ statusCounts.Fail }} Warn {{ statusCounts.Warn }} Pass {{ statusCounts.Pass }} Claims {{ claimInventoryRows.length }}
Use a short label that matches the API, client, or incident you are reviewing.
Choose the closest relying-party context before reviewing expiry, audience, issuer, subject, and replay claims.
Use the algorithms your verifier is configured to accept, for example RS256, ES256, or EdDSA.
Leave blank only when you are doing a first-pass decode without relying-party context.
Enter the API resource, client ID, or audience URI that should receive this token.
Short access tokens reduce replay exposure; adjust this to your production policy.
minutes
Decoding happens locally in the browser. Signature verification still belongs in the relying-party verifier.
{{ sourceStatusLine }}
Default 60 seconds catches meaningful time-claim drift without hiding clock noise.
seconds
Use this for deterministic ticket evidence or replaying a past incident timestamp.
Flag missing jti
Use this when your issuer and resource server maintain revocation, replay, or incident correlation by token ID.
These terms extend the built-in secret, credential, and personal-data checks.
{{ header }} Copy
{{ cell }} {{ cell }}
{{ emptyTableMessage(tab.key) }}
Tags: Encoding, Security
Export to PDF Fullscreen
Customize
Advanced
:

A JSON Web Token, or JWT, carries a signed or encrypted set of statements called claims. Those claims often decide who issued the token, who it describes, which service should accept it, when it becomes valid, when it expires, and what permissions or session details travel with it. A token can decode cleanly and still be risky if the claims do not fit the relying party that is about to trust it.

JWT claim review matters most before a token reaches production policy, incident notes, or verifier configuration. Expired tokens, missing audiences, broad scopes, readable personal data, and unsigned headers are easy to overlook when the token is treated as a blob of text. A readable claim set gives reviewers a quick way to spot policy drift before they depend on the token in an API, OpenID Connect flow, client assertion, refresh workflow, or browser session.

JWT anatomy diagram showing header checks, readable claims, and the verifier boundary.

Claim review has a hard limit. A decoded payload is not proof that the issuer signed the token, that the correct key was used, that the token has not been revoked, or that the application will enforce the permissions correctly. It is a pre-verification safety pass: useful for finding obvious claim and header problems, but never enough to trust a bearer token by itself.

The highest-risk mistakes tend to be ordinary values in the wrong place. An aud value for another API, an exp far beyond policy, an alg header that the verifier should not accept, or a readable email, secret, or API key inside the payload can turn a normal-looking token into something that needs remediation before release.

Technical Details:

JWTs commonly use three compact parts: a protected header, a payload, and a signature segment. The header names the signing algorithm and may include key-selection hints such as kid. The payload carries claims. The signature segment can be present while still needing separate cryptographic verification by the relying party.

The registered claim names from RFC 7519 provide the main vocabulary. iss identifies the issuer, sub identifies the subject, aud names intended recipients, exp sets the expiration time, nbf delays use until a not-before time, iat records issue time, and jti gives a token identifier. Time claims use NumericDate seconds, so a string such as 2026-05-06 is not the same thing as a valid epoch-second value.

Risk comes from comparing those claims with the token's use. An API access token usually needs a tight lifetime, an issuer, an audience, and authorization context. An OpenID Connect ID token often needs a nonce when the client requested one. A client assertion or refresh-like JWT benefits from a jti because replay, revocation, and incident correlation need a stable token identifier.

Rule Core:

The checker applies a local rule set to decoded header and payload values. The strongest findings are about unexpected algorithms, missing or invalid time claims, issuer or audience mismatch, absent signatures, and readable sensitive data.

Review area Main checks Risk signal
Structure Compact JWT parts, payload JSON, header and payload JSON, and compact JWE detection. Invalid input fails. Five-part JWE inputs are marked as encrypted because claims cannot be inspected without decryption.
Header alg allow-list, alg=none, jku, x5u, suspicious kid, missing kid for asymmetric rotation, and crit. Unsecured or unexpected algorithms fail. Dynamic key URLs and critical headers warn because verifiers must handle them carefully.
Signature boundary Signature segment presence and unsigned-token conditions. A present segment is only informational here. Missing signatures or alg=none become failures when a signed token is expected.
Time claims exp, nbf, iat, clock skew, reference time override, and exp - iat lifetime. Missing, non-numeric, expired, future, or overly long time windows produce Fail or Warn rows depending on the claim and boundary.
Issuer and audience Exact issuer matching, accepted audience list, subject presence, and profile-required claims. Missing or mismatched iss and aud values are high-signal because they decide who should trust the token.
Replay and authorization jti, nonce, scope, scp, roles, permissions, and authorities. Missing replay identifiers warn for profiles that need them. Wildcard, admin, owner, manage, write, delete, and similar grants warn as broad authorization.
Payload exposure Configured sensitive claim terms, secret-like values, personal-data claim names, claim count, byte size, and nested objects. Secret-like claims fail. Personal-data names, bulky payloads, and deeply nested claims warn because signed JWT payloads remain readable.

Profile defaults:

Token use profile Maximum lifetime Required or expected checks
API access token 15 min iss, sub, aud, exp, and iat; scope-like authorization context is expected.
OpenID Connect ID token 60 min iss, sub, aud, exp, and iat; nonce is expected for the ID-token profile.
Refresh-like JWT 10080 min iss, sub, aud, exp, iat, and jti; replay tracking is expected.
Client assertion 5 min iss, sub, aud, exp, iat, and jti; short lifetime and replay resistance matter most.
Browser session JWT 480 min iss, sub, aud, exp, and iat; jti is optional unless you require it.

Score construction:

Each Fail or Warn row subtracts weighted risk points from a 100-point starting score. Critical findings carry 28 points, High carries 18, Medium carries 10, and Low carries 4. A Fail uses the full weight. A Warn uses 60 percent of that weight, rounded to the nearest whole point.

score = clamp ( 100 - risk points , 0 , 100 )
Risk label Rule used here How to read it
Critical claim risk Any Critical Fail, or score below 55. Stop before relying on the token. Fix the failing control and verify signature and key policy separately.
High claim risk Any Fail, or score below 75. Treat the token as unsuitable until the failing claim, header, or timing condition is corrected.
Review claim risk Any Warn, or score below 92. The token may be usable after review, but the warning row names a policy choice or weak assumption to confirm.
Low claim risk No Fail or Warn rows, and score at least 92. The decoded claims fit the configured local checks. Signature, key ownership, revocation, and application authorization still need normal verification.

Everyday Use & Decision Guide:

Start with the Token use profile. It changes the expected lifetime and a few claim expectations, so the same payload can look acceptable as a session token but too long-lived as a client assertion. Use API access token for resource-server checks, OpenID Connect ID token for identity responses, and Client assertion when the token is proving a client to an authorization server.

Fill Allowed algorithms, Expected issuer, and Expected audience before trusting the summary. Blank issuer or audience fields leave the local comparison incomplete, so the checker warns instead of pretending the decoded value is enough. Keep the algorithm list narrow and tied to the verifier's real configuration, such as RS256, ES256, or EdDSA.

Paste a compact JWT, an Authorization: Bearer line, decoded payload JSON, or a JSON object with header and payload. Only the first non-empty line is processed. If a parsing note says extra lines were ignored, trim the source to one token or review each token separately so rows and exports do not mix contexts.

  • Use Maximum lifetime to mirror the policy for this token class. The checker compares exp - iat against that value.
  • Use Clock skew allowance only for the leeway your verifier actually permits around exp, nbf, and iat.
  • Use Reference time override when incident evidence needs to be replayed at a known epoch second instead of the current browser time.
  • Turn on Require replay ID when your environment uses jti for revocation, replay detection, or ticket correlation.
  • Add Sensitive claim terms for organization-specific names that should not appear in readable token payloads.

Read Claim Risk Scorecard first for all controls, then JWT Remediation Queue for only Fail and Warn rows. Claim Inventory Ledger is the decoding reference: it shows each header and payload value, its type, and the local interpretation. The JWT Risk Profile Chart is useful when several categories warn at once and you need to see which area contributes the most risk.

A high score does not mean the token is safe to accept. Use the score to choose what to fix first, then verify the signature, issuer-owned key, audience policy, revocation behavior, and authorization enforcement in the relying party before trusting the token.

Step-by-Step Guide:

Use the summary score for triage, then move into the rows that explain the score.

  1. Enter a Token label that names the API, flow, environment, or ticket. The summary line and structured output use that label for traceability.
  2. Choose Token use profile. Confirm that Maximum lifetime now matches the policy you want to test.
  3. Set Allowed algorithms, Expected issuer, and Expected audience. A missing expected value will appear as a Warn row instead of a clean match.
  4. Paste the JWT, Bearer line, decoded payload JSON, or header-and-payload JSON into JWT or payload JSON. If an error says the source could not be decoded, check dot-separated parts, Base64URL characters, and JSON object shape.
  5. Open Advanced when you need a specific Clock skew allowance, deterministic Reference time override, required jti, or extra sensitive claim terms.
  6. Read the summary score, risk label, and Fail, Warn, Pass, and Claims badges. A Check input summary means the source needs to be fixed before any claim judgment is meaningful.
  7. Open Claim Risk Scorecard and find the first Fail or Warn. The Observed, Evidence, and Recommended action columns explain what changed the score.
  8. Use JWT Remediation Queue for handoff work. It sorts only the rows that need attention, so High and Critical findings do not get hidden by passing checks.
  9. Use Claim Inventory Ledger and JSON to confirm decoded values before copying results into an issue or review note.

Interpreting Results:

The risk label is the fastest stoplight. Critical claim risk and High claim risk mean at least one control should block reliance on the token until it is fixed. Review claim risk means no Fail row may be present, but at least one warning needs context. Low claim risk means the decoded claims fit the configured checks, not that the token has been cryptographically accepted.

Output cue Meaning Follow-up
Algorithm allow-list = Fail The header declares no algorithm, alg=none, or an algorithm outside the entered allow-list. Reject at the verifier unless an approved profile explicitly allows that algorithm.
Expiration claim = Fail exp is missing, invalid, or already expired after the selected skew allowance. Reissue or reject the token. Do not repair trust by raising skew beyond policy.
Issuer claim or Audience claim = Warn The claim may exist, but the expected value was not supplied for local comparison. Enter the relying party's exact issuer and accepted audiences, then rerun.
Sensitive claim exposure = Fail A claim name or value matched secret-like terms such as password, secret, token, or API key. Remove the secret from the readable payload and move confidential data behind a server-side lookup.
Signature verification boundary = Info A signature segment may be present, but this checker did not validate it. Verify signature, issuer key ownership, and algorithm match in the relying party.

The most common false confidence comes from a good-looking decoded payload. Claims are readable by design in a signed JWT, and a copied token can preserve plausible iss, aud, and exp values while still failing signature, key, revocation, or authorization checks elsewhere. Keep the harshest Fail or Warn row in the remediation queue as the next review item.

Worked Examples:

Sample access token with a longer-than-policy lifetime

The loaded sample uses the API access token profile, RS256, issuer https://idp.example.com/, audience orders-api, and a readable scope string with read:orders write:orders. The scorecard passes issuer, audience, subject, and algorithm checks, but Token lifetime warns because exp - iat is 20 minutes while the profile default is 15 minutes. Scope and role breadth also warns because write:orders matches the broad-write pattern. The summary lands in Review claim risk, which is the right cue to shorten the lifetime or confirm the broader write scope before use.

Unsigned token that should not reach a relying party

A compact token with header {"alg":"none"}, a plausible iss, matching aud, and future exp can still be unacceptable. The checker marks Algorithm allow-list as Critical Fail and Signature verification boundary as Critical Fail for the unsecured algorithm. Even if the payload inventory looks tidy, the result becomes Critical claim risk. The fix is not a claim edit. The relying party must reject unsecured JWTs unless a tightly controlled unsecured-token profile protects that exact use.

Payload JSON from an incident note

An incident ticket may contain only decoded payload JSON such as {"iss":"https://idp.example.com/","aud":"orders-api","exp":1770000900,"email":"person@example.com"}. The checker can still build a Claim Inventory Ledger and time-claim rows, but Input format and Signature verification boundary explain that header and signature checks are limited. If Sensitive claim exposure warns on email, the follow-up is to minimize personal data in readable tokens and repeat the review with the original compact JWT when possible.

Encrypted JWE pasted into the source box

A five-part compact JWE is recognized as encrypted. The parsing note says the payload claims cannot be inspected without decryption, the scorecard records an input-format failure, and the claim inventory remains empty. That is a useful troubleshooting result: decrypt in an approved environment, then review the resulting claims rather than treating the encrypted source as a failed JWT decode.

Security Review Note:

This checker is a local claim and header review aid. It does not upload the JWT source text for analysis, and it does not keep a history list. Browser state, copied URLs, downloads, screenshots, and exported records are still under your control, so avoid pasting live bearer tokens unless your review process allows that exposure.

The result should not be used as an authorization decision. A token with Low claim risk still needs normal verifier-side checks for signature, key ownership, accepted algorithm, issuer, audience, revocation, token binding where used, and application authorization. A token with Critical claim risk should be treated as evidence for remediation, not as a full incident conclusion by itself.

FAQ:

Does this verify the JWT signature?

No. It decodes header and payload values, checks claim and header risk, and reports the signature boundary. Signature validation, key lookup, issuer ownership, and revocation checks belong in the relying party.

Which input formats can I paste?

Use a compact JWT, an Authorization: Bearer line, decoded payload JSON, or a JSON object with header and payload. Five-part JWE inputs are detected as encrypted, but their claims are not decoded here.

Why do issuer and audience warn when the token contains values?

Because local matching needs the expected values. If Expected issuer or Expected audience is blank, the checker can show what the token says but cannot prove it matches the relying party you care about.

Why does an ID token profile care about nonce?

OpenID Connect flows can use nonce to bind an ID token response to the original client request. The ID-token profile warns when nonce is missing because that claim often matters for browser-based sign-in flows that requested it.

What should I do with broad scope warnings?

Check the exact scope-like values in Claim Inventory Ledger and the row in JWT Remediation Queue. Values with admin, wildcard, write, delete, manage, owner, or similar wording should be justified by server-side authorization policy, not by the token text alone.

Does the JWT text leave my browser?

The decoding and scoring run in the browser for this checker. Treat pasted tokens as sensitive anyway, because browser history, copied result links, screenshots, and exported records can still expose bearer material or readable claims.

Glossary:

NumericDate
An epoch-second timestamp format used by JWT time claims such as exp, nbf, and iat.
Issuer
The iss claim that identifies the authority that created the token.
Audience
The aud claim that names the intended recipient or recipients for the token.
JWT ID
The jti claim, often used when replay tracking, revocation, or incident correlation needs a stable token identifier.
Nonce
A value used in some OpenID Connect flows to bind the ID token response to the original client request.
JWE
JSON Web Encryption, the encrypted compact form whose claims cannot be inspected without decryption.

References: