security · Browser tool
JWT Token Inspector
Split a token into its three parts, read the header and payload, and turn the time claims into dates you can actually check. Signature verification is optional and needs a key you supply.
Token
Decoding is not trust. Anyone holding a token can read its payload — that is what the panels below do. A token only means something once its signature has been checked against a key you already trust, and only the issuer's server can do that properly.
Header
Payload
Claims
| Claim | Value | Reading |
|---|
Times are shown in your local zone and in UTC. Registered claims follow RFC 7519; anything else is application-specific.
Signature
Paste the matching entry from the issuer's JWKS document. Only the public half is needed, and it stays on this page.
What a JWT actually is
Three Base64URL strings joined by dots. The first two are JSON — a header saying which algorithm signed the token, and a payload of claims. The third is a signature over the first two, byte for byte as they appear in the string. That last detail matters: a verifier must sign the original header.payload text, not a re-serialised version of the JSON, because key order and whitespace would change and the signature would fail.
Padding and why decoders disagree
Base64URL in a JWT drops the trailing = characters. Some decoders insist on them and choke; this one adds them back before decoding. If a token decodes here but not in your library, the padding rule is the first thing to check.
alg: none
The JWT specification defines an unsecured token where the algorithm is none and the signature is empty. Several libraries once accepted such a token as valid, which let an attacker strip the signature off a real token, change the payload, and be believed. Any verifier you write should decide the acceptable algorithm from your own configuration and reject whatever the token's own header claims, rather than trusting the header to pick the check.
What verification here can and cannot do
HMAC algorithms (HS256, HS384, HS512) use one shared secret for signing and verifying, so pasting the secret is enough and the check is exact. RS, PS and ES algorithms sign with a private key and verify with a public one, so verification needs the issuer's public key. You can paste it as a JWK and the check runs through crypto.subtle.verify in your browser. Fetching a JWKS document automatically would mean a network request, which this page does not make — copy the key across yourself. Nothing here checks whether a key has been revoked, whether the issuer is who you think, or whether aud matches your service. Those are your application's job.