JWT Decoding vs Signature Verification
Understand what a JWT decoder can reveal, what signature verification proves, and which claims applications must validate.
The three parts of a JWT
A typical JSON Web Token contains a header, payload, and signature separated by dots. The header describes metadata such as the signing algorithm. The payload contains claims about a subject, issuer, audience, permissions, and time limits.
The first two parts use Base64URL encoding, which makes them readable without a secret key. That convenience is useful for debugging, but it also means the payload should never be treated as encrypted or private.
What decoding actually does
Decoding converts the header and payload from Base64URL text into readable JSON. It helps a developer inspect fields such as iss, sub, aud, exp, nbf, scopes, and roles when diagnosing an authentication problem.
A decoder does not contact the issuer, check the signature, confirm the algorithm, or decide whether the current application should trust the claims. Anyone can create a token-shaped string with arbitrary payload values.
What verification must check
Signature verification proves that the signed token content matches the key used by the expected issuer. Secure applications must also restrict accepted algorithms and obtain keys through a trusted configuration or issuer metadata endpoint.
A valid signature is only one part of validation. The application should check the issuer, intended audience, expiration, not-before time, and any application-specific authorization rules before granting access.
Understanding exp, nbf, iss, and aud
The exp claim is a Unix timestamp after which the token should no longer be accepted. nbf indicates when acceptance may begin. Small clock differences between systems can require a limited, intentional tolerance rather than ignoring time validation.
iss identifies the authority that created the token, while aud identifies the service or application for which it was issued. Accepting a token with the wrong audience can allow a token created for one service to be replayed against another.
Safe token debugging
Use a local decoder to inspect token structure, then reproduce the real verification path in the application or trusted identity library. Compare the issuer, audience, algorithm, key identifier, and timestamps with the system configuration.
Tokens commonly grant access and should be treated as credentials. Do not paste production tokens into tickets, public chats, screenshots, or third-party websites. Replace sensitive values with a purpose-built test token whenever possible.