Skip to main content
Ink·tab
←all tools

Sign and verify with HS256/384/512

Mint a JWT for staging-auth debugging, or verify a received token against a secret.

Mode
Algorithm
Signed token
—

Everything happens in your browser. Nothing is uploaded.

When you'd use this

Debugging authentication on staging, reproducing a 401 reported by QA, spinning up a fresh token after a key rotation, or confirming that a received token was signed with a particular secret.

Two modes

  • Sign — Provide extra header fields, the payload, a secret, and an algorithm. The token comes out immediately. The header's alg and typ are filled in automatically.
  • Verify — Paste a token and a secret, and the recomputed signature is compared with the one in the token. Header and payload are shown alongside.

Supported algorithms

HS256 · HS384 · HS512 (HMAC), handled directly by the Web Crypto API. No external library is used. Asymmetric algorithms like RS256 and ES256 are intentionally omitted — PEM key parsing and import work add bundle and UI cost while the search demand is overwhelmingly HS-family.

alg: none is the unsecured JWT defined in RFC 7519 §6.1. Sign mode will produce one for debugging or learning, but verify mode unconditionally rejects alg=none tokens. Several libraries have historically accepted them by mistake (the "alg=none attack"); this tool blocks the bypass explicitly.

Secrets stay on the page

Sign and verify both run in the browser, so secrets and payloads never leave it. Production keys can still leak through screenshots or browser memory — keep this for staging or debugging keys, and follow your org's policy for production material.

When this isn't the right tool

  • Asymmetric algorithms (RS256, ES256, EdDSA) — not supported. Use a server library like jose or jsonwebtoken.
  • Production key handling — discouraged. Rotate and store keys via HSM or a dedicated secret management system (KMS).
  • JWE encryption — only JWS (signed) is covered. JWE encrypted tokens are out of scope.

Secrets stay on the page

HMAC sign and verify both run through the Web Crypto API. Secrets and payloads never leave the browser. RFC 7519 compliant — `alg: none` tokens are explicitly rejected during verification (alg=none attack guard).

Frequently asked questions

Is it safe to paste a secret here?
Sign and verify both run through this page's Web Crypto API; there are no outbound network requests. That said, production keys may still leak via screenshots or browser memory — keep this for staging or debugging keys, and follow your org's policy for production material.
Why no RS256 / ES256 (asymmetric algorithms)?
PEM key parsing and importKey work add bundle and UI cost while most search demand is HS-family. For asymmetric needs, use a server library (jose, jsonwebtoken) or jwt.io. May be added later if there is real demand.
Why does verification always fail for alg=none tokens?
RFC 7519 §6.1 unsecured JWT — but several libraries have historically accepted alg=none tokens by mistake (the "alg=none attack"). This tool explicitly rejects alg=none during verification so consumers don't accidentally bypass the check.
How does this differ from the JWT decoder tool?
JWT decoder *parses* a token's header and payload — no signature check. JWT sign accepts a secret to either produce a signed token or verify that one was signed with a given secret. Use this when you need to mint tokens or confirm authenticity.