JWT Inspector

Read the claim, not a promise

The sample has an HS256 header, a demo audience and an expiry in the past. The inspector can decode those values because compact signed JWTs use base64url encoding. Encoding is reversible. It provides no secrecy and says nothing about who created the token.

Expiry is only one part of acceptance

An exp value describes when a token must stop being accepted. A nbf value describes when it may start being accepted, and iat records an issuance time. An application still needs its own clock-skew policy, trusted issuer, permitted algorithms and audience checks. A future expiry cannot establish any of those things.

What this inspector deliberately leaves out

This release does not verify signatures, fetch key URLs, decrypt JWE tokens or contact an identity provider. It recognises the encrypted compact format without pretending its ciphertext is readable JSON. Unsupported encodings and malformed claim sets are reported rather than repaired silently.

Keep the result private

Copying or downloading a result may include every decoded claim. Remove personal identifiers before sharing it in a ticket. If a usable bearer token has already been exposed, follow your provider's revocation or rotation process. Closing this tab does not revoke it.

References

• JWT structure and registered claims, RFC 7519
• JWT implementation guidance, OWASP

Documentation reviewed: 1 November 2026. Rule results describe the supplied text, not a live application test.

Useful next steps

• Secret Redactor
• HTTP Security Headers Reviewer
• Practical guides and coding projects

Maintained by MetaCyberGuru. A review point may need source, runtime or deployment context before you act on it.