How to Decode a JWT Without Trusting It

A JWT is readable by anyone, so decoding proves nothing. See its three parts, the claims worth reading, and what verification must check before you trust it.

A JSON Web Token looks opaque, but its first two parts are just Base64URL-encoded JSON. Decoding one takes seconds, and that is exactly why decoding must never be mistaken for checking that a token is genuine.

Paste a token into the decoder below to read its header, payload and expiry. It runs entirely in your browser, so the token is not sent anywhere.

JWT DecoderPaste a JWT to read its header and payload and see when it expires. Decoding happens entirely in your browser, so the token never leaves your device.

The three parts

A JWT is three Base64URL strings separated by dots:

header.payload.signature
PartContainsExample
HeaderThe signing algorithm and token type{"alg":"HS256","typ":"JWT"}
PayloadThe claims: who, what and until when{"sub":"1234","exp":1893456000}
SignatureA MAC or signature over the first two partsBinary, shown as Base64URL

Because the header and payload are only encoded, anyone who holds the token can read them. Never put passwords, secrets or sensitive personal data in a JWT payload.

Claims worth reading

ClaimMeaning
issIssuer: who created the token
subSubject: who the token is about
audAudience: who the token is meant for
expExpiry, as seconds since the Unix epoch
nbfNot before: the token is invalid until this time
iatIssued at

Time claims are Unix timestamps in seconds, not milliseconds. If a token seems to expire in the year 50,000, something encoded milliseconds by mistake.

Decoding is not verifying

Decoding tells you what the token claims. Verification tells you whether those claims are authentic. A forged token decodes just as cleanly as a real one.

Before trusting a token, a server must:

  1. Verify the signature with the correct key (the shared secret for HS256, the issuer's public key for RS256 and similar).
  2. Pin the algorithm it expects, instead of trusting the alg value in the token's own header. Accepting none, or letting the token choose between symmetric and asymmetric algorithms, has caused real vulnerabilities.
  3. Check exp and nbf against the current time, allowing a small clock skew.
  4. Check iss and aud match what your application expects.

Debugging a rejected token

  • Expired: compare exp with the current time. The decoder shows the expiry in a readable form.
  • Wrong audience or issuer: the token was minted for a different service or environment.
  • Signature invalid: the key differs between the issuer and verifier, or the token was altered or re-encoded.
  • Malformed: it does not have exactly three dot-separated parts, or a part is not valid Base64URL. The Base64 guide explains that encoding.

Creating test tokens

When building or testing an API you often need a token with specific claims. The generator signs one locally with a secret you provide. Use throwaway secrets for testing, never production keys.

JWT GeneratorBuild a JWT payload, pick an algorithm and sign it with your secret. Signing happens entirely in your browser, so the secret never leaves your device.

Try the tools