What Is a JWT? How to Decode a JSON Web Token (and What Never to Put in One)

The short answer

A JWT (JSON Web Token) is a compact, URL-safe string that carries a set of claims as JSON, defined in RFC 7519 (the spec suggests pronouncing it "jot"). The common, signed form has three parts joined by dots: header.payload.signature. To decode one, split it on the dots and base64url-decode the first two parts — each turns into plain JSON. You don't need a key for that, because base64url is an encoding, not encryption. Decoding tells you what a token says; only verifying the signature with the right key tells you whether to believe it.

Anatomy of a real token

Here is a genuine HS256 token, signed with a random 256-bit secret we generated for this article and haven't published. Line breaks after the dots are for display only:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyXzg0MTMiLCJuYW1lIjoiSmFuZSBEb2UiLCJpYXQiOjE3ODk1NDkyMDAsImV4cCI6MTc4OTU1MDEwMH0.
jTzXUkptGVt4F1Bwp8MNRZgkI3EAnwwYbXtPoT_RqdA

Base64url-decoding the first two segments gives:

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "user_8413",
  "name": "Jane Doe",
  "iat": 1789549200,
  "exp": 1789550100
}

The header says how the token was signed (alg) and what it is (typ). The payload holds the claims: sub, iat and exp are registered claims from RFC 7519, while name is a custom one. The signature is an HMAC-SHA256 over the first two segments exactly as they appear in the token:

signature = base64url(
  HMAC-SHA256(secret, base64url(header) + "." + base64url(payload))
)

Change one character of the payload and the signature no longer matches — but only someone holding the secret can check that.

Base64url is encoding, not encryption

Base64url, as defined for JWTs in RFC 7515, is ordinary Base64 using the URL-safe alphabet — - and _ instead of + and / — with the trailing = padding dropped. It is fully reversible by anyone. It's also why most tokens start with eyJ: that is how {" followed by a letter comes out in Base64. So everything in the payload is readable by whoever holds the token — the user, browser extensions, proxies, and any log file it lands in. RFC 7519's privacy section says it plainly: omitting privacy-sensitive information from a JWT is the simplest way to minimise privacy issues.

Can you decode a JWT without the secret key?

Yes — decoding needs nothing but the token. What you can't do without the key is verify it. With HS256, the same shared secret signs and verifies. With RS256 or ES256, the issuer signs with a private key and anyone with the matching public key can verify. RFC 7519 is explicit that a token's contents can't be relied on for a trust decision unless they're cryptographically secured, so a decoder is a debugging aid, not an authentication check. Anyone can build a token claiming "admin": true; the signature check on your server is what rejects it.

Reading the registered claims

RFC 7519's registered claims are all optional. These six matter most:

• iss (issuer) — who created the token.
• sub (subject) — who the token is about, unique within that issuer.
• aud (audience) — who the token is for. If it's present and the recipient isn't listed, the token must be rejected.
• exp (expiration time) — on or after this moment, the token must not be accepted.
• nbf (not before) — before this moment, the token must not be accepted.
• iat (issued at) — when the token was created, useful for working out its age.

The three time claims use a NumericDate: the number of seconds since 1970-01-01T00:00:00Z UTC, ignoring leap seconds. Seconds, not milliseconds — JavaScript dates count milliseconds, so multiply by 1,000 before converting:

node -e 'console.log(new Date(1789550100 * 1000).toISOString())'
# 2026-09-16T09:15:00.000Z

So the example token was issued at 09:00 UTC on 16 September 2026 and expired 15 minutes later. RFC 7519 lets verifiers allow a small leeway for clock skew, "usually no more than a few minutes".

How to decode a JWT on the command line

Node's Buffer understands base64url directly, so this prints the header and payload of whatever is in $TOKEN:

node -e '
  const [h, p] = process.argv[1].split(".");
  for (const s of [h, p])
    console.log(JSON.parse(Buffer.from(s, "base64url")));
' "$TOKEN"

With jq (we tested 1.7.1), swap the URL-safe characters back first, because its @base64d filter expects the standard alphabet:

printf '%s' "$TOKEN" | jq -R 'split(".")[0:2]
  | map(gsub("-"; "+") | gsub("_"; "/") | @base64d | fromjson)'

Piping a segment straight into base64 -d is unreliable because the padding is gone: on macOS it silently dropped the last two characters of our example payload, with no error. For a one-off check, CheckSEO's Base64 decoder accepts either alphabet without padding. Tokens typed into commands end up in shell history, so use test or expired ones.

JWS vs JWE

A JWT is carried as either a JWS (JSON Web Signature, RFC 7515) or a JWE (JSON Web Encryption, RFC 7516). A JWS is signed: three segments, readable payload — what almost everyone means by "JWT". A JWE is encrypted and has five segments: protected header, encrypted key, initialization vector, ciphertext and authentication tag. If claims genuinely need to be confidential, use a JWE — or better, keep them out of the token.

What never to put in a JWT, and 6 other mistakes

So token storage is also an XSS question: preventing injected script — including with a Content-Security-Policy, covered in our security headers checklist — matters as much as where the token lives.

Decode your token now

CheckSEO's JWT Decoder decodes the header and payload locally in your browser — the token is never uploaded. It strips a pasted Bearer prefix, shows iss, sub, aud and the exp/iat/nbf times as UTC dates with relative times, and flags expired or not-yet-valid tokens. It warns about alg: none, a missing exp and millisecond timestamps, and recognises five-segment JWEs. It doesn't verify signatures: that needs the issuer's key, and belongs on your server.