Use header.payload.signature form; signed, unsigned, and Bearer-prefixed tokens are accepted for local inspection.
{{ fileStatus || 'Drop TXT or JWT onto the textarea.' }}
Example: https://auth.example.com. Blank keeps the decoder in inspect-only mode.
Use one value or a comma-separated list; blank skips audience comparison.
Set only when comparing against systems that allow clock skew.
sec
Set hours only when your policy has a known maximum JWT lifetime.
hours
Segment Encoded chars Decoded bytes Status Note Copy
{{ row.segment }} {{ row.encodedChars }} {{ row.decodedBytes }} {{ row.status }} {{ row.note }}
Claim Location Type Value Note Copy
{{ row.claim }} {{ row.location }} {{ row.type }} {{ row.value }} {{ row.note }}
Severity Check Evidence Next step Copy
{{ row.severity }} {{ row.check }} {{ row.evidence }} {{ row.nextStep }}
Tags: Devtools, Encoding, Security
JWT Claims Risk Checker Check JWT claims and headers for issuer, audience, time, algorithm, replay, and sensitive-data risks before relying on a token in an API.
Base64 Encoder and Decoder Encode or decode Base64 text and files in your browser, inspect recovered bytes, repair padding, and create URL-safe or Data URL output.
SAML Assertion Timing Checker Review SAML assertion timing from XML, SAMLResponse, or OAuth assertion captures with skew, bearer-expiry, replay-cache, and session evidence.
HTML Unescaper Decode escaped HTML text or small files in your browser, inspect each entity change, and flag unresolved references or script-shaped output.
Customize
Advanced
:

JSON Web Tokens carry identity and authorization claims in a compact text format that fits cleanly into headers, cookies, links, logs, and API debugging sessions. Their short shape can make them look opaque, but a signed JWT usually contains two readable JSON objects before the signature segment.

In everyday API work, the same token may pass through a browser, reverse proxy, mobile app, server log, support ticket, or command-line request. Decoding helps explain what that compact value says, but the surrounding system still decides whether the token should be accepted. A copied staging token, a clock that is several minutes out, a wrong audience value, or an issuer mismatch can break a request even when the payload looks familiar.

The first object is the JOSE header. It names details such as the signing algorithm, token type, and sometimes a key identifier. The second object is the claims payload. That payload can include registered claims such as issuer, subject, audience, expiration, not-before time, issued-at time, and JWT ID, along with application-specific claims such as roles, tenant IDs, scopes, email addresses, or feature flags.

Header
Metadata about how the token is supposed to be processed, including values such as alg, typ, and kid.
Payload
The claim set. It is readable after Base64URL decoding unless the token is encrypted.
Signature
Bytes that can prove integrity only when checked with the trusted algorithm, key, issuer, audience, and application policy.
  • Issuer: which authority created the token and which configuration should verify it.
  • Audience: which API, resource, or client the token is meant for.
  • Time window: when the token starts, expires, and how much clock tolerance the relying party allows.
  • Signature policy: which algorithm and key are trusted by the verifier, not merely named by the token.

A common mistake is treating decoding as proof. Decoding a JWT only turns compact text back into readable JSON. Trust still depends on cryptographic verification and policy checks performed by the relying system. A token that says it belongs to a user, a tenant, or an API is only useful evidence after the signature, issuer, audience, clock window, replay controls, and authorization rules all pass.

JWT compact token anatomy with readable header and payload segments separated from signature verification.

Timing claims are another common source of confusion. exp, nbf, and iat use NumericDate seconds, not local date strings. They also depend on clock policy: some systems allow a small skew, while others reject a token exactly at the boundary.

JWT payloads are not private by default. Signed tokens protect integrity, not confidentiality. Anyone who receives a compact signed token can decode the header and payload, so sensitive secrets belong in encrypted tokens or server-side storage rather than ordinary readable claims.

How to Use This Tool:

