JWT tokens are used everywhere in modern authentication systems, but inspecting token contents during debugging is often slow and fragmented. This inspector decodes header and payload instantly and highlights key claims such as exp, iat, nbf, and aud.
The tool is built for safe and practical workflows. It clearly states that decoding is not signature verification, helping teams avoid false trust in unsigned inspection. All decoding is done in your browser, making it suitable for internal environments and secure debugging sessions.
How to inspect a JWT token
- Paste a JWT token into the input field.
- Review decoded header and payload JSON.
- Inspect claim summary including issue and expiry times.
- Use the copy buttons to export decoded sections for debugging notes.
Example Token Inspection
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwiZXhwIjoxOTAwMDAwMDAwfQ.signatureHeader and payload are decoded into JSON, with exp shown as readable date/time.JWT Structure: Header, Payload, and Signature
A JSON Web Token consists of three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded, which means you can decode the first two parts without any secret key or certificate.
The header is a JSON object that specifies the token type (typically JWT) and the signing algorithm. Common algorithms include HS256 (HMAC with SHA-256, using a shared secret) and RS256 (RSA with SHA-256, using a public/private key pair). The algorithm choice determines how the signature is created and verified.
The payload contains claims, which are statements about the user and metadata about the token. Claims are simply JSON key-value pairs. Standard claims include sub (subject identifier), iss (issuer), aud (audience), exp (expiration time), and iat (issued at time). Custom claims can contain any application-specific data like user roles or permissions.
The signature is computed over the encoded header and payload using the algorithm specified in the header. For HS256, the server signs with a secret key that both the issuer and verifier share. For RS256, the issuer signs with a private key and verifiers check with the corresponding public key. The signature ensures that the token has not been tampered with since it was issued.
Common JWT Claims and Security Considerations
The exp (expiration) claim is a Unix timestamp indicating when the token becomes invalid. Servers should reject tokens past their expiration time. The iat (issued at) claim records when the token was created. The nbf (not before) claim prevents a token from being used before a specific time, useful for tokens issued in advance.
The sub (subject) claim identifies the principal, typically a user ID. The iss (issuer) claim identifies who created the token, allowing verifiers to reject tokens from untrusted issuers. The aud (audience) claim specifies the intended recipient, preventing a token meant for one service from being accepted by another.
A critical security principle: never trust JWT contents without verifying the signature. The payload is encoded, not encrypted. Anyone can decode it, modify the claims, and re-encode it. Without signature verification, an attacker could change their user role from 'viewer' to 'admin' by simply editing the Base64 payload.
This tool intentionally decodes without verifying signatures, which is useful for debugging and inspection. You can see what claims a token carries, check if it has expired, and verify the issuer value. However, for any security decision in production code, always verify the signature using a trusted library and the correct key material. Decoding alone provides no guarantee of authenticity or integrity.