JWT Decoder

Paste the entire JWT string into the input box. A JWT looks like three Base64URL-encoded segments separated by dots: eyJhbGciOi....eyJzdWIiOi....SflKxwRJ.... The tool splits on the dots, decodes the first two segments (header and payload) from Base64URL into JSON, and displays the parsed objects. You don't need a secret or public key to decode — JWTs are intentionally readable by anyone who has the token. The signature (third segment) is what proves authenticity, but it's not needed to read the contents. So 'decode JWT', 'read JWT payload', 'inspect JWT claims', and 'view JWT header' all describe this same operation, and this tool does it in your browser with zero network calls.

Yes, completely safe. The decoding happens entirely in your browser using JavaScript, and your token is never sent to any server or stored anywhere. I know a lot of developers get nervous about pasting tokens into online tools, and that is a totally valid concern with sites like jwt.io where you might wonder what is happening server-side. Here, there is literally no network request involved. You can verify this yourself by opening your browser's Network tab before pasting a token and watching for any outgoing calls. You will see zero requests. The tool just splits your token on the dot separators, base64url-decodes each segment, and renders the JSON. Your token stays in your browser's memory and gets garbage collected when you navigate away. So go ahead and paste production tokens if you need to debug something quickly.

The IETF reserved claims are: iss (issuer — who created the token, usually your auth provider's URL), sub (subject — typically the user ID), aud (audience — who the token is intended for, usually your API), exp (expiration time as a Unix timestamp), nbf (not-before time), iat (issued-at time), and jti (JWT ID, a unique identifier for the token). The tool automatically converts the Unix timestamps in exp, iat, and nbf to human-readable dates so you can immediately see if a token is expired without doing the math. Beyond the standard claims, your token will usually also have custom claims specific to your application — things like user roles, tenant IDs, or feature flags. Those are just regular JSON fields in the payload.

This tool only decodes and displays the token contents, it does not verify signatures. And honestly, for most debugging scenarios that is exactly what you want. When I am troubleshooting auth issues, 95% of the time I just need to see what claims are in the payload, check if the token is expired, or confirm the issuer and audience values are correct. Verification is a different operation entirely because it requires either the HMAC secret (for HS256) or the public key (for RS256/ES256) to validate that third segment of the token. If you actually need signature verification, you will want to use a library like jsonwebtoken in Node.js or PyJWT in Python, or a tool like jwt.io where you can paste in your public key. But for quick inspection and debugging, decoding is what you need.

Three common causes. First, you may have copied only part of the token — JWTs are long, and email clients or terminals sometimes truncate the third segment. Make sure you grabbed the entire string between any quotes or whitespace. Second, the token may not actually be a JWT — some auth systems use opaque random strings that look similar but aren't structured. A real JWT always has exactly two dots, splitting it into three Base64URL parts. Third, if the payload looks like garbage characters, the segment may be Base64-encoded (with + and /) rather than Base64URL-encoded (with - and _) — most decoders handle both, but a malformed token from a buggy issuer can break this. Try pasting individual segments into the Base64 decoder tool to see what's there.