🔒 Runs in your browser · tokens never uploaded
JWT Decoder & Inspector
Paste any JSON Web Token to decode the header and payload, see every claim, get a human-readable expiry status, and catch common security warnings. Fully client-side — your tokens stay on your device.
✔ 100% Free
✔ No signup
✔ Works offline
✔ Tokens never leave your browser
What this tool does
Takes a JWT (three base64url-encoded segments joined by dots) and decodes the first two segments into readable JSON. Then it inspects the result for common security issues and time-based status — whether the token is expired, not yet valid, signed with alg: none, or missing a recommended claim. Everything runs in your browser; the token is never sent anywhere.
What it shows you
- Header — the algorithm (
alg), token type (typ), key identifier (kid), and any other header fields.
- Payload — the full set of claims in the token, including registered claims (
iss, sub, aud, exp, nbf, iat, jti) and any custom claims your application set.
- Expiry status — the token is automatically checked against the current time and marked VALID, EXPIRED, or NOT YET VALID.
- Security warnings — flags
alg: none tokens, missing exp claims, and very long-lived tokens.
- Signature — the third segment is displayed (it's not human-readable) so you can confirm it's present and see which algorithm produced it.
What it explicitly does NOT do
- Verify the signature. Verifying requires the secret key (HS256) or public key (RS256, ES256, EdDSA). That is a server-side operation that belongs in your auth middleware, not a browser tool. Always verify signatures in production code — never trust a JWT just because it decodes.
- Send tokens anywhere. All decoding is base64url in JavaScript, on your device.
- Generate or sign new JWTs. Token creation belongs in your backend with proper key management. Browser-side JWT generation is almost always the wrong answer.
Common JWT claims (registered)
The JWT spec (RFC 7519) defines a small set of standard claim names. Most applications use them in addition to custom claims.
iss — issuer. The principal that issued the JWT. Usually the URL of your auth server (e.g. https://auth.example.com).sub — subject. Who the token is about. Typically the user ID.aud — audience. Who the token is intended for. Used so a token issued for service A isn't accepted by service B.exp — expiration time. Unix timestamp (seconds) after which the token must not be accepted. Required for any non-trivial use.nbf — not before. The token must not be accepted before this time.iat — issued at. When the token was issued. Useful for age checks.jti — JWT ID. A unique identifier. Useful for replay-prevention or revocation lists.
JWT algorithms in 2026
The algorithm header field tells the verifier which cryptographic algorithm was used to sign the token. The common choices:
- HS256 / HS384 / HS512 — HMAC with SHA-2. Symmetric: the same secret signs and verifies. Fine for internal services where one side trusts the other; not appropriate when the verifier shouldn't be able to issue tokens.
- RS256 / RS384 / RS512 — RSA-based. Asymmetric: private key signs, public key verifies. The traditional choice for OAuth / OIDC, but RSA keys are large and verification is slower than ECDSA.
- ES256 / ES384 / ES512 — ECDSA with curves P-256 / P-384 / P-521. Smaller keys, faster verification than RSA. The recommended default for new asymmetric JWTs.
- EdDSA (Ed25519) — modern signature scheme. Strongest contemporary recommendation; widely supported as of 2026.
- PS256 / PS384 / PS512 — RSA-PSS. RSA with a probabilistic padding scheme that's safer than PKCS#1 v1.5 padding used by RS256.
- none — no signature. This is a known security footgun: a JWT with
alg: none can be modified freely and still "verify" if your code accepts it. Production verifiers should always reject alg: none. This tool flags it loudly.
What can go wrong with JWTs in production
JWTs are simple to use and easy to mis-use. A short list of the most common production mistakes, all of which a decoder helps you spot quickly:
- Accepting
alg: none. If your verification code doesn't explicitly reject unsigned tokens, an attacker can forge a JWT trivially.
- Algorithm confusion (RS256 → HS256). If your code uses the algorithm declared in the token rather than the algorithm you expect, an attacker can submit a JWT signed with HS256 using your public key as the HMAC secret, and your verifier will accept it.
- No expiration. A token without
exp is forever-valid. If it leaks, you have no way to time-bound the exposure.
- Very long expirations. A 90-day access token has 90 days of exposure if it leaks. Use short access tokens (5–15 minutes) with refresh tokens for long-lived sessions.
- Missing
aud. Without an audience claim, a token issued for one service can be replayed against another.
- Storing JWTs in localStorage. Vulnerable to XSS. HttpOnly cookies are usually safer.
- Relying on revocation lists for "logout." JWTs are stateless by design. If you need server-side revocation, either keep tokens short-lived (and use refresh tokens) or accept the operational cost of a revocation cache.
For deeper background on JWT security, the OWASP JWT cheat sheet is the canonical reference.
Frequently asked
Is this JWT decoder safe to use with real tokens?+
Yes. The decoder runs entirely in your browser using JavaScript. Tokens are never sent to any server, never logged, and never stored. The base64url decoding happens locally on your device. That said, JWTs are by design readable by anyone who has them — if a token is sensitive, the right answer is to rotate it after decoding, not to avoid decoding it.
Can this tool verify the JWT signature?+
No. This tool decodes the JWT but does not verify the signature, because verifying requires the secret key (HS256) or the public key (RS256, ES256, EdDSA) that signed it. Signature verification is a server-side operation that should happen in your auth middleware using the issuer's published JWKS endpoint or your own shared secret — not in a browser tool. Always verify signatures in production code, never trust a JWT solely because you can decode it.
What does it mean if my JWT shows "alg: none"?+
An algorithm of none means the JWT is unsigned — anyone can modify the payload and the token will still "work" if your verification code accepts unsigned tokens. This is a known vulnerability category. Any JWT verification library should reject alg=none by default in production. If you're inspecting a token with alg=none, treat it as untrusted.
Why is the signature shown but not decoded?+
The third part of a JWT is the cryptographic signature, which is a binary blob encoded with base64url. It is not meant to be decoded into human-readable text — it's a check value that the recipient uses to verify the token wasn't tampered with. The tool displays it so you can see it's present and what algorithm produced it, but the raw bytes aren't meaningful on their own.
What are common JWT claims?+
The most common registered claims are: iss (issuer), sub (subject — typically the user ID), aud (audience), exp (expiration timestamp), nbf (not-before timestamp), iat (issued-at timestamp), and jti (JWT ID). Beyond these, applications add custom claims like email, roles, scope, tenant_id, etc. The decoder displays all claims found in the payload.
How can I tell if my JWT is expired?+
The decoder automatically checks the exp claim against the current time and flags the token as EXPIRED or VALID. The exp claim is a Unix timestamp (seconds since 1970-01-01 UTC), and a token is considered expired when the current time exceeds exp. Some libraries allow a small clock-skew tolerance (usually 30 seconds). The decoder also checks nbf (not-before) to flag tokens that aren't yet valid.
What JWT algorithms does this tool support?+
The decoder displays any algorithm declared in the header, including HS256/HS384/HS512 (HMAC with SHA-2), RS256/RS384/RS512 (RSA), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), and EdDSA (Ed25519). Decoding the header and payload is the same regardless of algorithm — the algorithm only matters for signature verification, which this tool doesn't perform. For new tokens in 2026, ES256 and EdDSA are the recommended algorithms.