🔏 JWT Encoder

Create signed JSON Web Tokens directly in your browser. Edit the header and payload JSON, enter a secret, and get a ready-to-use HS256 token signed locally with the WebCrypto HMAC-SHA256 implementation, so your data never leaves your machine. It is built for testing authenticated APIs, reproducing token-related bugs, and learning how JWTs are put together.

How Signing Works

A JWT has three base64url segments separated by dots: header.payload.signature. The encoder does the following:

1. Parse the header and payload as JSON, failing fast if either is invalid.
2. Base64url-encode each JSON string exactly as written (padding stripped, + → -, / → _).
3. Compute signature = HMAC-SHA256(header + "." + payload, secret) and base64url-encode the raw bytes.

The result is the token. Every segment uses base64url, which is case-sensitive and strips the trailing = padding. Verification is the same operation in reverse: the server recomputes the HMAC with its copy of the secret and compares. If a single character of the payload changes, the signature no longer matches.

Step by Step

1. Edit the header — the default {"alg": "HS256", "typ": "JWT"} works unless you need extra header fields such as kid.
2. Edit the payload — add claims such as sub, name, iat, exp, or roles. Values must be valid JSON.
3. Enter a secret — type the shared HMAC key. Use a throwaway test value, never a production secret.
4. Read the token — the field re-signs automatically as you type, and the Sign button forces a re-run.
5. Copy — one click copies the finished token.

Worked Example: Reproducing a Known Token

Header (compact, no spaces):

{"alg":"HS256","typ":"JWT"}

Payload:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

Secret: your-256-bit-secret. The encoded pieces are:

• header → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
• payload → eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
• signature → SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

giving the full token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Change the secret by one character and the signature segment changes completely, while the first two segments stay identical. That is the whole point: the payload is public, the signature is the proof.

Signing Is Not Encryption

This is the most misunderstood part of JWTs. HS256 provides integrity and authenticity, not confidentiality. Decode the token above with the JWT Decoder and the claims appear in plain text — base64url is an encoding, not a cipher. Anyone who intercepts the token can also replay it until it expires, so:

• Put only non-sensitive claims in the payload: user id, roles, scopes, expiry.
• Keep secrets, passwords, and personal data server-side.
• Use TLS so the token cannot be lifted in transit.
• Verify the signature and the exp claim on the server before trusting anything.

The tool itself also cannot make a weak secret safe. A leaked or guessable HMAC secret lets anyone mint valid tokens, which is why this page is for development only.

Common Mistakes

• Pasting a production secret. Sign test tokens with test secrets and rotate anything that has ever been entered into a browser tool.
• Forgetting whitespace matters. The default header in the textarea contains newlines and indentation, so its signature differs from the compact form above even though the JSON is semantically identical.
• Expecting claim validation. exp in the past, nbf in the future, or a misspelled role claim all sign without complaint. Validation is the server’s job.
• Using HS256 across untrusted parties. A symmetric secret must stay secret on every verifier. If multiple services need to verify, prefer an asymmetric algorithm.
• Treating the token as encrypted. See above — assume the payload is readable.

HS256 vs RS256

HS256 is symmetric: one secret both signs and verifies, so every service that verifies must also be able to sign, and a leak in any of them compromises all of them. RS256 and ES256 are asymmetric: a private key signs and a public key verifies. That separation lets API gateways and resource servers verify tokens without holding signing power, which is why public-key algorithms dominate multi-service architectures.

This encoder supports only HS256 because a browser test needs no private-key management. If your target system uses RS256, mint tokens with your own tooling and use the JWT Decoder to confirm the structure and claims — the decoded header will read "alg": "RS256".

Verifying a Token Outside the Browser

You can reproduce the signature without any JWT library. A short Node script using the built-in crypto module does exactly what a server does on each request:

const crypto = require('crypto');
const [h, p, sig] = token.split('.');
const expected = crypto.createHmac('sha256', secret)
  .update(`${h}.${p}`).digest('base64url');
console.log(expected === sig); // true only if the secret matches

Both Node and modern browsers expose base64url, so no manual +// replacement is needed. If the comparison is false, the token was signed with a different secret, the payload was altered, or the header and payload strings were re-serialised with different whitespace. Reject it and move on.

Related Tools

• JWT Decoder — Inspect the header, payload, and signature of any token.
• Base64 Encoder/Decoder — See the raw bytes behind each JWT segment.
• Hash Generator — Compare HMAC output and other digest algorithms.
• Password Generator — Generate a strong random HMAC secret.