A JWT decoder that never sees your token.
Paste a JSON Web Token to inspect its header, payload, and signature. Standard claims are expanded with explanations. Nothing is sent to a server — your tokens stay on your machine.
0 charsYour token never leaves your machine. Decoding is local — the page splits the JWT on the dots, base64-decodes the header and payload, and renders them in this tab. We never see the token, the claims, or the user it represents.
A spec-correct decoder, with the obvious explanations.
The features people actually use when poking at a JWT — color-coded segments, claim hints, expiry warnings — surfaced without sign-up, without ads, and without sending your token to anyone.
Each part of the JWT — header, payload, signature — is shown separately and color-matched to a marker so you can scan the encoded form and the decoded form together.
Short explanations of `iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, `jti`, `azp`, `scope`. Hover the key to remind yourself what RFC 7519 requires.
Timestamps render with an ISO 8601 string and a relative readout. Expired tokens trigger a warning banner so you do not waste time chasing a 401.
Unsigned tokens look indistinguishable from real ones to the eye. The decoder flags `alg: none` immediately so you do not trust one by accident.
Every keystroke triggers a re-decode and re-render. Pasting a token, fixing a typo, slicing off a header — all visible without a button press.
The decoder handles the `-` and `_` substitutions and missing padding that JWTs require. Plain Base64 also works; we normalize before decoding.
Intentional. Verifying a signature requires the signing key — paste a key into a browser at your own risk. Use this tool to inspect, not to authenticate.
Use it anonymously, on as many tokens as you want. No account, no cookies, no usage counter. The network tab will confirm nothing goes out.
When a 401 lands and you need to see why.
When a request returns 401 and you can't tell whether the token is malformed or just expired, drop it in here. Three seconds later you know which.
Identity providers shape their custom claims differently. Decode once to learn exactly which keys (`https://yourdomain/roles`, `azp`, etc.) the provider issues — then write strict typings against them.
When a partner says "use the bearer token from our system," decode it before plumbing it through your stack. Surfaces audience mismatches and stale algorithms in seconds.
A user pastes their broken token into a support ticket. Decode it locally to see the role/scope claim, confirm the expiry, and reproduce the exact 403 they hit.
Some auth setups bake the entire user profile into a JWT. Decode yours and confirm you are not shipping PII into every request — emails, phone numbers, addresses do not belong in a bearer.
Kubernetes, GCP, and AWS STS tokens are all JWTs. Decode to see the service-account binding, the issuer, and the audience — useful when a CI step fails with a cryptic "permission denied".
JWT decoding, the plain answers.
No. The decoder splits the string on dots, base64-decodes the first two segments, and parses them as JSON — all in this browser tab. No network call is made for your token. Verify by opening DevTools → Network while you paste.
No, by design. Signature verification requires the signing key — either the HMAC secret (symmetric algorithms like HS256) or the public key (asymmetric algorithms like RS256). Pasting a secret into a browser-side tool is a bad pattern, so we do not invite it. Use this tool to inspect the contents; verify on a server or with a CLI like `jwt-cli`.
The `iat`, `nbf`, and `exp` claims are Unix epoch seconds per RFC 7519. We render each as an ISO 8601 string plus a relative readout ("3 hours ago", "in 2 days"). Time zone is your browser's local zone; the underlying value is always UTC.
Clock skew. Servers usually allow a few minutes of drift before rejecting an `exp`-failed token, and our decoder uses your local clock with no tolerance. If your machine's clock is off, the readout will look wrong. Compare the `exp` value to the current Unix timestamp on your server for ground truth.
An unsigned JWT. Anyone can craft one — the structure is valid, the parse succeeds, but the signature segment is empty or arbitrary. Some libraries historically accepted "alg: none" by default, which created CVE-grade auth bypasses. Modern libraries reject it; if you see one in production traffic, treat it as a red flag.
No. JWE tokens have five dot-separated segments (header, encrypted key, IV, ciphertext, auth tag) and require the decryption key. This tool handles JWS (the signed-not-encrypted variant), which is what 99% of "JWTs" people deal with are. If yours has five segments, you have a JWE.
It is a hand-crafted HS256 example for illustration — issuer `https://auth.nimbusnexus.net`, audience `api.nimbusnexus.net`, expiry 24 hours from issue. The signature is a placeholder and will not validate against any real secret. Use it to explore the UI without copying production tokens.
Building auth into your app? NimbusNexus ships managed JWT verification.
Sign up for the free tier and you get $100 in credits, plus VMs, managed databases, object storage, and built-in JWT verification, secret rotation, and OIDC integration across four regions.