Extract and display JWT claims as formatted JSON with registered claim explanations and timestamp conversion.
JWT Claims Inspector turns the claim set inside a compact, signed JWT into readable, indented JSON. It decodes the token's payload segment, labels registered claims such as sub and iat, and converts supported NumericDate values into dates. The main trap is treating a successful decode as proof that the token is genuine. A signed JWT payload is encoded, not hidden, and inspection alone does not establish who signed it or whether it should be accepted. Since pasted tokens may contain credentials or personal data, this browser-only inspection keeps them on the device.
A concrete input and expected output from the current implementation.
Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Expected output
Claims JSON:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Registered claim details: sub = Subject; iat = Issued At; iat represents 2018-01-18T01:30:22Z. The payload segment decodes to the three-member JSON object shown. The iat number is seconds since 1970-01-01T00:00:00Z; 1516239022 seconds lands at 2018-01-18T01:30:22Z, so the converted instant and raw value agree. The sub label identifies the registered Subject claim.
For a three-part compact token, the inspector takes the middle segment as the claim set. That segment uses base64url, so its alphabet and omitted padding differ from ordinary Base64. After decoding the bytes as JSON, the tool presents object members with indentation. The first segment is the JOSE header, while the third carries signature data; neither belongs to the claims object.
Names registered for JWTs receive claim-specific explanations rather than being treated only as arbitrary JSON keys. NumericDate claims such as exp, nbf, and iat express seconds relative to the Unix epoch, and the inspector adds a date conversion for those values. Private claim names and nested values remain JSON; their business meaning must come from the token issuer.
No. Decoding requires no signing secret or public key and establishes only what bytes are present in the payload. Acceptance requires cryptographic signature validation plus checks appropriate to the application, such as allowed algorithms, trusted keys, expected issuer and audience, and current-time handling. Use the inspector to understand claims, not as an authentication decision.
No, not into plaintext claims. A compact JWE has five segments and protects its payload with encryption, so the claims cannot be recovered merely by base64url-decoding one segment. This inspector is for JWT claim payloads that are directly decodable. An encrypted token must first be decrypted by a party holding suitable key material.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.