JWT Decode Brief
{{ summaryPrimary }}
{{ summaryLine }}
{{ algorithmBadge }} {{ validityBadge }} {{ claimCount }} payload claim(s) Not verified
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
Export to PDF Fullscreen
Customize
Advanced
:

A JSON Web Token, usually shortened to JWT, is a compact way to carry claims between systems. The header describes the token type and signing algorithm, the payload carries claims such as issuer, subject, audience, and expiry, and the signature segment is what a verifier uses to decide whether the token should be trusted.

Decoding is useful because many JWT problems are visible before a verifier runs. An access token might be expired, meant for another API, missing an issuer, using an unexpected algorithm, or carrying readable sensitive data in the payload. Seeing the decoded header and claims helps a developer or reviewer decide what to check next.

Compact JWT parts flow from header to payload to signature, with a reminder that decoding is not verification.

The important boundary is trust. A decoded token is readable, not proven. A signature can be present while still unchecked, an algorithm header can be misleading if code trusts it blindly, and a time-active token can still be rejected by the relying party because the issuer, audience, key, or revocation state does not match policy.

Encrypted JWTs are different. A five-part compact JWE hides its claims behind encryption, so a normal decoder cannot reveal the payload without decryption keys. For signed or unsigned compact JWTs, decoding is a practical inspection step before server-side verification and application policy review.

Technical Details:

JWT inspection starts with compact serialization. A signed JWS-style token commonly has three period-separated parts: protected header, payload, and signature. Each visible part is Base64URL text. The decoded header and payload are UTF-8 JSON objects, while the signature segment is bytes that only become meaningful when a verifier checks them with the right algorithm and key.

Registered JWT claims give the main timing and routing vocabulary. iss names the issuer, sub names the subject, aud names recipients, exp sets the expiration time, nbf blocks use before a not-before time, iat records issue time, and jti gives a token identifier. Time claims use NumericDate seconds from the Unix epoch; strings that merely look like dates do not carry the same meaning.

Base64URL decoding is reversible for readable JWT parts, but it is not decryption. Payload claims in a signed JWT should be treated as visible data. Passwords, client secrets, API keys, and refresh-token-like values do not become safe just because they sit inside a token payload.

Transformation Core:

The decoder turns compact text into structured inspection rows in a fixed sequence. Each stage must succeed before the later claim, timing, and safety checks can be trusted.

Stage Accepted input Output Failure or limit
Source cleanup One compact JWT, or an Authorization: Bearer line. The first non-empty token-like line is selected for decoding. Extra non-empty lines are ignored and shown as a warning.
Part count header.payload or header.payload.signature. Header, payload, and signature rows are prepared. Five-part compact JWE input is rejected because encrypted claims cannot be revealed here.
Base64URL check Characters A-Z, a-z, 0-9, _, and -. URL-safe text is normalized for decoding. Characters outside the alphabet or impossible padding length stop decoding.
JSON decode UTF-8 JSON in the header and payload segments. JSON objects used for the claim ledger and safety checks. Invalid UTF-8, invalid JSON, arrays, and scalar values are rejected.
Signature inspection Optional third segment. Encoded length and decoded byte count. Presence is not cryptographic verification.

Rule Core:

After decoding, the safety notes compare token fields with browser time and optional review inputs. These checks help triage obvious problems, but they do not replace the relying party's verifier.

Check Boundary used here Result meaning
Algorithm header Missing alg or alg=none is called out. The token needs verifier-side algorithm policy before acceptance.
Signature verification A non-empty third segment counts as signature bytes present. The summary still marks the token as not verified.
Expiration With tolerance s, expired means current time minus s is at or after exp. Expired tokens produce a Fail note; missing exp produces a Review note.
Not-before With tolerance s, not active means current time plus s is before nbf. The token may be early, or issuer and verifier clocks may not agree.
Issued-at With tolerance s, future issue means current time plus s is before iat. The output points to clock drift or unexpected issuer timing.
Maximum TTL review When both iat and exp are numeric, lifetime is exp - iat. A configured hour limit produces Pass or Warn rows; zero skips this review.
Issuer and audience Issuer must match exactly. Audience can be a string or array and passes when any expected value is present. Mismatch means the token may belong to another issuer or recipient.
Readable sensitive claims Payload keys resembling passwords, secrets, API keys, private keys, client secrets, or refresh tokens are flagged. Signed JWT payloads are readable after decoding, so secret-like claims need removal or encryption.

