Start with the three-part structure
A compact JSON Web Token normally contains three dot-separated segments: header, payload, and signature. The first two are Base64URL-encoded JSON. They are not encrypted. Anyone holding the token can usually read them.
base64url(header).base64url(payload).signatureThe header describes how the token is intended to be processed. The payload contains claims. The signature binds those bytes to a key and algorithm. Decoding the first two parts does not prove that the signature is valid.
Inspect the header before trusting claims
Record the alg and typ values, then look for key selection fields such as kid, jku, or x5u. In a legitimate assessment or CTF, those fields may reveal how the verifier chooses a key. Do not assume that changing alg changes server behavior; the server must still accept the modified token.
Read claims as untrusted input
| Claim | Question to ask |
|---|---|
iss | Who issued the token, and does the application validate it? |
aud | Which service is the token intended for? |
sub | Which identity does the token describe? |
exp | Is the expiration in the future, and is it interpreted as Unix seconds? |
nbf | When does the token become valid? |
iat | When was it issued, and is that time plausible? |
Application-specific fields such as role, admin, or scope are only assertions until the signature and surrounding authorization logic have been verified.
A safe CTF inspection example
Decode the sample token in the local JWT tool. If the payload contains "admin": false, changing it to true will invalidate the original signature. The useful question is not “can I edit the JSON?” but “does the challenge verifier incorrectly accept the edited bytes?” Keep the original and modified versions separate so your test remains reproducible.
Hexforge displays header and payload contents locally. It does not possess the issuer's key and does not claim that a token is authentic.
Common mistakes
Using milliseconds for JWT time claims
JWT numeric dates are normally Unix seconds. A 13-digit value is usually milliseconds and may indicate custom application behavior or a mistaken conversion.
Ignoring the exact signing input
The signature covers the encoded header, a dot, and the encoded payload. Reformatting JSON or changing padding changes those bytes even when the displayed object looks equivalent.
Testing systems without permission
Only analyze tokens from your own applications, authorized labs, or CTF environments. A token may contain personal or session data even when its payload is readable.
Repeatable checklist
- Preserve the complete original token.
- Count segments and decode header and payload.
- Record the algorithm and key-selection fields.
- Convert
exp,nbf, andiatto readable time. - Treat all claims as untrusted until signature verification is established.
- Document every mutation and server response in the challenge workspace.