Decode and inspect JSON Web Tokens — view header, payload, and verify signatures locally
A JWT (JSON Web Token) debugger decodes the three Base64URL-encoded parts of a JWT — header, payload, and signature — into readable JSON objects so you can inspect the token contents. JWTs are compact, URL-safe tokens used for authentication, authorization, and information exchange between parties. The header specifies the signing algorithm, the payload contains claims (user data, permissions, expiration), and the signature ensures the token has not been tampered with.
JWT debugging is essential for troubleshooting authentication failures, verifying token claims during API development, inspecting expiration times, checking role-based access control claims, and understanding what information your application is embedding in tokens. A debugger that also verifies signatures helps you confirm whether a token was signed with the expected secret or key, detecting potential security issues in your authentication pipeline.
PinusX decodes JWT tokens with 100% client-side processing — your tokens never leave your browser. This is absolutely critical because JWT tokens contain authentication credentials: user IDs, roles, permissions, session data, and often sensitive claims. Pasting a valid JWT into a server-based debugger gives that server full access to impersonate the user or extract private data. In November 2025, jsonformatter.org leaked over 80,000 user credentials processed on their servers. PinusX prevents this by running all decoding and signature verification locally in your browser tab. Your authentication tokens stay on your machine.
Only if the tool processes entirely client-side, like PinusX. Server-based JWT debuggers receive your complete token, which could be used to impersonate the user until it expires. Never paste production JWTs with active sessions into tools that send data to servers. PinusX is safe because nothing is transmitted.
Key claims to inspect: exp (expiration time — is the token expired?), iat (issued at — when was it created?), sub (subject — who is it for?), iss (issuer — who created it?), aud (audience — who is it intended for?), and any custom claims like role, permissions, or scope. Invalid claims are the most common cause of auth failures.
Yes. Enter your HMAC secret (for HS256/HS384/HS512) or RSA/EC public key (for RS256/ES256) and the tool verifies the signature locally in your browser. A valid signature confirms the token has not been modified since it was signed. Invalid signatures indicate tampering or wrong signing key.
The header typically contains two fields: alg (the signing algorithm, like HS256 or RS256) and typ (the token type, usually JWT). Some tokens include kid (key ID) for selecting the correct verification key from a JWKS endpoint, or additional fields for key rotation and token management.
This usually means your server is not validating the exp claim, or its clock is skewed. Check that your validation middleware explicitly checks token expiration. Clock skew between servers can cause tokens to appear valid when they should be expired. Most JWT libraries accept a small clock skew tolerance (typically 30-60 seconds).
Your data never leaves your browser. 100% client-side processing.
Get instant alerts when your endpoints go down. 60-second checks, free forever.
Start Monitoring Free →