JWT Claims Inspector
Decode JWT structure, inspect registered and provider-specific claims, and compare timing boundaries without implying signature verification.
Three-part JWS tokens can expose their JSON claims. Five-part compact JWE tokens are recognized as encrypted, but their claims cannot be read here without decryption keys and algorithms.
Compare claims with the context you actually expect
Whole seconds from 0 to 300. Tolerance is applied symmetrically to exp, nbf, and future iat comparisons.
Copyable claim report
Decoded claim details will appear here.
Decoded claims are data, not proof that the token is trustworthy
Anyone can create a JWT-looking header and payload. Reading iss, aud, sub, or an unexpired exp tells you what the token claims, not whether a trusted issuer actually signed it.
Real acceptance requires cryptographic verification with an allowed algorithm and the correct key, followed by the claim rules for that token profile. RFC 8725 specifically calls out algorithm verification, issuer validation, and audience validation as security requirements in applicable JWT deployments.
NumericDate is seconds since the Unix epoch, and it may contain a fraction
RFC 7519 defines exp, nbf, and iat using NumericDate. NumericDate is a JSON number measured in seconds from 1970-01-01T00:00:00Z, and non-integer values are allowed. Strings such as "1717078800" are therefore not valid NumericDate values.
The clock tolerance setting is an explicit comparison aid rather than a claim rewrite. It never changes the decoded value, and very large finite timestamps are shown as outside JavaScript's Date range instead of causing formatting to fail.
Issuer and audience checks only make sense against expected values
Registered claims are optional unless the application or token profile makes them required. That is why missing iss, aud, sub, and exp are not treated as universal failures by default. Turn on a requirement only when it reflects the system you are debugging.
When you enter an expected issuer, comparison is exact and case-sensitive. Audience may be a single string or an array of strings; a match means the expected audience appears in that registered claim, not that the token has been authenticated.
Unsecured JWS and encrypted JWE are different cases
A three-part JWS using alg=none is an unsecured JWT and, when structurally valid, has an empty signature segment. It can be decoded but should only be accepted in an application that explicitly permits that unsecured form and protects it by other means. A five-part compact JWE is encrypted; its protected header is visible, while the claims remain encrypted until decryption succeeds.
JWTs also use UTF-8 JSON and unpadded Base64URL. The decoder checks canonical Base64URL rather than quietly accepting malformed padding or a different text encoding.
Scopes and roles are conventions layered on top of JWT
Claims such as scope, scp, roles, permissions, and groups are common in real identity systems, but their meaning is provider- or application-specific. Seeing admin in a decoded array is not authorization by itself.
The standards behind the checks
RFC 7519 defines JWT and the registered claims. RFC 7515 defines JWS compact serialization, including the unsecured form. RFC 8725 adds current JWT security guidance. RFC 7797 explicitly says JWTs must not use the JWS unencoded-payload option.