{"alg":"HS256","typ":"JWT"}{"sub":"1234567890","name":"Juan dela Cruz","role":"member","iat":1756400000,"exp":1756486400}No secret was needed to produce either of those. They were read straight out of the token above.
A JWT is signed, not encrypted. That single sentence is the reason this page shows you the decoded payload right beside the token.
The middle section of a JWT is base64url — an encoding, which anyone can reverse, not a cipher, which needs a key. Everyone who holds the token can read every claim in it. The signature does something different and narrower: it proves the token has not been altered since you signed it. It hides nothing.
People put passwords, identity numbers and internal flags into payloads because the token looks encrypted — a long opaque string that means nothing to the eye. A generator that showed only that string would be helping the reader believe the wrong thing, so this one decodes it back for you and names any claim whose key looks like a secret.
There is no "none" algorithm here and there never will be. An unsecured token can be forged by anybody, and a server that honours one has no authentication at all. A header that tries to set the algorithm is refused rather than quietly overwritten — you should find out that you cannot make one, not believe that you did.
Timestamps are seconds, not milliseconds. exp, iat and nbf are seconds since the epoch; Date.now() is milliseconds. Pass one straight through and your token expires roughly fifty thousand years from now, and nothing anywhere will complain.
No, and this is the misunderstanding the whole page is built around. The payload is base64url — an encoding, not a cipher. Anyone holding the token can read every claim in it without the secret, which is why this page shows you the decoded payload next to the token rather than hiding it. The signature proves the token has not been altered; it hides nothing at all.
Anything you would not print on a postcard. Passwords, national identity numbers, card details, internal flags you would rather a customer did not see. Put a reference in the token — a user id — and keep the value on the server where it belongs. This page names any claim whose key looks like a secret, but it can only see the name, not what you meant by it.
Because an unsecured JWT can be forged by anybody, and a server that accepts one has no authentication at all. It is the specification’s most exploited corner. This generator will not produce one, and it refuses a header that tries to set the algorithm rather than quietly overwriting it — you should find out that you cannot, not believe that you did.
HS256 unless something on your side requires otherwise. All three are HMAC over a shared secret and all three are sound; HS384 and HS512 use a wider hash and produce a longer signature, which makes the token bigger without making a well-chosen secret meaningfully harder to guess. The weak link in an HMAC-signed JWT is almost always the secret, not the hash — so a longer secret buys you far more than a longer algorithm name.
RS256 and ES256 need RSA or elliptic-curve key handling, which is a much larger surface than a token generator should carry, and half a signature scheme is worse than none. The three offered here are the whole HMAC family, implemented from the specification with no dependencies — the hashes are verified against the published FIPS 180-4 and RFC 4231 test vectors.
You used milliseconds. JWT timestamps — exp, iat and nbf — are seconds since the epoch, and Date.now() gives you milliseconds, so a value passed straight through is a thousand times too large. No library rejects it and nothing looks wrong, which is why this page flags a timestamp that is too big to be a plausible second count. Divide by 1000.
At least 32 random bytes. An attacker who obtains one token can test guesses against it offline, as fast as their hardware allows and without touching your server — so a memorable passphrase is not enough. Generate one on the secret key page rather than inventing it.
No, this only signs. It is also worth saying that verifying a token means checking the signature with the secret and then checking the claims — the expiry, the issuer, the audience. Decoding a token and reading its claims without verifying the signature is not authentication, however convincing the payload looks.
Two of the three are plain text in disguise. Only the third needs the secret.
Integrity, not confidentiality. If you need the second, encrypt the value before it goes in — or better, keep it on the server and put a reference in the token.
Signed in your browser; the secret is never transmitted or stored. A JWT is signed, not encrypted — treat everything in the payload as public. This is a development tool, not a security review. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.