JWT Decoder
A JWT decoder that runs entirely in your browser: read the header and payload, check exp and nbf validity, and see every registered claim explained with timestamps as readable dates.
Decoded in your browser - the token is never sent anywhere. This tool does not verify the signature (that needs the secret or public key).
About JWT Decoder
The JWT Decoder splits a token on its dots, base64url-decodes the header and payload, and prints both as formatted JSON. Above them sits a status line derived from the payload itself: expired, not yet valid, valid for the next few minutes, or no expiry claim at all. That is usually the question you actually have when an API returns 401 - is the token stale, is a clock wrong, or is the claim set not what the issuer promised. Everything happens in the page, so the token is never uploaded.
A JWT is three base64url segments defined by RFC 7519, carrying a JOSE header, a claims set and a signature over the first two. The registered claims iss, sub, aud, exp, nbf, iat and jti all have precise meanings in that specification, and most real authentication failures are claim failures: an aud that does not match the resource server, an nbf a few seconds in the future because two hosts disagree on time, or an alg of none, which RFC 7518 defines as an unsecured token and which a permissive verifier will accept as legitimate. The decoder flags alg=none explicitly for that reason.
This implementation is client-side JavaScript only. The token is decoded in the page and no request leaves your browser, which matters because a JWT is a bearer credential and pasting one into a remote debugger hands over whatever it authorises. It deliberately does not verify the signature: that requires the shared secret or the issuer's public key, and asking you for either would defeat the purpose. Use it to read and reason about a token, then verify signatures in your own code or against your identity provider's JWKS endpoint.
How to use it
- 1Paste the token into the JWT field - the three dot-separated segments on their own, without any Bearer prefix.
- 2Read the Status card for the verdict: expired, not yet valid, valid for the next N minutes, or no expiry claim, alongside the alg from the header.
- 3Inspect the Header and Payload panels, which show the decoded JSON side by side.
- 4Scroll to Registered claims to see iss, sub, aud, exp, nbf, iat, jti, scope and azp named in full, with exp, nbf and iat rendered as local dates.
- 5Confirm alg is what your verifier expects, and treat a red alg=none warning as a token to reject outright.
Common use cases
- -Confirming whether a 401 from an API is caused by an expired token or by a claim the resource server will not accept.
- -Troubleshooting an nbf or exp failure caused by clock skew between an identity provider and an application host.
- -Auditing a token issued by a new OIDC client to check its aud, scope and azp before wiring it into production.
- -Inspecting a customer-supplied token during a support case without uploading their bearer credential to a third party.
- -Reading the iat and jti of a token while investigating replay or session-length questions.
Frequently asked questions
- Is it safe to paste a JWT into an online decoder?
- Only if the decoder never sends it anywhere. A JWT is a bearer token: whoever holds it can act as its subject until it expires. This decoder runs entirely in your browser, so the token is parsed locally and no request carries it off your device. With any tool that decodes server-side, assume the token is disclosed and rotate it.
- Why does a JWT decoder not verify the signature?
- Verification needs the key. An HMAC algorithm such as HS256 requires the shared secret; RS256 or ES256 require the issuer's public key from its JWKS endpoint. A decoder that asked you to paste a signing secret would be asking for the credential that mints tokens. Decoding shows what a token claims; verification proves the issuer signed it, and belongs in your application or gateway.
- What does alg=none mean in a JWT?
- It is the unsecured JWS defined in RFC 7518: a token with an empty signature, asserting its claims with nothing behind them. Libraries that accept whatever algorithm the header names will treat such a token as valid, which lets an attacker rewrite the payload at will. Always pin the expected algorithms in your verifier and reject none. This decoder marks alg=none as unsafe when it sees it.
- What is the difference between exp and nbf in a JWT?
- Both are NumericDate claims from RFC 7519, measured in seconds since the Unix epoch. exp is the moment a token stops being acceptable; nbf is the moment it starts. A token whose nbf sits a few seconds ahead of the verifier's clock is rejected as not yet valid, which is why clock skew between issuer and verifier produces intermittent, hard-to-reproduce authentication failures. Both are shown here as readable local dates.