How to Decode a JWT: Header, Payload and Claims Explained

A JWT is a compact, URL-safe way to carry claims between parties. Its structure is deliberately simple: three base64url segments separated by dots. Once you can read those segments, decoding a token takes seconds — and it never requires the secret that signed it.

JWT

JSON Web Token — an encoded, signed (or signed-and-encrypted) container for JSON claims, standardized in RFC 7519, commonly used for access tokens and ID tokens.

Header

The first segment. A small JSON object that states the signing algorithm (typically HS256, RS256 or ES256) and often the token type (typ: JWT).

Payload (claims)

The second segment. JSON statements about the subject: who it is (sub), who issued it (iss), who it's for (aud), when it expires (exp) and when it was issued (iat).

Signature

The third segment. A cryptographic tag produced from header + payload using the algorithm's secret or private key. It proves the token hasn't been tampered with and pins its issuer.

base64url

The URL-safe Base64 variant JWTs use: - replaces +, _ replaces /, and trailing = padding is removed so the token travels inside headers and query strings without escaping issues.

The three parts of a JWT

Every standard JWT has exactly two dots, splitting it into three segments. The first two are plain JSON that has been base64url-encoded — anyone can read them, which is why JWTs carry claims, never sensitive secrets.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIn0.fGBj_cRZlF2P_fuY-SL9vLKab7nNZs7mR4kHVeLP86Y

header.payload.signature

1. header    ->  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. payload   ->  eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2huIn0
3. signature ->  fGBj_cRZlF2P_fuY-SL9vLKab7nNZs7mR4kHVeLP86Y

What's in the header

The header is the smallest part. Its only job is to tell verifiers how the token was signed and what type it is. Decoding the first segment above gives exactly this JSON:

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

Common claims in the payload

The payload holds the claims. Some are registered (community-standardized), some are public (custom, but collision-resistant), and some are private to your issuer. The most common registered claims are:

The exp and iat values are Unix timestamps. To read them as human dates, paste them into the Timestamp Converter — the difference between exp and iat is the token's intended lifetime.

Decoding is not verifying

Because header and payload are encoded, not encrypted, decoding never needs a secret — and success says nothing about authenticity. A token decodes perfectly even if an attacker forged it. Verifying means recomputing the signature with the issuer's public key or shared secret, and that happens in your application, on the server.

How to decode a JWT online

1. Paste the token into the JWT Decoder — a leading 'Bearer ' is stripped automatically, and dots count as exactly two.
2. Read the header (algorithm) and payload (claims) as formatted JSON sections.
3. Check exp and iat: convert them with the Timestamp Converter to confirm the token's lifetime and current validity.
4. Satisfied with the claims? Move on to verification — a signature check requires the issuer's key and never happens in a decoder.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyOjEwNDIiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJleHAiOjE4MjcwNzIwMDB9.signature

Header
{
  "alg": "HS256"
}
---
Payload
{
  "sub": "user:1042",
  "iss": "https://auth.example.com",
  "exp": 1827072000
}

Why a pasted token might fail to decode

• Truncation — most often the final signature segment is dropped during copy-paste. Re-copy the whole three-part token.
• URL-encoding — tokens that traveled through logs or query strings may contain %22 or %7B sequences. Run them through the URL Decoder first.
• Not a JWT — an access-token format that isn't three dot-separated base64url segments (for example opaque tokens or some opaque SAML artifacts).

Try it

Paste any real token into the JWT Decoder to see its header and claims as readable JSON, then use the Timestamp Converter to interpret exp, iat and nbf. Pair it with the HTTP Header Inspector when an Authorization header is rejecting your requests.