JWT Decoder

If you paste something with five dot-separated segments, that is a JWE — an encrypted token whose payload cannot be read at all without the decryption key. This tool will tell you so rather than producing nonsense. Two segments with an empty third means an unsigned token, which is a red flag on anything that matters.

The registered claims

All three time claims are NumericDate: seconds since 1970-01-01 UTC, not milliseconds. This trips people up constantly, because JavaScript's Date.now() returns milliseconds. Signing a token with exp: Date.now() + 3600000 produces a token that expires in about the year 56,000; signing with a millisecond value where seconds are expected fails validation immediately on some libraries and passes absurdly on others. This decoder interprets them as seconds, per RFC 7519 §2, and shows both the local time and the ISO form so a wrong-by-1000 value is immediately obvious.

A missing exp deserves attention. A token with no expiry is valid forever unless the issuer maintains a revocation list — and the main appeal of JWTs is that they are stateless, meaning most issuers do not. That combination is how a leaked token stays useful for years.

Reading the alg field

HS256 is HMAC-SHA-256: one shared secret both signs and verifies. Fine when a single service issues and consumes its own tokens; unworkable when you need to distribute verification, because every verifier would also be able to mint tokens. RS256 and ES256 are asymmetric — the issuer signs with a private key and anyone can verify with the public key, which is what OIDC providers publish at a JWKS endpoint.

alg: "none" means the token asserts it is unsigned. It exists in the specification for tokens whose integrity is guaranteed by other means, and it has been the basis of a long series of real vulnerabilities: a library that reads the algorithm from the header and dispatches on it will happily "verify" a none token that an attacker rewrote. The related attack swaps RS256 for HS256 and signs with the *public* key as the HMAC secret. The defence for both is the same — the verifier must pin the algorithm it expects and refuse anything else, never trust the header to choose.

This tool flags alg: none explicitly because seeing it in a token from a production system is worth investigating immediately.

Verifying properly, on the command line

Decoding is a one-liner. Verification needs the key, and is worth doing with a real library rather than by hand — but the manual HMAC check below is instructive because it shows exactly what the signature covers.

JWT='eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature'

# Decode the header and payload (base64url -> base64, then decode)
echo "$JWT" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null | jq .
echo "$JWT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | jq .

# Is it expired? Compare exp against now, in seconds
echo "$JWT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null \
  | jq --argjson now "$(date +%s)" '{exp, now: $now, expired: (.exp < $now)}'

# Verify an HS256 signature by hand — the input is header.payload, verbatim
SIGNING_INPUT=$(echo "$JWT" | cut -d. -f1,2)
printf '%s' "$SIGNING_INPUT" \
  | openssl dgst -binary -sha256 -hmac 'your-shared-secret' \
  | openssl base64 -A | tr '+/' '-_' | tr -d '='
# Compare that to: echo "$JWT" | cut -d. -f3

# Fetch an issuer's public keys for RS256/ES256 verification
curl -s https://accounts.google.com/.well-known/openid-configuration | jq -r .jwks_uri
curl -s "$(curl -s https://accounts.google.com/.well-known/openid-configuration | jq -r .jwks_uri)" | jq .

Note that the signing input is the raw header.payload string exactly as it appears in the token — not a re-encoding of the decoded JSON. Re-serialising the payload changes key order and whitespace and produces a different signature, which is why verification must operate on the original bytes.

A verifier's checklist

• Pin the expected algorithm. Never dispatch on the token's own alg header.
• Verify the signature before reading any claim. A payload from an unverified token is attacker-controlled input.
• Check exp and nbf, with a small clock-skew allowance (60 seconds is conventional).
• Check iss against the exact issuer you expect, and aud against your own service identifier. A valid token for a different audience is not a valid token for you.
• For asymmetric tokens, fetch keys from the issuer's JWKS endpoint and match on kid. Cache them, and handle key rotation — a hardcoded public key becomes an outage on rotation day.
• Keep token lifetimes short. Statelessness means you generally cannot revoke, so expiry is your only real control.
• Store tokens where XSS cannot read them where possible. localStorage is readable by any script on the page; an HttpOnly cookie is not.

If a token in your hands is failing verification and you cannot see why, decode it here first. Roughly half of all JWT bugs turn out to be visible in the payload alone: a millisecond exp, an aud naming a different environment, an iss pointing at the staging tenant, or a kid referring to a key that was rotated out. The other half are clock skew and a mismatched secret.