Registered claim map:

Claim Meaning Review cue
iss Issuer Compare with the expected issuer value for the environment.
sub Subject Use it to identify the user, client, or principal described by the token.
aud Audience Confirm the intended API, client, or relying party is listed.
exp Expiration time Check whether the browser clock sees the token as active or expired.
nbf Not-before time Use it to explain tokens that fail before their start time.
iat Issued-at time Compare with exp for token lifetime and future-clock warnings.
jti JWT ID Useful for replay review, incident notes, and token traceability.

Everyday Use & Decision Guide:

Start with one token. Paste a compact JWT or a full Authorization: Bearer line into JWT, or use Browse JWT for a small text file. The decoder reads the first non-empty line only; if the warning says extra lines were ignored, split the sample and inspect each token separately.

Use Expected issuer and Expected audience when you know the relying party's policy. Leaving them blank is fine for a first look, but it also means the safety notes cannot tell you whether iss or aud matches the application you are debugging. Use comma-separated audience values when more than one recipient is acceptable.

Set Clock tolerance only when the verifier really allows clock skew around exp, nbf, and iat. A generous tolerance can make a borderline token look acceptable during inspection even though production verification may be stricter. Use Maximum TTL review when policy limits token lifetime from issue time to expiration time.

  • Use Token Parts to confirm the compact structure, decoded byte counts, and signature segment status.
  • Use Claim Ledger to read every header parameter and payload claim with value type and notes.
  • Use Validity Timeline when iat, nbf, or exp need a quick time comparison.
  • Use Safety Notes for the findings that should slow a handoff, such as missing signatures, expired timing, issuer mismatch, or readable secret-like claims.
  • Use JSON when another reviewer needs the decoded structure and the explicit signature_verified state.

A good fit is debugging a token sample, preparing an issue note, or comparing what an identity provider issued against what an API expects. A poor fit is deciding that a bearer token is valid for access; that decision belongs in verifier code with trusted keys, issuer and audience policy, clock rules, and revocation handling.

Step-by-Step Guide:

Work from structure to claims, then from timing to trust warnings.

  1. Paste a compact token into JWT, paste an Authorization: Bearer line, choose Browse JWT, or select Load sample. A valid source shows JWT Decode Brief; an empty source asks you to paste a JWT before decoding.
  2. Open Advanced and enter Expected issuer, Expected audience, Clock tolerance, or Maximum TTL review only when those values match the system you are checking.
  3. Read the summary badges. Confirm the algorithm badge, validity badge, payload claim count, and the persistent Not verified badge before moving to detailed rows.
  4. Open Token Parts. Check that Header and Payload show JSON object, then read the Signature row for Present, Empty, or Missing.
  5. Open Claim Ledger. Review header parameters such as alg, typ, and kid, then check payload claims such as iss, sub, aud, iat, nbf, and exp.
  6. Open Validity Timeline when timing claims are present. If the chart says there are no NumericDate claims, return to Claim Ledger and check whether the timing values are missing or not numeric.
  7. Open Safety Notes and handle any Fail, Warn, or Review row before sharing the token analysis. The Next step column names the follow-up check.
  8. If decoding fails, fix the source format first: use two or three compact parts, remove unsupported characters, avoid five-part JWE input, and make sure the header and payload decode to JSON objects.

Interpreting Results:

The first result to trust is the warning that signatures are not verified. Time-active means the browser clock and optional tolerance did not find an expiration, not-before, or future-issued problem. It does not mean the token came from the right issuer, was signed with the right key, or should be accepted by an API.

Expired, Not active yet, Future iat, and No exp are timing interpretations, not full policy decisions. Use the Validity Timeline and Claim Ledger together so you can see both the UTC value and the raw claim that produced it.

