All tools

JWT Signer

JWT

Sign JWTs with HS256/RS256

This is the counterpart to JWT Decoder: instead of inspecting an existing token, you fill in header and payload claims and actually sign one, either with HS256 and a shared secret for a quick test against an API expecting bearer tokens, or with RS256 and a private key to mirror how a production auth server issues tokens for staging tests. Signing happens entirely in the browser, so secrets and private keys never leave your machine, but that's also the reason this isn't meant for real token issuance; production auth should run server-side with proper key storage and lifecycle management, not in a browser tab. The HS256/RS256 distinction matters operationally: HS256 uses one shared secret for both signing and verification, while RS256 splits signing (private key) from verification (public key), which is the safer choice when multiple services need to check tokens without being able to mint new ones.

jwtsignhmacrsa

How to use JWT Signer

  • 1.Fill in header and payload claims, choose HS256 with a shared secret, and generate a signed JWT for testing an API that expects bearer tokens.
  • 2.Switch to RS256 and paste a private key to sign tokens the way your production auth server would, for staging environment tests.
  • 3.Use the signed token immediately in the JWT Decode tool to confirm the claims (exp, roles, sub) look exactly as your backend expects.

Frequently asked questions

Is my secret or private key sent to a server?
No, signing happens entirely in your browser — secrets and keys never leave your machine.
Should I use this to sign tokens in a production app?
No — this tool is for testing and debugging. Production token issuance should happen server-side, in your backend's runtime, using a maintained JWT library and properly secured key storage.
What's the difference between HS256 and RS256?
HS256 uses a single shared secret for both signing and verification, while RS256 uses an asymmetric key pair — sign with a private key and verify with a public key, which is safer when multiple services need to verify tokens but shouldn't be able to issue them.
Can I set custom claims and expiry?
Yes, you can add arbitrary custom claims alongside standard ones like `exp`, `iat`, and `sub`.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/jwt-sign \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"payload":{"sub":"user123","role":"admin"},"secret":"my-secret","expiresIn":3600}'

Get an API key from your dashboard · Full API docs →

Related tools

JWK ViewerParse a JSON Web Key Set (JWKS) or a single JWK and view each key's type, use, algorithm, key ID, and size in a readable tableJWTJWT Builder (unsigned preview)Build a JWT header and payload preview with standard claims — unsigned, pair with JWT Signer to sign itJWTJWT DecoderDecode and inspect JWT tokensJWT