JWT Inspector

Decode a JSON Web Token, verify its signature, and check it the way your API should — plus inspect a JWKS or OpenID Connect configuration for risky settings.

Free · no sign-up · updated 7 Oct 2026

Runs entirely in your browser. Nothing you enter leaves this page.

requests since opened: 0

Verify it yourself

This page is served with a security policy your browser enforces: it cannot open connections or load anything from other sites — not even to us.

Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).

tools v0.9.1 · build 0efa119

How to use

Paste the token (a leading "Bearer " is fine).
Read the claims, expiry and warnings.
Add the secret or public key to verify, then set your API’s rules for a clear accept / reject.
Optional: paste your provider’s JWKS or openid-configuration to check its keys and settings.

Wipe everything when I leave this tab

Token

Inspect a JWKS or OpenID configuration

Open your provider’s /.well-known/openid-configuration or its jwks_uri in another tab and paste the JSON here.

Decoding is not verifying

A JWT is three Base64url parts: a header, the claims and a signature. Anyone can decode the first two — that is why a token must never carry secrets, and why the decoded claims prove nothing until the signature is checked with the right key. Encryption needs a JWE, which this page cannot open without the private key.

Verification here uses your browser’s own WebCrypto for HS, RS, PS, ES and EdDSA, with the secret or public key you supply as PEM, JWK or a whole JWKS.

Why APIs accept tokens they should reject

Real breaches rarely come from broken cryptography. They come from validation gaps: accepting alg “none”, letting the token choose the algorithm (an RS256 public key used as an HS256 secret), trusting a kid or jku header that points to attacker-controlled keys, or skipping the audience check so a token issued for one API works on another. RFC 8725 lists these; “Validate like your API” runs the same checks with your issuer, audience and clock skew.

Keys, rotation and discovery

Identity providers publish their signing keys as a JWKS and rotate them; the kid in each token says which key signed it. Paste the JWKS or the openid-configuration document to see every key’s type, size and thumbprint, whether private material leaked into a public set, and risky settings such as implicit flow or missing PKCE. For HS256, the shared secret should be at least 256 random bits — the Secret Generator makes one.

Common questions

Is it safe to paste a JWT into an online decoder?

Only if the page cannot send it anywhere. A valid token works like a password for as long as it lives. This page is locked by your browser so it cannot make connections, which you can test with the “Test the lock” button.

How do I verify a JWT signature?

Paste the token, then add the shared secret (HS256) or the public key (RS256, ES256, EdDSA) as PEM or JWK. For providers such as Entra ID, Okta or Auth0, paste their JWKS and choose “Use these keys to verify”.

Why should an API reject a token with a valid signature?

A signature only proves who issued the token. The API must also check the issuer, the audience (that the token was meant for this API), the algorithm and the expiry — “Validate like your API” runs those checks.

Known limitations

Can’t fetch keys from a JWKS URL — paste the JSON instead.
Encrypted tokens (JWE) can’t be read without the decryption key.
Your framework may add checks beyond these (scopes, custom claims).
Browser extensions can read any page — use a private window for sensitive data. How the lock works