Output cue Meaning Follow-up
Not verified The signature has not been cryptographically checked. Verify signature, key, issuer, audience, and clock claims in the relying party.
Signature verification Safety note for present, missing, or unusable signature bytes. Treat present bytes as inspect-only until server-side verification succeeds.
Issuer comparison Exact comparison between iss and Expected issuer. Reject or route the token to the correct issuer configuration when it warns.
Audience comparison Checks whether any expected value appears in aud. Confirm the API or client that will process the token is actually listed.
Readable sensitive claims A payload key resembles secret-bearing data. Remove the value from signed JWT payloads or use encrypted token handling.

The best corrective check is external to the decoded view: run the token through the same verifier, key source, issuer policy, audience policy, and lifetime rules that production uses. Use the decoded rows to explain why a token looks suspicious, not to bypass verification.

Worked Examples:

Signed access-token sample. A compact three-part token has header alg=RS256 and typ=JWT, payload iss=https://auth.example.com, sub=user_123, aud=api://orders, iat=1767225600, exp=1893456000, and a non-empty signature segment. With Expected issuer set to https://auth.example.com and Expected audience set to api://orders, JWT Decode Brief shows a future expiration, Token Parts shows Signature Present, and Safety Notes still includes Signature verification as Review because the signature bytes are not checked here.

Expired two-part debug token. A token with header alg=none, payload iss=https://auth.example.com, sub=tester, aud=api://orders, and exp=1704067200 decodes, but JWT Decode Brief reports an expired token. Token Parts shows Signature Missing, and Safety Notes flags Algorithm header, Signature verification, and Expiration. That is useful for a fixture or test note, but it should not be treated as an acceptable bearer token.

Issuer mismatch during API debugging. A three-part token lists iss=https://login.example.net and aud=["api://orders","api://reports"]. If Expected issuer is https://auth.example.com and Expected audience is api://orders, Safety Notes warns on Issuer comparison while audience passes. The decoded token may belong to a different environment even though the audience includes the API.

Encrypted or malformed source. A five-part compact JWE such as part1.part2.part3.part4.part5 fails with the encrypted-payload message because claims cannot be revealed without keys. A source with two pasted tokens on separate lines decodes only the first and shows the extra-line warning, so the corrective path is to inspect one compact token at a time.

FAQ:

Does this verify the JWT signature?

No. The output always marks the token as not verified. A signature segment can be decoded and counted, but trust requires verifier code with the correct algorithm, trusted key source, issuer, audience, clock rules, and revocation policy.

Why does a five-part token fail?

Five compact parts indicate JWE-style encrypted content. The decoder can inspect signed or unsigned compact JWT parts, but encrypted claims cannot be revealed without decryption keys.

What does the extra-line warning mean?

Only the first non-empty line is processed. If you pasted several tokens, split them and decode one at a time so Claim Ledger, Safety Notes, and JSON all describe the same token.

How should clock tolerance be set?

Use the same tolerance your verifier allows, in seconds. The value affects exp, nbf, and iat review, so a larger value can hide a boundary timing problem that a stricter verifier would reject.

Is it safe to paste a production bearer token?

The token text and local file content are decoded in the browser and the tool has no JWT upload endpoint, but bearer tokens are credentials. Avoid pasting live tokens on shared devices, and rotate any token that may have been exposed.

Glossary:

JWT
A JSON Web Token, a compact token carrying header data, claims, and sometimes a signature.
JWS
JSON Web Signature, the signed compact structure commonly seen as header, payload, and signature.
JWE
JSON Web Encryption, an encrypted token form whose compact version has five parts.
JOSE header
The JSON header that names token type, algorithm, key hints, and related parameters.
Claim
A name and value inside the payload, such as iss, aud, or exp.
Base64URL
The URL-safe text encoding used for compact JWT parts.
NumericDate
A JWT time value expressed as seconds from the Unix epoch.
Bearer token
A credential presented by whoever holds it, commonly sent in an HTTP authorization header.

References: