JWT-Inspektor

JSON Web Tokens are everywhere modern authentication happens: OAuth2 access tokens, session cookies, API keys, single sign-on. They look like cryptic gibberish but are really just three Base64-encoded parts separated by dots. The JWT Inspector makes them readable and answers the questions you actually have while debugging: what is inside, who is it for, and when does it expire?

You paste your token - an optional Bearer prefix is stripped automatically - and immediately see three cleanly separated panels. The header reveals the signature algorithm and optionally the key ID. The payload shows all claims, with standard claims like iss, sub, aud, exp, nbf, iat and jti explained in plain language so you do not have to look up what each abbreviation means. The signature is shown as its own block.

The most useful practical helper is the expiry display. Instead of converting a Unix timestamp in your head, you get a clear status banner - valid, expiring soon or expired - along with a live ticking countdown. A token without an exp claim is flagged too, because a token that never expires is rarely a good idea. A timeline shows issuance, valid-from and expiry relative to each other.

For HMAC-signed tokens (HS256, HS384, HS512) you can check directly whether the signature is correct: you enter the secret, and the inspector recomputes the signature via your browser's Web Crypto API and shows with a green or red badge whether it is valid. For asymmetric methods like RS256 or ES256 the inspector shows the algorithm and an assessment of its security; the cryptographic verification of these signatures with a public key is not part of this tool's job.

Beyond the pure inspector there are two more modes. The token builder assembles a new HS-signed token from a header, a payload and a secret - handy for testing. The compare mode puts two tokens side by side and marks claim by claim what is identical, what differs and what exists only in one of them - worth gold when a login works sometimes and not others.

A size warning speaks up when your token approaches the usual HTTP header limits, because overloaded tokens are silently rejected by some servers and proxies. Ready-made example tokens - from a standard HS256 through an expired one to a German authority scenario - help with trying things out and learning.

Everything runs 100% client-side. Your token, your secret, your claims - none of it is sent to a server or stored. With credentials that is not just fast but the only defensible way to work. No account, no signup, no data leaving your device.