Skip to main content
SnipKit

JWT Encoder

Sign and verify JWT tokens with HS256/HS384/HS512 or RS256 — fully client-side via Web Crypto.

Processed locally in your browser
Decode →
{
  "alg": "HS256",
  "typ": "JWT"
}

Standard claims: iss, sub, aud, exp, iat, nbf, jti

Used as HMAC key. Longer secrets resist brute-force attacks.

Security: All signing and verification runs client-side via Web Crypto — your secret never leaves the browser. Still, never paste real production secrets or private keys into any online tool. The none algorithm is intentionally not supported — unsigned tokens are an authentication anti-pattern.

Unlock the full toolkit

Batch processing, no ads, higher limits, and API access.

Go Premium

How to Use

1. Pick the signing algorithm — HS256 for shared-secret HMAC, RS256 for RSA private/public key pairs. 2. Edit the JSON payload directly or use the claim helper buttons to add common fields. 3. Paste your secret (HS*) or PKCS#8 private key PEM (RS256). 4. Click "Generate token" — the signed JWT appears below with one-click copy. 5. Switch to Verify mode to validate any token against its key. To inspect the decoded contents, jump to the JWT Decoder.

Features

  • Sign JWTs with HS256, HS384, HS512, or RS256
  • Verify signatures against secret or public key
  • Live JSON payload editor with syntax validation
  • One-click claim helpers — iat, exp (+1h/+24h/+7d/+30d), iss, sub, aud, jti
  • Auto-detects algorithm from token header in Verify mode
  • Web Crypto API — secret never leaves your browser
  • `none` algorithm explicitly disabled (security best practice)
  • Direct hop to JWT Decoder to inspect the generated token

Frequently Asked Questions

What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is symmetric — the same secret signs and verifies tokens, so anyone who can verify can also forge tokens. RS256 (RSA-SHA256) is asymmetric — a private key signs while a separate public key verifies, so you can safely distribute the public key to many services. HS256 is simpler and faster; RS256 is essential when verification happens on machines you do not control. HS384/HS512 are HS256 variants with stronger hash functions for higher-entropy applications.
Is it safe to enter my JWT secret in this tool?
All signing happens locally via the Web Crypto API — your secret, payload, and the resulting token never touch our servers, and nothing is logged or transmitted. That said, never paste production secrets into any online tool, including this one. Use throwaway test secrets for token generation and reserve real production keys for your backend or local CLI signers.
What are the standard JWT claims (iss, sub, aud, exp, iat, nbf, jti)?
These are the registered claims defined in RFC 7519. `iss` (issuer) identifies who created the token. `sub` (subject) identifies whom the token is about. `aud` (audience) lists the intended recipients. `exp` (expiration) is a Unix timestamp after which the token is invalid. `iat` (issued at) records when the token was created. `nbf` (not before) is a Unix timestamp before which the token must not be accepted. `jti` (JWT ID) is a unique identifier useful for revocation lists. The claim helper buttons in this tool insert any of these with sensible defaults.
How should I use JWTs in production safely?
Sign tokens on your backend, never in client-side code that ships to users. Use RS256 (or ES256) when multiple services need to verify but only one issues. Always set `exp` — short lifetimes (minutes to hours) limit the blast radius of a stolen token, paired with refresh tokens for sessions. Validate `iss` and `aud` on every verify to prevent token reuse across services. Reject the `none` algorithm explicitly — many libraries default to permissive verification. Pair JWT auth with HTTPS and HttpOnly cookies for browser apps.
Why does this tool refuse to issue `alg: none` tokens?
The `none` algorithm produces an unsigned JWT — anyone who sees the token can modify any claim and the verifier accepts it without checks. It exists in the spec for testing libraries but has been the source of real CVEs (e.g., libraries that defaulted to "accept any algorithm including none"). Issuing `none` tokens here would be teaching a footgun. If you really need an unsigned base64url payload, use Base64 Encode & Decode directly.
How do I generate an RSA key pair for RS256?
On macOS/Linux: `openssl genpkey -algorithm RSA -pkcs8 -out private.pem -pkeyopt rsa_keygen_bits:2048` then `openssl rsa -in private.pem -pubout -out public.pem`. The private key (PKCS#8) goes into Encode mode; the public key (SPKI) goes into Verify mode. Both formats start with `-----BEGIN PRIVATE KEY-----` / `-----BEGIN PUBLIC KEY-----` respectively. PKCS#1 keys (`-----BEGIN RSA PRIVATE KEY-----`) need conversion: `openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem`.