The three-part JWT structure
A compact signed JWT commonly looks like header.payload.signature. The header and payload are JSON encoded with Base64url. The signature covers the encoded first two sections.
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-42","exp":1780000000}Because Base64url is encoding, anyone holding the token can usually read those two sections. Do not place secrets in an ordinary signed JWT payload.
What decoding proves
Decoding proves only that the sections can be translated into bytes and, for the first two, parsed as JSON. An attacker can create a token with any payload they want. A decoder will display that payload even when the signature is absent, invalid, or created with an unrelated key.
What signature verification proves
Verification recomputes or checks a cryptographic signature using an allowed algorithm and the correct key. A successful result indicates the signed bytes were produced by someone with the relevant signing capability and were not changed afterward.
That conclusion depends on key protection and algorithm policy. A service should not blindly accept whatever alg appears in an untrusted header. It must restrict algorithms and key types according to its configuration.
Claims still require application checks
exp: reject after the expiration time, allowing only deliberate clock tolerance.nbf: do not accept before this time.iss: match the expected issuer.aud: include the intended recipient.sub: interpret only within the issuer’s rules.jti: an identifier can support replay tracking, but does not prevent replay by itself.
A valid signature plus invalid claims is still an unacceptable token. Authorization also requires application policy: a signed role string should not grant access unless its issuer and semantics are trusted.
Shared secrets and public keys
HS256, HS384, and HS512 use an HMAC shared secret; any verifier with that secret can also sign tokens. RSA and elliptic-curve schemes separate private signing keys from public verification keys. Key rotation, JWKS retrieval, revocation, and secure storage belong in the application architecture.
Inspect safely
The JWT Decoder decodes three-part tokens and can sign or verify only HS256, HS384, and HS512 with a supplied secret. It displays time claims but does not enforce issuer, audience, expiry, or authorization policy. Avoid entering production shared secrets on devices you do not trust.
For the underlying representation, read why Base64 is not encryption. For payload syntax, see JSON formatting, validation, and comparison.