JWT Header Explained: alg, typ and kid

The JWT header is the first of the three base64url segments and the smallest part of the token: a JSON object that usually names the signing algorithm and the token type. Small as it is, the header decides which cryptographic algorithm protects the token, and the way a validator treats it is a known source of real-world JWT vulnerabilities. The header fields and their meaning are defined in RFC 7519.

What is inside a JWT header?

A typical HS256 header is three fields, and decoding it takes seconds with the JWT Decoder:

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

alg is the only field that matters cryptographically. typ is informational, and kid appears only when a server manages multiple signing keys.

What does the alg header mean?

alg tells the validator which algorithm created the signature and therefore which key and verification steps apply. The value you most often see is HS256, but production systems commonly use RS256 and ES256 too, and each maps to a different key model:

The verifier must pick the verification routine from alg and only accept an algorithm it actually configured. A validator that trusts the header blindly can be tricked into treating an asymmetric token as a symmetric one - the algorithm confusion attack - which is why libraries are told to pin an allowlist of algorithms.

What does typ mean?

typ is short for type and declares the media type of the token, almost always the literal string JWT. It exists for the same reason an email has a Content-Type header: it tells parsers what they are looking at. It has no effect on verification, and a valid token missing typ decodes and verifies exactly like one that has it.

What does kid mean?

kid is a key identifier. When a service signs with keys that rotate, it sets kid to tell validators which key in the set produced this token. The validator reads kid, looks up the matching key, and verifies with it. Handling kid properly matters during rotation, because a validator that always uses a single key will fail or, worse, accept the wrong key after a rollover.

kid is only a label. The key itself must come from a trusted key set, not from the token, or an attacker can point kid at a key they control.

Why is alg=none dangerous?

The none value means the token is unsigned: the header says do not verify a signature, and the token carries an empty third segment. An attacker can take any valid JWT, change alg to none, delete the signature, and leave the payload claims intact. A validator that honors none accepts the forgery as if the issuer signed it.

Modern libraries reject none unless it is explicitly enabled, and the JWT specification requires that validators accept only algorithms they configured. If you are debugging a token and the header says alg none, treat the token as unsigned and untrustworthy, and make sure your own validator refuses it.

How do you read a JWT header?

Split the token on the dots and base64url-decode the first segment, exactly as described in how to decode a JWT. The JWT Decoder does that decoding and shows the header as formatted JSON. Once you know alg, you know which key model the token needs, and the JWT Validator can check that the signature actually matches.

What makes a header secure in practice?

• Pin the allowed algorithms in the validator; never trust alg from the token alone.
• Reject none and any algorithm the server did not configure.
• Validate that kid resolves to a key the server actually owns before verifying with it.
• Use a key of the correct length for the algorithm, such as 32 bytes for HS256.

The header is where a JWT states its intent. Verifying that the intent matches your policy is the difference between a token that is read and a token that is trusted.