JWT Encoder

How do you build a JWT for local testing safely?

What this tool does

The Kitnax JWT Encoder lets you edit header and payload JSON, optionally sign the result with HS256 using a shared secret, and copy a complete three-part JWT string. The header defaults to standard fields like alg and typ; the payload accepts any valid JSON claims including exp, sub, and custom roles. When you leave the secret empty, the tool produces an unsigned token with alg none for quick fixtures. Token assembly and signing run entirely in your browser via Web Crypto — no upload to Kitnax servers.

Why you need it

Backend and frontend teams often need reproducible JWT fixtures before an identity provider is wired up. Unit tests for middleware may require tokens with specific exp or aud values. Demos and API documentation benefit from sample tokens you can paste into the JWT Decoder to verify structure. This encoder fills that gap without replacing your auth platform. It is explicitly for development, demos, and test harnesses — not for issuing credentials users rely on in production.

How to use it

1. Edit HEADER and PAYLOAD JSON directly, or click Load sample for a starting template with common claims.
2. Optionally enter a shared secret in the HS256 field — leave blank for unsigned alg:none tokens used in local mocks.
3. Watch the Token output area update as JSON validates; fix syntax errors flagged in the status bar.
4. Click Copy Token when the status shows success, then paste into the JWT Decoder to inspect claims.
5. Clear all fields before switching to unrelated projects so secrets do not linger on screen.

Practical examples

• API fixture: build a token with sub and roles claims matching your test user, sign with a dev-only secret, and send it in Authorization headers against a local Express middleware.
• Expiry testing: set exp to a past timestamp, sign the token, and confirm your service returns 401 while the JWT Decoder shows an expiry warning.
• Documentation screenshot: generate an unsigned sample token for a README example without exposing real signing keys.
• Claim migration: encode payloads with both legacy and new claim names to compare how downstream parsers behave before a release.

How it works

JWT creation follows the same three-part layout as decoding: Base64URL-encoded header and payload joined by dots, plus a signature segment. For HS256, Kitnax canonicalizes the JSON, encodes each part, and computes an HMAC-SHA256 signature with the secret you provide using SubtleCrypto. An empty secret switches alg to none and leaves the signature segment blank — valid for some test stacks, rejected by properly configured production APIs.

Client-side signing is convenient for demos but fundamentally unsuitable for production auth. Browser tools cannot protect long-lived secrets from extensions, memory inspection, or shoulder surfing. Production systems sign tokens on hardened servers with key rotation, short-lived signing keys, and audit trails. Never paste production HMAC secrets or private keys into any online or browser-based encoder — treat any secret typed here as compromised for real environments and rotate it if accidental exposure occurs.

Common mistakes

• Using tokens from this tool in live authentication flows — production signing belongs on your auth server, not in a browser tab.
• Pasting real production secrets to "test quickly" — use throwaway dev keys only and rotate anything that touched a client-side tool.
• Accepting alg:none tokens in APIs meant for production — explicitly reject unsigned tokens in middleware configuration.
• Expecting RS256 or ES256 support here — asymmetric signing requires private keys that must never load into client-side tooling.

FAQ

Related tools

• JWT Decoder
• Base64 Encoder/Decoder
• Hash Generator
• UUID Generator