JWT Decoder
Decode a JWT header and payload locally, with claims explained and expiry counted down. 100% free, no signup. Everything runs in your browser.
Loading the tool…
Paste any JSON Web Token into this free JWT decoder and you instantly see the decoded header and payload laid out as clean, readable JSON. The registered claims that actually matter (exp, iat, nbf, iss, sub and aud) are explained in plain English next to their values, and the expiry is shown as a live countdown or as "expired 12 minutes ago" so you never have to convert a Unix timestamp in your head again.
Two things before you paste anything. First, this tool decodes tokens, it does not verify them. A decoded payload proves nothing about who issued the token or whether it was tampered with, and I say that loudly because plenty of decoders quietly gloss over it. Second, JWTs are credentials, so everything runs in your browser and the token never touches a server. If you work with raw Unix timestamps elsewhere, my epoch timestamp converter pairs nicely with this one.
How to use
- Copy the JWT from your API response, browser storage, cURL output or server logs.
- Paste it into the input box at the top of the tool.
- Read the decoded header to see the signing algorithm and token type.
- Review the payload, where each registered claim is explained beside its raw value.
- Check the expiry line, shown as a live countdown or as time elapsed since expiry.
- Copy the pretty JSON output if you want to save it or share it with a teammate.
Why use our jwt decoder?
The biggest reason I built this decoder the way I did is privacy. A JWT is a credential. If someone captures a live access token they can often act as you until it expires, which is why pasting tokens into a random website that posts them to a server is a genuinely bad habit. This tool does the base64url decoding with JavaScript on your machine, so the token never leaves the browser. You can load the page, switch off your Wi-Fi and it still works.
The claim explanations save you a trip to the spec. Instead of staring at "exp": 1767225599 and guessing, you see that exp is the expiration time, iat is when the token was issued, nbf is the moment before which it must be rejected, iss identifies the issuer, sub is the subject and aud is the intended audience. All six registered claims are defined in RFC 7519, and I link the spec because the summaries here are conveniences, not replacements for it.
The live expiry countdown is the feature I use most myself. When you are debugging a 401 response, the first question is almost always "is this token simply expired?" Seeing "expires in 4 minutes 12 seconds" or "expired 3 hours ago" answers that in one glance.
I also want to be direct about what this tool does not do, because the distinction matters for security. Decoding is not verification. Anyone can mint a token that claims to be from your issuer with any payload they like, and it will decode perfectly here. Only checking the signature against the issuer's key proves authenticity, and that belongs in your backend, not in a browser tool. Treat everything you see here as "what the token says", never as "what is true".
Beyond that, it is simply fast. No signup, no rate limits, no ads between you and the output. The payload renders as properly indented JSON, the same formatting you get from my JSON formatter, so nested custom claims are easy to scan.
Who is this tool for?
Debugging authentication is the obvious one. When an API starts returning 401 or 403, decode the access token and check the audience, issuer and expiry before you touch any code. In my experience a surprising share of "broken auth" tickets turn out to be an expired token or an aud claim pointing at the wrong API, and both are visible here in seconds.
Frontend developers use it to inspect what their identity provider actually puts in a token. Auth0, Cognito, Firebase and Microsoft Entra all shape their claims slightly differently, and reading a real decoded payload beats reading their documentation diagrams. If your provider stores user identifiers as UUIDs, my UUID generator is handy when you need placeholder values for tests.
It is also a genuinely good learning tool. If you are studying for an interview or just met JWTs for the first time, paste a sample token and watch how the three dot-separated segments map to header, payload and signature. Seeing your own data appear in the payload makes the "JWTs are readable by anyone" lesson stick far better than any article.
Finally, security reviews. When I audit a project I decode a few captured tokens to check whether anything sensitive is riding in the payload. Emails and role flags are common and usually fine, but I have seen internal hostnames and even phone numbers in there. Since the payload is only encoded, not encrypted, that data is effectively public to anyone holding the token.
Frequently asked questions
No, and I want that to be unmissable. It decodes the header and payload so you can read them, but it never checks the signature against a key. A token that decodes cleanly can still be forged, expired or issued by the wrong party. Verification requires the issuer's secret or public key and belongs on your server.
The token is decoded with JavaScript in your browser and never transmitted anywhere, which you can confirm in your network tab. That said, good hygiene still applies: prefer tokens from development environments, and treat any live production token as sensitive no matter what tool you use.
A JWT is three base64url segments joined by dots. The first is the header (algorithm and type), the second is the payload (the claims), and the third is the signature. This tool decodes the first two and displays the third as-is, since a signature is binary data, not readable JSON.
It is the expiration time as a Unix timestamp in seconds. A compliant server must reject the token after that moment. The decoder converts it to your local time and runs a live countdown, so you can watch a short-lived token tick down while you debug.
The usual culprits are a missing segment (JWTs need exactly two dots), stray whitespace or quotes picked up when copying, or the fact that it is not a JWT at all. Many providers issue opaque access tokens that are just random strings, and those cannot be decoded by anyone.
No. A standard signed JWT is encoded, not encrypted, so anyone holding the token can read the payload exactly as this tool does. Keep secrets server-side and store them properly, never inside a token payload.
Decoding does not depend on the algorithm at all, so tokens signed with HS256, RS256, ES256 or anything else display identically. The alg value in the header is shown for information only, since no signature checking happens here.