A JSON Web Token (JWT) commonly contains three dot-separated sections: a header, a payload and a signature. The first two sections are encoded so they can travel safely in text-based systems. Decoding them can help during development and debugging, but decoding alone does not prove that a token is genuine.
Use the JWT Decoder to inspect a token’s readable sections without treating the result as signature verification.
JWT structure
The header normally identifies the token type and signing algorithm. The payload contains claims, which can include standard fields such as issuer, audience, subject and expiry time as well as application-specific data. The final section contains signature material for signed tokens.
Decoding is not verification
Header and payload sections can be decoded without knowing the signing secret or private key. That means anyone who has the token can read them. A successful decode does not confirm that the signature is valid or that the claims should be trusted.
Common claims to review
iss– the issuer.sub– the subject.aud– the intended audience.exp– the expiry timestamp.nbf– the time before which the token should not be accepted.iat– the issued-at time.
Do not paste sensitive production tokens into unknown services
JWT payloads can contain identifiers, roles or other application data. Access tokens may also grant real permissions while they are valid. Use local or trusted tooling and avoid sharing live credentials in screenshots, tickets or public examples.
Base64URL differences
JWT sections use Base64URL encoding, a URL-safe variant of Base64. Characters and padding can differ from standard Base64, so a general decoder may need special handling.
Verify tokens in the application that relies on them
Proper verification must use the expected algorithm, trusted key material and application rules for issuer, audience and time-based claims. The UptimeFixer JWT Decoder helps you read the token, but security decisions should be made only after full verification in the system that accepts it.