Skip to content
yutils
Example

Input (Payload + Secret + Algorithm)

Payload:
{ "sub": "123", "name": "Alice", "exp": 1815000000 }

Secret: your-256-bit-secret
Algorithm: HS256

Output (signed JWT)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWxpY2UiLCJleHAiOjE4MTUwMDAwMDB9.q3w...

Note

Uses Web Crypto API HMAC-SHA. Same input → same token (deterministic). As long as the secret is kept safe, the token cannot be forged externally.

Usage / FAQ

When to use

  • Quickly issue API auth tokens for tests or local environments
  • Re-sign a token with the same secret while debugging via JWT Decoder
  • Issue a single token without a backend library
  • Set custom `exp`, `sub`, `role` claims for permission testing
  • Compare outputs of HS256 / HS384 / HS512

FAQ

Q.Is RS256 (asymmetric) supported?
A.Only HS256/384/512 (HMAC) at the moment. RS256, ES256, etc. need PEM key parsing — under consideration as a separate tool. HMAC is sufficient for simple use cases (single secret signs and verifies).
Q.Is the secret sent anywhere?
A.No. Both `crypto.subtle.importKey` and `subtle.sign` run entirely in the browser — secret, payload, and resulting token never leave your device.
Q.Can I use this with production secrets?
A.Suitable for tests and local debugging. Pasting production secrets into a browser tool isn't generally recommended — clipboard, browser extensions, etc. are an exposure surface. Mint real tokens server-side.
Fun facts
  • JWT's RFC 7519 defined an algorithm of 'none' — which became the basis of a 2015 Auth0 disclosure: many JWT libraries would happily verify a token whose `alg` header was switched to 'none', bypassing signature checks entirely. Libraries now block 'none' by default.

    Auth0 — JWT vulnerabilities (2015)
  • HS256 (HMAC-SHA256) requires both issuer and verifier to share the same secret. RS256 (RSA) splits private/public — only the issuer signs, anyone with the public key can verify. Prefer RS256 when many services need to verify tokens.

    RFC 7518 — JOSE Algorithms
  • A JWT payload is base64url-encoded, *not* encrypted — anyone can decode it as plaintext. The signature protects against tampering, not disclosure. Don't put passwords, government IDs, or other sensitive PII into the payload.

    Auth0 — JWT Claims