Free Online JWT Decoder & Inspector

About this tool

This free online JWT decoder lets you inspect token header and payload claims instantly, including exp/iat/nbf checks and common structure validation. All decoding runs locally in your browser - no uploads and no server-side processing. Use it to debug authentication flows, verify what your app is actually receiving, and quickly export decoded sections for incident response or logging.

Common use cases

• Inspect header and payload claims during OAuth/OpenID debugging
• Check token expiration (exp), issued-at (iat), and not-before (nbf)
• Confirm issuer (iss), audience (aud), subject (sub), and scopes/roles
• Copy or download decoded sections for troubleshooting and reporting
• Optionally verify HS256/384/512 signatures when you have the shared secret

How it works

JWTs are three base64url-encoded parts: header, payload, and signature. This tool decodes the header and payload by base64url decoding and JSON parsing, then evaluates time-based claims (exp/iat/nbf) against your local clock. Signature verification is optional: when you provide a shared secret for HS* algorithms, the tool computes the expected HMAC and compares it to the token signature - all locally in the browser.

FAQ

Does this JWT decoder upload my token

No. Decoding and optional verification run locally in your browser.

Does decoding a JWT mean the signature is valid

No. Decoding only reveals the contents. Signature validity requires verification (HS* verify is available when you provide the secret).

Why do exp/iat/nbf checks show as invalid

Most issues come from clock skew, tokens being used too early (nbf), or expired tokens (exp). Confirm your system time and token issuance settings.

JWT structure in depth

A JWT is three base64url-encoded segments joined by dots: header.payload.signature. The header identifies the algorithm and token type. The payload carries claims — assertions about the subject, issued time, expiry, audience, and any application-specific data. The signature is a cryptographic binding: it proves the header and payload have not been modified since the token was issued.

The base64url encoding used in JWTs is a URL-safe variant: + becomes -, / becomes _, and padding characters (=) are omitted. This is intentional so JWTs can appear in query strings and HTTP headers without URL encoding. This decoder handles the padding normalization automatically — you do not need to manually pad tokens before pasting.

Registered claims and what they mean

The JWT spec (RFC 7519) defines a set of registered claim names with specific semantics:

• iss (Issuer) — who created the token, typically an auth server URL or service identifier
• sub (Subject) — the principal the token refers to, often a user ID
• aud (Audience) — the intended recipient(s); services should reject tokens where they are not the audience
• exp (Expiration) — Unix timestamp after which the token must not be accepted
• nbf (Not Before) — Unix timestamp before which the token must not be accepted
• iat (Issued At) — when the token was created; used to calculate token age
• jti (JWT ID) — unique identifier for the token, used to prevent replay attacks

All other claims in the payload are application-defined. Common examples include roles, scope, email, name, and org_id. These are not validated by this decoder — they are surfaced for inspection.

Algorithm security considerations

HS256/384/512 (HMAC with SHA-2) use a shared symmetric secret. Both the issuer and every verifier must have the same secret. This is suitable when all parties are trusted, but it means any party that can verify tokens can also forge them. If your architecture has multiple independent services verifying tokens, a compromise of any one service exposes the signing key.

RS256/384/512 (RSA with SHA-2) use a key pair. The issuer signs with the private key; verifiers check with the public key. The public key can be distributed without risk — no party that only holds the public key can forge tokens. This is the standard choice for OAuth 2.0 and OIDC deployments where multiple resource servers need to verify access tokens.

ES256/384/512 (ECDSA) provide similar asymmetric properties to RSA but with shorter key sizes and faster verification, making them increasingly common in high-throughput APIs. alg: none means no signature — tokens with this algorithm should never be accepted by a production service. This decoder flags alg: none explicitly.

When NOT to use this decoder

This tool is for inspection and debugging, not for production token validation. Do not use the decoded output of this tool as proof that a token is valid for authorization decisions. A decoded JWT can be read by anyone who has the token — the claims are not encrypted (unless you are using JWE, which this tool does not handle). For production verification, use a server-side JWT library with your public key or secret, an audience check, an expiry check, and an issuer check all enforced together.

Also note: this tool cannot verify RS256, ES256, or other asymmetric algorithms — those require the public key, which is not something you should paste into a browser tool. Only HS256/384/512 verification is available here, and only when you have the HMAC secret and understand that it never leaves your browser.

Debugging JWT issues in practice

The most common JWT debugging scenario is an API returning 401 when a token should be valid. Paste the token here first to confirm the basics: is the exp in the future? Is the aud claim set to the correct service? Is the iss what your service expects? Is the algorithm what your verification code handles?

Clock skew is a frequent production issue: if the issuing server and verifying server have clocks that differ by more than the token's leeway window, tokens will appear expired or not-yet-valid even when freshly issued. A 30-60 second skew allowance is common but must be configured explicitly in most JWT libraries.

For incident response scenarios involving leaked JWTs, the exp claim tells you exactly when the token expires. The jti claim (if present) can be used to revoke the specific token via a deny-list. If neither is practical, rotating the signing secret immediately invalidates all outstanding tokens for HS* algorithms. See the incident response toolbelt guide for a broader workflow that includes JWT inspection.