JWT decoder and inspector

What is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe container for claims about a subject. It is the de-facto format for stateless authentication in REST APIs: the server issues a signed token at login, the client sends it on every request, and the server validates the signature instead of looking the session up in a database.

A JWT has three parts separated by dots: a base64url-encoded header, a base64url-encoded payload, and a signature. The header declares the signing algorithm; the payload is a JSON object of "claims" describing the subject and the token's validity; the signature is computed over the first two parts using a secret or a private key.

When to use this tool

• Debugging auth.Your API returns 401 but the token "looks fine"? Paste it here to see the exact exp, aud, and iss values your gateway is seeing.
• Reading an OAuth / OIDC ID token.Identity providers (Google, Microsoft, Auth0, Cognito) issue JWTs full of profile claims. Decode them to see what the upstream is actually telling you about the user.
• Inspecting third-party tokens.Webhook signatures, signed download URLs, magic-link tokens - many are JWTs in disguise.
• Spot-checking a token's lifetime.The status row above tells you immediately whether the token is expired, not yet valid, or unsigned.

How JWTs work under the hood

The header and payload are JSON objects, encoded with base64url (RFC 4648 section 5 - the URL-safe variant of Base64 that replaces + with -, / with _, and drops trailing = padding). The signature is computed over the byte string base64url(header) + "." + base64url(payload).

Common algorithms include HS256 (HMAC-SHA256, shared secret), RS256 (RSA-SHA256, asymmetric), and ES256 (ECDSA over P-256). Server-side libraries verify the signature; clients merely transport the token. A JWT you can read is not a JWT you can trust - that's what the signature is for.

Worked examples

• Login response.A successful login returns a JWT with sub (the user's ID), iat (issued at), exp (typically 15 minutes - 24 hours later), and a custom roles claim. The client stores it and sends it on subsequent requests.
• Refresh tokens.Refresh tokens often have a longer exp (weeks or months) and a narrower aud (only the refresh endpoint accepts them). Decoding them surfaces both quickly.
• OIDC ID tokens.Tokens from accounts.google.com carry email, email_verified, name, picture, and aud equal to your OAuth client ID. If aud doesn't match your app's client ID, the token isn't intended for you.

Common pitfalls

• "alg: none" attacks.Some older libraries accepted tokens with "alg": "none" (unsigned) when configured naively. If the status above flags an unsigned token, never trust it - even if every claim looks reasonable. Your library should reject none outright.
• Forgetting to verify aud and iss.A valid signature only means "someone with the key signed this". You still have to check that the issuer and audience match what your service expects. Otherwise a JWT minted for another service could be reused against yours.
• Clock skew.exp and nbf are absolute timestamps. If your server clock drifts even a few seconds, valid tokens will reject. Most libraries allow a configurable leeway (e.g. 30 seconds) for exactly this reason.
• Storing secrets in the payload.Payload is base64-encoded, not encrypted. Anyone who has the token can read every claim. Put sensitive data behind a reference instead, or use JWE (encrypted JWTs).
• Long-lived tokens.A revoked JWT keeps working until it expires unless you maintain a denylist. Short lifetimes plus refresh tokens beat 30-day access tokens in almost every case.

FAQ

Does this tool send my token anywhere?

No. Decoding happens in JavaScript inside your browser. The page makes zero network calls during decode.

Why doesn't it verify the signature?

Verifying needs the signing key. If we accepted a key from the user, we'd be encouraging exactly the wrong workflow: keys should never leave your server. Verify on your backend with a library like jose (Node), python-jose (Python), or ruby-jwt (Ruby).

What's the difference between a JWT and an OAuth access token?

OAuth defines the protocol; JWT is one format the access token can take. An access token can also be an opaque string the issuer looks up server-side - JWT is the popular choice because it can be validated without a database hit.

Are JWTs encrypted?

Plain JWTs (JWS) are signed, not encrypted - anyone with the token can read the payload. JWE adds encryption; it's less common and slightly heavier.

Is it safe to put a JWT in the URL?

Generally no. URLs leak into server logs, referrer headers, and browser history. Send tokens in the Authorization header or a Secure, HttpOnly cookie.