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 most common format for stateless login in REST APIs: the server issues a signed token at login, the client sends it on every request, and the server checks the signature instead of looking up the session in a database.

A JWT has three parts separated by dots: a base64url-encoded header, a base64url-encoded payload, and a signature. The header names the signing algorithm. The payload is a JSON object of "claims" about the subject and how long the token is valid. 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 or OIDC ID token. Identity providers (Google, Microsoft, Auth0, Cognito) issue JWTs full of profile claims. Decode them to see what the provider is really telling you about the user.
• Inspecting third-party tokens. Webhook signatures, signed download URLs and magic-link tokens are often JWTs.
• Checking a token's lifetime. The status row above tells you at once whether the token is expired, not yet valid, or unsigned.

How JWTs work

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

Common algorithms are HS256 (HMAC-SHA256, shared secret), RS256 (RSA-SHA256, public and private key) and ES256 (ECDSA over P-256). Server-side libraries verify the signature; clients only carry the token. Being able to read a JWT does not mean you can trust it. That is 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 (usually 15 minutes to 24 hours later) and a custom roles claim. The client stores it and sends it on the next 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 shows 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 does not match your app's client ID, the token is not meant for you.

Common mistakes

• "alg: none" attacks. Some older libraries accepted tokens with "alg": "none" (unsigned) when set up carelessly. If the status above flags an unsigned token, never trust it, even if every claim looks right. Your library should reject none outright.
• Not checking 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 made for another service could be used against yours.
• Clock skew. exp and nbf are absolute timestamps. If your server clock drifts even a few seconds, valid tokens get rejected. Most libraries allow a small leeway (for example 30 seconds) for this reason.
• Secrets in the payload. The payload is base64-encoded, not encrypted. Anyone who has the token can read every claim. Keep sensitive data on the server and put only a reference in the token, or use JWE (encrypted JWTs).
• Long-lived tokens. A revoked JWT keeps working until it expires, unless you keep a deny list. Short lifetimes plus refresh tokens are better than 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 no network calls while decoding.

Why does it not verify the signature?

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

What is 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 that the issuer looks up on its server. JWT is the popular choice because it can be checked without a database lookup.

Are JWTs encrypted?

Plain JWTs (JWS) are signed, not encrypted. Anyone with the token can read the payload. JWE adds encryption; it is less common and a little heavier.

Is it safe to put a JWT in the URL?

Usually no. URLs end up in server logs, referrer headers and browser history. Send tokens in the Authorization header or a Secure, HttpOnly cookie.