Why only HS256, and why that's a deliberate scope limit

HS256 is a symmetric algorithm — the exact same secret both signs and verifies a token, which is exactly why this tool can offer signing at all: you supply a secret you control, and the tool produces a token any system holding that same secret can verify. Asymmetric algorithms like RS256 or ES256 work differently — signing requires a private key, verification only needs the corresponding public key — and minting a token under one of those algorithms for a service you don't control would require that service's private key, which by design no one outside that service should ever have. This tool sticking to HS256 isn't a missing feature; it's the only case where "sign a test token" is a well-posed, legitimate thing to ask a browser tool to do.

What this is actually for

The practical use case is testing your own systems: you're building or debugging something that consumes JWTs — an API gateway, a middleware layer, a test suite — and you need real, validly-signed tokens with specific claims to exercise it against, without spinning up a full auth server just to mint one token. Since you already control the secret in that scenario (it's the test secret your own system is configured to verify against), signing locally in the browser is exactly as trustworthy as signing it any other way — the token is only ever as good as the secret behind it, and that secret never leaves your machine here.