JWT Signature Generator
Work directly with the signature part of a JSON Web Token. Paste header.payload to sign it with a secret or private key, or paste a complete token to check whether its signature matches the secret or public key you have. The page shows the signing input, the signature in Base64URL and hexadecimal, a clear valid or invalid verdict, and warnings about alg "none" and algorithm mismatches.
- Runs in your browser
- No sign-up
- Free to use
How to use JWT Signature Generator
- Paste a full token or only its first two parts.
- Keep “From the token header” or choose the algorithm you expect.
- Enter the secret, the private key (to sign) or the public key (to verify).
- Read the verdict and copy the signature or re-signed token.
JWT Signature Generator features
Sign and verify
Create a signature or check an existing one in one place.
All JWS algorithms
HS256–512, RS256–512, PS256–512, ES256–512 and EdDSA.
Two encodings
Signature as Base64URL and hexadecimal.
Attack warnings
Flags alg "none" and header/algorithm mismatches.
Key formats
Secrets as text, Base64 or hex; keys as PEM or JWK.
Local only
Web Crypto in your browser; nothing is transmitted.
When to use JWT Signature Generator
- Finding out why a service rejects a token with “invalid signature”.
- Checking which of several secrets a test token was signed with.
- Re-signing a modified payload in a test environment.
- Comparing your library’s signature with a reference value.
JWT Signature Generator FAQ
What exactly is signed in a JWT?
The ASCII text “header.payload”: the Base64URL-encoded header, a dot and the Base64URL-encoded payload, exactly as they appear in the token. Re-encoding the JSON differently changes the signature.
Why does my HS256 signature not match?
The usual causes are a different secret (check the encoding: plain text versus Base64), extra whitespace, or a header or payload that was re-encoded. The signature covers the exact characters.
Why are ES256 signatures different every time?
ECDSA and RSA-PSS use a random value in each signature, so signing the same input twice gives different results. Both verify correctly.
Should a verifier read the algorithm from the token?
No. The verifier should know which algorithm it accepts and reject anything else. Trusting the header enables attacks such as switching to “none” or confusing RSA with HMAC.
Can I verify with only a public key?
Yes, for RS, PS, ES and EdDSA tokens. Creating a signature needs the private key.
Is this the same as the JWT Decoder?
The decoder focuses on reading claims and expiry. This tool focuses on the signature: computing it, comparing it and showing it in different encodings.
The signature part of a JWT
The third part of a JSON Web Token is what makes it trustworthy. It is computed over the signing input, which is the encoded header and payload joined with a dot, using the algorithm named in the header and a key known to the issuer. Anyone can read and modify the first two parts, but without the key they cannot produce a matching signature, so a verifier that checks the signature detects any change.
For HMAC algorithms the signature is a keyed hash: the same secret and input always produce the same signature, which makes comparing two values meaningful. This page shows the result in Base64URL, the form used in tokens, and in hexadecimal, the form many libraries and debugging tools print. Comparison of a token’s signature is done by verification, which avoids timing differences.
Asymmetric algorithms behave differently. RSA PKCS#1 v1.5 signatures are deterministic, but ECDSA and RSA-PSS include randomness, so a new signature never equals the old one. What matters is whether the public key verifies the token’s signature. With only a public key you can verify but not sign; that separation is exactly why services that merely check tokens should hold public keys only.
Most JWT vulnerabilities come from verification logic, not cryptography. Accepting alg "none", reading the algorithm from the token instead of configuring it, using an RSA public key as an HMAC secret, or skipping the signature check in some code paths have all led to real breaches. The warnings on this page point out those patterns when a token shows signs of them.
When a signature fails, work through the inputs one at a time: confirm the algorithm, then the key and its encoding, then whether the header or payload text changed in transit, for example through added whitespace or a re-serialised JSON body. Because the signature covers exact characters, even a harmless-looking change produces a completely different value.