FameOrbitJWT Decoding Explained: Headers, Payloads, Claims and Signatures
JSON Web Tokens are compact strings commonly used to carry claims between systems. They often look intimidating because they are encoded, but the structure is straightforward: a typical signed JWT has a header, a payload and a signature separated by dots. Understanding each part makes authentication debugging much easier.
Updated September 2026 · FameOrbit editorial guide
The three JWT parts
A signed JWT is commonly represented as three Base64URL-encoded segments: header, payload and signature. The header describes metadata such as the signing algorithm and token type. The payload contains claims such as a subject, issuer or expiration. The signature is used to verify that the token was produced by a trusted signer and was not modified.
The first two segments can usually be decoded without a secret. That is why a JWT decoder is useful for debugging. It does not mean the token is valid or trustworthy.
What claims mean
Claims are statements carried in the payload. Registered claims include concepts such as issuer, subject, audience, expiration and issued-at time, while applications can define their own claims. A token can be syntactically valid and still be unacceptable because its issuer, audience or expiration does not meet application policy.
When debugging an authentication failure, inspect the timestamps and identity claims first. Time-zone confusion and clock skew are common causes of seemingly mysterious expiration problems.
Decoding is not verification
Decoding reverses the Base64URL representation. Verification checks a cryptographic signature against the expected algorithm and key. A developer who only decodes a token can see what it claims to say, but should not trust those claims until the application has verified the signature and applied its validation rules.
This distinction is essential when building security-sensitive software. Never treat a decoded payload as proof that a user is authenticated.
JWT privacy considerations
A normal signed JWT is not encrypted. Anyone who can obtain the token can generally decode the header and payload. Avoid putting passwords, private keys or unnecessary sensitive information into a signed-but-not-encrypted JWT.
Tokens should also be handled carefully in logs, screenshots and bug reports. A token copied into a public issue can be usable as a credential if the receiving system accepts it and it has not expired or been revoked.
Debugging responsibly
When investigating a JWT problem, use a test token where possible. Inspect the decoded header and payload, compare the issuer and audience with application configuration, check expiration, then verify the signature using the same library and key material used by the application.
FameOrbit's JWT Decoder is designed for inspection and development. It should complement, not replace, proper server-side token verification.