ZeroTrace OSINT
JWT Decoder
Parse JWT tokens, verify signatures against pasted keys or fetched JWK Sets, surface alg-confusion warnings.
The JWT decoder takes a JSON Web Token, parses the three parts (header / payload / signature), and surfaces every claim with annotations from a built-in claims glossary. Optionally it verifies the signature against a pasted public key or against a JWK Set fetched from the issuer's .well-known/jwks.json.
What you get
For any JWT:
| Section | What it shows |
|---|---|
| Header | alg, typ, kid, custom header fields |
| Payload (claims) | Every claim with annotations from the standard JWT claims registry |
| Signature | Raw signature bytes, base64url-encoded |
| Token validity window | iat, nbf, exp with freshness chip |
| Standard-claim glossary | iss, sub, aud, jti, iat, exp, nbf annotated automatically |
| Custom claims | Surfaced as-is (no annotation; you interpret them) |
| Signature verification | Optional: verify against pasted public key or fetched JWK Set |
| Algorithm confusion warning | Flag if alg is unusual or asymmetric algorithm with key size that fits a symmetric secret |
Standard-claim glossary
The decoder annotates the canonical claims:
| Claim | Meaning |
|---|---|
iss | Issuer, who created the token |
sub | Subject, who the token is about |
aud | Audience, who the token is for |
exp | Expiry, when the token stops being valid |
nbf | Not before, when the token starts being valid |
iat | Issued at, when the token was created |
jti | Unique token ID, for revocation |
Custom claims (anything not in the standard registry) are surfaced as-is.
Validity window
The decoder evaluates the token against the current time:
iat(issued at), when the token was created.nbf(not before), when the token starts being usable.exp(expiry), when the token stops being valid.
A token currently outside its validity window is flagged.
Signature verification
Two verification modes:
| Mode | When to use |
|---|---|
| Paste public key | You have the issuer's PEM-encoded public key |
| Fetch JWK Set | You have the issuer's URL, the decoder fetches <issuer>/.well-known/jwks.json and finds the matching key by kid |
Verification supports the common JWT algorithm families: HS256/384/512 (HMAC), RS256/384/512 (RSA), ES256/384/512 (ECDSA), PS256/384/512 (RSA-PSS), EdDSA.
A successful verification confirms:
- The token was signed by the holder of the corresponding key.
- The token has not been modified since signing.
A failed verification means one or the other is false. The decoder tells you which.
Signature verification confirms the token was signed by some key, it does not by itself prove the token is "valid." A token signed by an attacker-controlled key passes verification with that attacker's key. Always verify against a key you trust came from the legitimate issuer.
Algorithm confusion warning
A classic JWT vulnerability: a server expects RS256 but accepts HS256 with the public key as the symmetric secret. The decoder flags this when:
- The token's
algis symmetric (HS256/384/512). - The token's key looks like it could be a public key (PEM-shaped).
This is a sanity check, not a verdict, many legitimate setups use symmetric keys. But the warning catches the misconfiguration that the most common JWT bypass exploits.
None-algorithm warning
A token with alg: none is unsigned. The decoder flags this prominently, accepting alg: none is the other classic JWT vulnerability.
Pivots
| Click on... | Pivot to |
|---|---|
iss URL | URL parser, site analysis |
aud URL | URL parser |
| Custom URL claim | URL parser |
| Email-shaped claim | Email analyzer |
Bulk JWT decode
Bulk paste accepts many tokens. Aggregate table shows per-token issuer / subject / expiry / valid-now status, useful for triaging a log file full of tokens.
Sources
- All decoding is local.
- JWK Set fetches go to the URL you provide, the URL is named on the result.