JWT inspector

A JSON Web Token is three base64url strings joined by dots: header.payload.signature. The first two are not encrypted — they are encoded, which means anyone holding the token can read them. Paste one here and this page shows you the header and the payload decoded, turns the timestamp claims into real dates, and then does the part a plain decoder does not: it reads the token the way someone trying to forge it would.

What it flags

The header's alg set to none — a token with the signature switched off, which a careless verifier will accept. HMAC algorithms (HS256 and kin), where the same secret signs and verifies, so a guessable secret means a forgeable token. The jku and x5u headers, which tell the server where to fetch its verifying key and, trusted blindly, let an attacker supply their own. A kid that could be bent into path traversal or SQL injection. A missing or absent exp, which makes a leaked token a permanent one. No aud, which lets a token minted for one service be replayed against another. And payload claims that should never be in a readable token at all — passwords, keys, personal data — alongside the privilege claims (role, scope, admin) that forgery is usually aimed at.

The secret test

When the token is HMAC-signed, the inspector can run a list of common and default secrets against it — secret, changeme, framework defaults, the string jwt.io pastes into its own examples — and tell you if one of them is the key. It does this by computing the HMAC of the token's own header and payload with each candidate and comparing it to the signature already on the token, all with the browser's built-in crypto. A match means the secret is weak enough that anyone could mint a valid token for any user, any role. It tests common words only; it is not a full brute-forcer, and a token it clears is not thereby proven strong — only not trivially weak.

Nothing you paste leaves your browser

The decoding and the secret test happen in this page, on your machine. There is no upload, no account, and no server to send anything to; the page makes no network request carrying any part of the token. That matters more here than for most tools, because a real JWT is often a live session — paste it into a server-side decoder and you have handed that session to whoever runs the server. Our analytics records that the tool was used and whether a token decoded, and never sees the token.

If you want the longer version of how these tokens are attacked and defended, the writing covers it, and passkeys vs passwords vs 2FA and your CSP probably does nothing are the nearest neighbours.