JWT Generator
Build and sign a JWT with HS256, HS384 or HS512 for testing.
Check a JWT signature against a secret or a public key, and see why it fails.
Only the public key is needed to verify an RS, PS or ES token. A private key should never be pasted into a web page.
The JWT Verifier checks a signature against an HMAC secret or an RSA or EC public key, and reports the signature result separately from the expiry check — because a token can be perfectly signed and still unusable.
Decoding a token tells you what it says; verifying tells you whether to believe it. This checks the signature, and separately checks the time claims, because a token can be perfectly signed and still expired — and the two failures need different fixes.
HMAC algorithms take a shared secret. RSA and ECDSA algorithms — RS256, PS256, ES256 and their larger siblings — take the public key in PEM form, which is safe to paste because it is public by definition. When verification fails the message says which thing failed: a signature that does not match, a key in the wrong format, an algorithm the token declares but the key cannot support, or simply an expired token.
HS256 through HS512 with a shared secret, and RS, PS and ES algorithms with a PEM public key.
Signature validity and claim validity are reported separately, because they fail for different reasons and need different fixes.
A wrong secret, a key in the wrong format and an algorithm mismatch each produce their own message rather than a generic failure.
The HMAC comparison does not short-circuit on the first differing byte, out of habit rather than necessity.
Verification uses the browser’s own crypto; nothing is transmitted.
The algorithm is read from the header, so the right key type is expected automatically.
A shared secret for HS algorithms, or a PEM public key for RS, PS and ES.
Signature valid or not, stated separately from the expiry check.
exp and nbf are evaluated against the current time and reported in plain English.
The public key, in SPKI PEM form — the block beginning "-----BEGIN PUBLIC KEY-----". The private key is never needed to verify, and should never be pasted anywhere.
Usually the wrong secret, or a secret that is base64-encoded at rest and needs decoding before use. Occasionally the token was copied with a trailing space or a line break in the middle.
Yes. A signature proves the token has not been altered; it says nothing about whether it has expired, been revoked, or is meant for a different audience. All three are reported separately.
No. Verification uses the browser's own crypto. A public key is safe to paste anyway; a shared secret should still be rotated if you paste it into any web tool.
What people who use the JWT Verifier think of it. Reviews come from visitors and are posted as written.
No ratings yet
Yours would be the first.
0 reviews
Newest first
No reviews yet
Be the first to rate the JWT Verifier. It takes half a minute and no account.
Write the first reviewBuild and sign a JWT with HS256, HS384 or HS512 for testing.
Collapse nested JSON into one flat level of dot-notation or bracket keys.
Build CSS keyframe animations and watch them run as you edit.
Measure text in UTF-8 bytes, code points, UTF-16 units and graphemes.
Build media queries with framework breakpoints and modern features.
Validate an IBAN's length, country and mod-97 checksum, and generate test ones.
Rebuild nested JSON from flat dot-notation or bracket-notation keys.
Check XML is well-formed and find the exact tag that breaks it.