How JWT Tokens Are Structured
Understand JWT header, payload and signature sections, plus why decoding a JWT is not the same as verifying it.
By Lumarc Studio · Updated 2026-07-29
A JSON Web Token, usually called a JWT, is a compact string with sections separated by dots.
header.payload.signatureThe header and payload are Base64URL-encoded JSON. The signature is used by a verifier to check that the token was issued by a trusted party and has not been changed.
Header
The header describes the token type and signing algorithm:
{
"alg": "HS256",
"typ": "JWT"
}This tells a verifier how the signature should be checked. It does not prove the token is valid by itself.
Payload
The payload contains claims:
{
"sub": "123",
"exp": 1893456000,
"role": "admin"
}Claims may describe a subject, expiry time, issuer, audience or application-specific values. Anyone with the token can decode these claims unless the token is encrypted separately.
Decoding vs Verification
The JWT Decoder shows the header and payload locally in your browser. That is useful for debugging, but decoding is not verification. A decoded token can be expired, forged, copied from another environment or signed with a key your system should reject.
Verification requires the expected algorithm, issuer rules, audience rules, expiry checks and the correct secret or public key. That logic belongs in the application or identity layer, not in a simple decoder.
Security Notes
Do not paste production tokens into unknown websites. Lumarc DevTools processes input locally, but tokens can still be sensitive because claims may reveal account IDs, tenant IDs, emails or authorization scopes.