Use the decoder for inspection and triage. It helps you see what the token says before you test the same token in the system that must verify and authorize it.

  1. Paste one compact token into JWT. A plain header.payload.signature token, a two-part unsigned form, or an Authorization: Bearer line can be inspected.
  2. Use Browse JWT or drag in a small text/JWT file only when you are allowed to inspect that token. Files over 256 KB are rejected, and multi-line input uses the first non-empty line with a warning.
  3. Open Advanced when you know the expected relying-party values. Expected issuer compares exactly with iss; Expected audience accepts one value or a comma-separated list.
  4. Set Clock skew only when the verifier intentionally allows tolerance around exp, nbf, or iat. Leave it at zero when you want an exact browser-clock review.
  5. Set Maximum TTL review when policy has a known lifetime limit from iat to exp. Use zero to skip that lifetime warning.
  6. Read Token Parts first, then move through Claim Ledger, Validity Timeline, Safety Notes, and JSON for deeper review or export.

If the token fails to decode, strip surrounding log text and keep one compact value. The header and payload must be Base64URL-encoded JSON objects, and encrypted five-part compact tokens cannot reveal payload claims here.

Interpreting Results:

The summary tells you how the visible time claims compare with the current browser clock after any configured skew. Time-active means the local time check is inside the decoded window. Expired, Not active yet, Future iat, and No exp all point to issues that need policy review before anyone relies on the token.

The Not verified badge is intentional. Signature bytes may be present, but the decoder does not choose keys, validate signatures, check revocation, enforce algorithm policy, or decide authorization. Treat decoded claims as untrusted text until the relying party accepts the token.

Result area Useful signal Do not overread
Token Parts Segment count, encoded length, decoded byte count, JSON status, and signature-segment presence. A present signature segment does not prove that the signature matches a trusted key.
Claim Ledger Header parameters and payload claims with readable values, types, labels, and UTC conversions for time claims. Custom claims can use local meanings, so confirm them against the issuer and application contract.
Validity Timeline A chart of numeric iat, nbf, and exp claims relative to now. The chart uses decoded values and the browser clock; the verifier's clock and skew policy may differ.
Safety Notes Warnings for missing or unusual algorithm data, unverified signatures, expiration state, issuer/audience comparisons, TTL review, critical headers, and sensitive-looking claim names. These notes are local review hints, not a complete security decision.

A decoded token can be readable, time-active, and still unusable. Wrong audience, wrong issuer, rejected algorithm, failed signature, revoked credentials, missing permissions, or leaked sensitive claims can all matter more than the decoded expiration alone.

Technical Details:

A signed compact JWT is usually a JSON Web Signature in compact form. The compact form joins Base64URL-encoded protected header, payload, and signature values with periods. Base64URL decoding makes the first two segments readable when they contain JSON, but signature verification requires the exact signing input, accepted algorithm, trusted key material, and verifier policy.

An encrypted compact token follows the JSON Web Encryption shape instead. It has five Base64URL segments: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. Without decryption keys, the claims are not available, so a decoder should stop instead of pretending the ciphertext is a readable payload.

Structure Core:

Compact shape Meaning Readable without keys
header.payload.signature Signed or MAC-protected content in compact JWS form. Header and payload are readable JSON when validly encoded; signature must be verified separately.
header.payload Unsigned inspection form or incomplete compact token. Header and payload may decode, but there are no signature bytes to trust.
header.key.iv.ciphertext.tag Encrypted compact JWE form. Only the structure is recognizable without decryption; payload claims remain hidden.

Transformation Core:

The inspection path is deterministic: isolate one compact token-shaped string, split on periods, decode Base64URL segments, parse JSON where required, then apply local claim checks. Each step can fail independently, which is why a malformed header, non-JSON payload, invalid Base64URL padding length, or encrypted compact shape gets a different failure reason.

Stage Rule Result produced
Source cleanup Use the first non-empty line, remove an optional authorization label, and inspect the compact token-like value. Extra-line warning when pasted logs or files contain more than one non-empty line.
Segment review Accept two or three segments for inspection and reject five-part encrypted compact form as unreadable without keys. Token part rows for header, payload, and signature status.
Base64URL and JSON Normalize URL-safe characters, decode to UTF-8, and parse the header and payload as JSON objects. Readable header parameters and payload claims.
Claim review Label registered claims, convert NumericDate values, compare optional issuer and audience values, and scan sensitive-looking payload keys. Claim ledger, timeline data, and safety notes.

Formula Core:

JWT time claims use NumericDate seconds from 1970-01-01T00:00:00Z UTC. Local timing review compares those seconds with the current browser time and the optional clock-skew tolerance.

expires in = exp-now starts in = nbf-now TTL hours = exp-iat3600

