{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ algorithmBadge }} {{ validityBadge }} Not verified

Use one two- or three-part compact token. Five-part encrypted JWE content needs decryption keys and is not decoded here.
{{ sourceStatus || 'Drop a TXT or JWT file onto the textarea; maximum 256 KiB.' }}
Only the first non-empty line was decoded; {{ ignoredLineCount }} extra line{{ ignoredLineCount === 1 ? '' : 's' }} ignored.
Blank skips issuer comparison and leaves the decoded claims unchanged.
Use one value or a comma-separated list. A match to any configured value passes this local comparison.
Zero uses the exact review time. This setting cannot prove what another verifier accepts.
sec
This comparison applies only when both numeric iat and exp claims are present.
hours
SourceNameTypeValueReviewCopy
{{ row.source }}{{ row.name }}{{ row.type }}{{ row.value }}{{ row.review }}

{{ ledgerExportStatus }}

SignalCheckEvidenceNext stepCopy
{{ row.severity }}{{ row.check }}{{ row.evidence }}{{ row.next_step }}

{{ reviewExportStatus }}

{{ chartExportStatus }}

{{ workflowAnnouncement }}

JWT Claims Risk Checker Check JWT headers and claims against issuer, audience, time, algorithm, replay, exposure, and token-profile rules without uploading the token.
Base64 Encoder and Decoder Encode or decode Base64 text and files locally, choose standard or URL-safe output, repair missing padding, and inspect the recovered bytes.
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.
HTML Unescaper Decode escaped HTML text or small local files with multi-pass reference tracking plus strict review, Unicode normalization, and safety signals.

A JSON Web Token can be readable without being trustworthy. Compact JWTs carry claims in period-separated Base64URL segments, so decoding can expose the header and payload without a key. Acceptance requires a separate cryptographic and policy decision.

Signed tokens commonly use three parts: a JOSE header, a claims payload, and signature bytes. The header may name an algorithm or key identifier. The payload may contain an issuer, subject, audience, expiry, activation time, issue time, token identifier, roles, scopes, or private application claims. None of those statements become true merely because the JSON parses.

Decoding
Turns Base64URL text into readable UTF-8 JSON and raw signature bytes.
Verification
Checks the cryptographic protection with a trusted key and an allowed algorithm.
Validation
Applies issuer, audience, time, token type, and application-specific rules.

Time claims use NumericDate values: seconds since 1970-01-01T00:00:00Z, ignoring leap seconds. exp limits use after expiry, nbf delays use until a stated time, and iat records when the token was issued. Clock tolerance can explain small differences between systems, but a large skew setting can also hide a real clock or token-lifetime problem.

JWT payloads are not secret by default. Access tokens copied into tickets, chat, logs, or screenshots may disclose names, identifiers, roles, internal hosts, or credentials stored in custom claims. Encryption uses JSON Web Encryption (JWE), whose compact form has five parts and requires decryption keys.

How to Use This Tool:

Use the decoder to inspect one token, then verify it in the system that actually makes the authorization decision.

  1. Paste one compact JWT, an Authorization: Bearer line, or load one TXT or JWT file under JWT source. Only the first non-empty line is decoded; remove extra lines when the warning appears.
  2. Open Advanced to compare iss and aud with values from trusted relying-party configuration. A blank field skips that comparison.
  3. Set Clock skew only when the verifier's allowed tolerance is known. Set Maximum TTL review when policy limits the time between numeric iat and exp.
  4. Read Decoded ledger for header and claim values, then inspect every Security review row. Use Validity timeline to compare the review time with numeric iat, nbf, and exp.

Interpreting Results:

The summary describes only local decoding and time review. Time-active means a numeric expiry is later than the adjusted review boundary; it does not mean the signature, issuer, audience, token type, or authorization scope is valid. No exp means there is no numeric expiry to assess, not that the token has an unlimited safe lifetime.

Pass rows confirm only the configured local comparison. Review and Fail rows identify missing protection, timing problems, policy mismatches, critical headers, or sensitive-looking claims. The persistent Not verified badge is decisive: do not accept the token until the relying party verifies the exact signing input with trusted configuration.

An algorithm name inside the header is input supplied by the token. It must not choose its own trusted verification method or key. Issuer and audience values should also come from application configuration, not from the token being inspected.

Technical Details:

Compact JWS-style input has either two parts, header.payload, or three parts, header.payload.signature. Header and payload must be unpadded Base64URL text that decodes as UTF-8 and then as JSON objects. A five-part compact value is recognized as JWE and rejected because encrypted content cannot be recovered without keys.

Transformation Core:

  1. Trim the source, keep the first non-empty line, and remove optional authorization and bearer prefixes.
  2. Split on periods and validate the two- or three-part shape.
  3. Translate Base64URL characters, restore temporary padding internally, decode bytes as UTF-8, and require object-shaped JSON for header and payload.
  4. List the compact segments, sorted header fields, sorted claims, decoded byte counts, and UTC forms of numeric time claims.
  5. Apply local time and policy rules without performing a cryptographic operation.

Rule Core:

Timing checks run in a fixed order. Let t be review time, s be allowed clock skew in seconds, and claim values be NumericDate seconds.

ConditionLocal result
t − s ≥ expExpired
Otherwise, t + s < nbfNot active yet
Otherwise, t + s < iatIssued in future
Otherwise, numeric exp existsTime-active
No numeric expNo exp

Issuer comparison is an exact string match. Audience input may be a comma-separated list, and the check passes when any configured value exactly matches the token's string audience or one member of its audience array. Maximum TTL applies only when both iat and exp are numeric: a negative lifetime fails, a lifetime greater than the configured limit receives review, and an equal or shorter lifetime passes.

The review also flags a missing or none algorithm, absent or unverified signature bytes, listed critical headers, and claim names resembling passwords, secrets, API keys, private keys, client secrets, or refresh tokens. These are focused heuristics rather than a complete JWT security policy.

Source input is limited to 256 KiB. Clock skew accepts 0 to 86,400 whole seconds. Maximum TTL accepts 0 to 87,600 hours, with zero disabling that comparison. The review time is captured from the browser clock in whole epoch seconds.

Privacy and Security Notes:

Token text is decoded in the browser and is not sent for verification. Local handling avoids uploading the token through this workflow, but the decoded claims remain visible on screen and in any copied or downloaded report.

  • Never paste a production token into an untrusted page, message, ticket, or shared screen.
  • Do not infer secrecy from a signature. Signed JWT payloads remain readable.
  • Do not treat claim values, algorithm names, key identifiers, or URLs in the token as trusted configuration.
  • Use a maintained verifier that enforces allowed algorithms, cryptographic validity, issuer, audience, and application rules.

Worked Examples:

Readable token with a signature segment

A three-part token may decode to an HS256 header and an exp claim 30 minutes after the review time. The local timing result is Time-active, while signature review remains Review because the presence of signature bytes is not verification. The correct next step is to validate the original compact token with the intended key, allowed algorithm, issuer, and audience.

References: