JWT Inspector
Decode and inspect JWT payloads and headers safely in the browser.
JWT Inspector
What This Tool Does
- JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a cryptographic secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. In modern web development, JWTs are most commonly used for stateless authorization. Once a user logs in, the authorization server generates a JWT containing user details and roles, sending it back to the client. The client subsequently includes this token in the header of API requests, allowing the resource server to validate the request without querying a central session database. This stateless nature makes JWTs highly scalable, but it also introduces operational challenges such as token size overhead and the difficulty of immediate token revocation.
- Because a JWT is self-contained, it encapsulates all the necessary user data, credentials, and authorization metadata within its own payload. This eliminates the database roundtrips required by traditional session-based cookies. However, this convenience demands strict security discipline. By default, standard JWT payloads are simply Base64URL-encoded strings, not encrypted ciphertext. This means that anyone who intercepts the token can read the claims (such as usernames, emails, and permissions) in plain text. Therefore, storing sensitive credentials or unencrypted personal data directly within standard JWT claims is a severe vulnerability. The JWT Inspector is designed to help developers inspect, decode, and troubleshoot these payloads entirely in the local environment, ensuring that credentials and secret tokens are never exposed to external validation endpoints during debugging session flows.
How It Works
- The JWT Inspector decodes JSON Web Tokens client-side inside your browser session.
- It first splits the token string by dots into its three constituent segments: Header, Payload, and Signature.
- It then normalizes the Base64URL encoding of the Header and Payload segments into standard Base64 by restoring any omitted padding characters (=) and mapping URL-safe characters (- and _ back to + and /).
- Next, it parses these raw JSON strings into JavaScript objects to render them in a clean syntax-highlighted editor.
- The inspector also checks the timestamp values of key claims like exp (Expiration Time), iat (Issued At), and nbf (Not Before) to calculate the remaining lifespan of the token relative to the developer's system clock.
Usage
- Paste your raw JWT string directly into the token input text area.
- Observe the automatically decoded Header and Payload outputs in the JSON panels.
- Review the expiration timeline indicator to see if the token is valid, expired, or active.
- Inspect custom application claims, security groups, and scopes listed in the payload.
- Check the algorithm specified in the header to ensure it matches your microservices design.
Examples
- Decoding a standard access token: Verify that sub maps to the correct user ID and exp is set to a short-lived future timestamp.
- Verifying multi-audience tokens: Ensure that the aud claim contains the correct client identifiers for your api server.
- Debugging local tokens: Check if local issuer iss matches the environment variables configured in your Node.js or Python backend.
- Checking scopes: Inspect the scp or scope array to verify that the user has the required read/write permissions.
- Decoding ID tokens: Check OIDC ID token fields like email_verified or nonce to validate authentication flow safety.
Real-World Use Cases
- Verifying custom user claims, organization contexts, and roles issued by Auth0, Okta, or Cognito during auth integration.
- Debugging token expiration bugs on frontend clients by verifying the exact datetime representation of the exp claim.
- Checking signature algorithms (such as RS256 vs HS256) inside the Header segment to verify backend security compliance.
- Validating standard claims (like aud and iss) to prevent token confusion attacks in multi-tenant application layouts.
- Inspecting security scopes and OAuth2 permissions inside API access tokens during local integration tests.
Best Practices
- Always validate exp claim and reject expired tokens; never trust client-side expiration checks.
- Validate aud claim matches your application ID to prevent token confusion attacks.
- Use RS256 (RSA) for when multiple services verify tokens; use HS256 (HMAC) only if one service signs and verifies.
- Store sensitive data in custom claims carefully; JWT payload is Base64-encoded (readable), not encrypted.
- Implement token refresh patterns; short-lived access tokens (15 min) + longer refresh tokens (7 days) reduce damage from token theft.
Common Mistakes
- Assuming that a JWT is encrypted; standard tokens are only Base64 encoded and are readable by anyone who intercepts them.
- Forgetting to verify the token signature on the server, which allows attackers to edit claims and gain admin access.
- Storing too many custom claims in the payload, causing the token size to exceed HTTP header limits (e.g. 8KB limits).
- Using a weak shared secret for HS256, which allows offline brute-force attacks to crack the secret key.
- Treating JWT claims like exp or iat as millisecond timestamps instead of Unix epoch seconds.
Limitations
- The inspector decodes token segments but does not guarantee signature verification against trusted keys.
- Do not paste production secrets into shared devices or recorded sessions.
Technical Reference Guide
- sub (Subject): Unique identifier for the end-user or entity the token represents. Usually a user ID or username. Example: "user123".
- iss (Issuer): Identifies the principal that issued the JWT. Usually the authorization server. Example: "https://auth.example.com".
- aud (Audience): Identifies the recipient(s) for which the JWT is intended. Used to reject tokens meant for other applications. Example: "my-app-api".
- exp (Expiration Time): Unix timestamp when the token expires. Tokens with exp in the past are invalid.
- nbf (Not Before): Unix timestamp indicating when the token becomes valid. Tokens before this time must be rejected.
- iat (Issued At): Unix timestamp indicating when the token was created, useful for determining token age.
- Custom claims: Applications can add domain-specific claims (roles, permissions, organization). Follow namespace conventions: "app:role", "org:team".
Specifications & Standards
FAQ
Is token data sent externally?
No. Token parsing runs in-browser only—nothing leaves your device.
Can this tool verify the signature of my JWT?
No, this is a local client-side inspector that focuses on decoding and debugging. Signature verification requires importing the signing key or secret, which should be done on a secure backend server.
Why does my JWT have only two parts instead of three?
A standard signed JWT (JWS) has three parts (Header.Payload.Signature). A token with two parts is likely an unsigned (plaintext) token, which is insecure and rarely supported in production environments.
What does the 'Invalid Token Structure' error mean?
It means the pasted string does not contain exactly three dot-separated segments or contains invalid characters. Ensure you copy the entire token, including header, payload, and signature.
How is a JWT different from a cookie?
A cookie is a browser storage and transmission mechanism, while a JWT is a token format. JWTs are often sent in the Authorization header or stored inside secure cookies.
What is the role of the 'kid' header parameter?
The Key ID ('kid') parameter hints to the verifying system which key was used to sign the token, enabling seamless key rotation without breaking active sessions.
Why do JWTs use Base64URL instead of standard Base64?
Base64URL replaces characters like '+' and '/' with '-' and '_', and removes '=' padding, ensuring the token can be safely passed in URL parameters and HTTP headers without encoding issues.
How should I handle token revocation?
Since JWTs are stateless, you cannot easily revoke them. Best practice is to keep access token lifetimes very short and use refresh tokens backed by a server database check for active sessions.
Related Tools
Explore related utilities inside the Security Lab workshop for complementary engineering workflows.
View all Security Lab tools