Expiration is flagged when now - skew >= exp. A not-before claim is still in the future when now + skew < nbf. An issued-at claim is treated as future-dated when now + skew < iat.

Rule Core:

Signal Local rule Security boundary
Algorithm header Missing alg or alg=none receives a warning. Other values are reported as information. The verifier must decide which algorithms are accepted and must not trust the token header alone.
Signature Present signature bytes receive review status because they are not checked. Missing or empty signature bytes receive warning status. Cryptographic verification belongs in the relying party or a verifier configured with trusted keys.
Expiration window exp, nbf, and iat are compared against the browser clock with optional skew. Time-active does not prove the issuer, audience, signature, replay state, or permissions.
Issuer and audience Configured expected values are compared exactly with iss and one or more aud values. Mismatches usually mean the token belongs to another issuer, client, API, tenant, or environment.
Token lifetime When iat and exp are numeric, the lifetime can be checked against the configured maximum TTL. Long-lived tokens increase exposure if copied, logged, or leaked.
Readable sensitive claims Payload keys that look like passwords, secrets, API keys, private keys, client secrets, or refresh tokens receive warnings. Signed JWT payloads are readable; confidential values need encryption or server-side storage.

The main boundary is readability versus acceptance. Decoding can explain the token's visible contents and timing, but only verifier-side policy can prove that a token is authentic, intended for the current service, still valid, unreplayed, and authorized for the requested action.

Privacy Notes:

The token text and browsed file contents are decoded in the browser. The decoder does not send the token to a remote signature validator or issuer lookup.

  • JWT payloads can expose names, email addresses, roles, tenant IDs, internal identifiers, session clues, or application-specific permissions.
  • Do not paste production tokens into tickets, screenshots, chat messages, or shared reports unless they have been revoked or carefully redacted.
  • Local inspection is useful for debugging, but the relying party remains authoritative for signature checks, issuer and audience policy, clock handling, replay controls, and permissions.

Worked Examples:

Access token with a short lifetime

A token with alg set to RS256, iss set to an authorization server hostname, aud set to orders-api, and an exp value 12 minutes from now can show Time-active. The Safety Notes row for signature verification still requires a server-side verifier before the API should trust the claims.

Staging token sent to production

If Expected audience is billing-api but the payload contains aud as orders-api, the claim ledger shows the decoded value and the safety notes warn on the audience comparison. That usually points to client configuration, copied credentials, or a request aimed at the wrong service.

Expired support-ticket token

A pasted Authorization: Bearer line with exp one hour in the past decodes, but the summary reports Expired and the timeline places expiration before now. Ask for a fresh token before investigating permissions or custom claims.

Encrypted compact token

A five-part compact value is treated as encrypted content. The correct result is an unreadable-payload message because JWE ciphertext cannot be decoded into claims without decryption keys.

FAQ:

Does a decoded JWT mean the signature is valid?

No. Decoding only reveals readable header and payload content. Signature verification needs trusted keys, accepted algorithms, issuer and audience policy, and server-side validation.

Why does the token still say not verified when it has a signature?

A signature segment can be decoded as bytes without proving those bytes match a trusted key. Use the relying party or a properly configured verifier for that step.

Why are extra lines ignored?

JWT inspection works on one compact token at a time. When pasted logs contain several lines, only the first non-empty line is decoded and the rest are flagged as ignored.

Can encrypted JWTs be decoded here?

No. Five-part compact encrypted tokens need decryption keys before the payload claims can be read.

Why do some claims appear as dates?

exp, nbf, and iat are NumericDate seconds. The claim ledger converts numeric values in those fields to UTC and relative timing for easier review.

Glossary:

JWT
JSON Web Token, a compact claims format often used with signed or encrypted JOSE structures.
JOSE header
The header object that can name the token type, algorithm, key identifier, and critical processing parameters.
Claim
A name/value assertion in the payload, such as issuer, subject, audience, role, scope, or expiration.
NumericDate
A time value expressed as seconds from 1970-01-01T00:00:00Z UTC.
Audience
The intended recipient, resource, or service that should accept the token.
JWS
JSON Web Signature, the JOSE format commonly used for signed compact JWTs.
JWE
JSON Web Encryption, the JOSE format for encrypted content whose payload is not readable without decryption.

References: