JWT Decoder / Verifier
The JWT decoder splits a JSON Web Token into its three Base64Url-encoded parts — header, payload, and signature — and displays the header and payload as formatted JSON.
JWT Token
Usage
• Decode: parses the three Base64Url parts; time fields (iat/exp/nbf) shown in local time, exp highlighted when expired
• Verify: picks HS/RS from Header.alg and checks the signature with your secret / public key
• Tokens are never uploaded; all parsing and verification run locally in your browser
What the JWT decoder is for
The JWT decoder splits a JSON Web Token into its three Base64Url-encoded parts — header, payload, and signature — and displays the header and payload as formatted JSON. Time claims (iat, exp, nbf) are converted to human-readable local time, and an expired exp is highlighted. A signature verification section lets you check HS256/384/512 signatures with a secret or RS256/384/512 signatures with a PEM public key, all running locally in the browser.
Use this tool to inspect claims and verify supported HS/RS signatures locally with a supplied key. Decoding, signature verification and application authorization are separate steps; a readable payload is not evidence of a trustworthy token.
Frequently asked questions
Can this tool verify JWT signatures?
The tool can verify HS256/384/512 and RS256/384/512 signatures locally with the appropriate secret or PEM public key. A valid signature establishes integrity relative to that key, not full authentication. Production validation must also enforce algorithms, issuer, audience, time constraints and authorization.
What is the difference between decoding and verifying a JWT?
Decoding reads the Base64url header and payload without a key. Verification checks integrity relative to the supplied key. Trust also requires an expected issuer and key, allowed algorithms, audience, time constraints and application authorization rules.
How do I verify an HS256 vs RS256 token?
HS256 uses a shared secret (a string). RS256 uses an RSA key pair — paste the PEM public key (SPKI format, beginning with -----BEGIN PUBLIC KEY-----) in the verification field. The tool picks the right algorithm from the Header.alg claim.
The exp claim shows 'expired' but the token still works — why?
The server validating the token may have clock skew tolerance configured (e.g. ±60 seconds), or the expiry is evaluated differently (e.g. sliding windows). The decoder shows what the exp claim says literally.
References and result limitations
Local results depend on the input and selected options. Retain the input example, format and processing rules when citing a result, and verify the output. Keep keys and other sensitive material out of public examples.
These references explain protocol or format rules; they do not endorse results produced by this site.