Inspect a JWT Token Payload
JSON Web Tokens (JWTs) are the dominant format for authentication credentials in modern web applications, used by OAuth 2.0 providers, REST API auth middleware, and single sign-on systems. A JWT looks like an opaque string, but it's actually three Base64url-encoded sections separated by dots: the header, the payload, and the signature. Decoding the first two reveals exactly what the auth server told your application about the authenticated user. This example contains a realistic JWT with standard claims in the payload. The header declares the algorithm (HS256 in this case, meaning HMAC-SHA256 with a shared secret) and the token type. The payload contains the standard registered claims: sub (the subject — usually a user ID), name, email, role (a custom claim), iat (issued-at timestamp), and exp (expiration timestamp). When debugging authentication failures, the first things to check are: is exp in the past (token expired)? Does sub match the expected user ID? Are custom claims like role or scope present and set to the right values? Does aud (audience) match your API's expected value? The decoder shows all of these at a glance with the exp timestamp converted to a human-readable date and a clear "expired" or "valid" indicator. Real-world scenarios: a user reports they're being logged out unexpectedly — decoding their token reveals exp is set to one hour in the future rather than the expected 24 hours, indicating the auth server's token lifetime configuration was changed. Or an API is returning 403 Forbidden even though the user is authenticated — the token's role claim is "user" but the endpoint requires "admin". Tips and pitfalls: decoding is not the same as verification. Anyone can decode a JWT without the secret key. Signature verification (which requires the secret or public key) is what prevents tampering. Never skip signature verification in your backend — only trust claims from a verified token. Security note: avoid pasting real production JWTs from long-lived sessions into online tools as a general hygiene practice. This decoder runs entirely client-side with no server calls, but the habit of protecting tokens is worth maintaining.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJKYW5lIFNtaXRoIiwiZW1haWwiOiJqYW5lQGV4YW1wbGUuY29tIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
FAQ
- Is it safe to paste a real JWT here?
- Decoding runs entirely in your browser with no server calls. That said, avoid pasting long-lived production tokens into any online tool as a general security practice.
- What is the exp claim?
- exp is a Unix timestamp (seconds since epoch) indicating when the token expires. The decoder compares it to the current time and shows whether the token is still valid.
- Can this tool verify the JWT signature?
- No. Signature verification requires the secret key, which is a server-side operation. This tool only decodes the readable header and payload sections.
Related Examples
REST APIs return compact, minified JSON to save bandwidth, but that makes the re...
Format a Webhook PayloadWebhooks are HTTP POST requests that third-party services send to your server wh...
Format an API Error ResponseWell-designed API error responses are what separates APIs that developers love f...