Is it safe to sign a token with my production secret here?

No. Sending a signing secret to any external service means it can mint tokens for your system. Use a throwaway secret for testing and generate production tokens in your own environment.

Asymmetric algorithms require a private key. Deliberately not accepting one removes the possibility of a user pasting the most sensitive key their system has.

Can I put sensitive data in the payload?

No. The payload is Base64URL — encoded, not encrypted, and readable by anyone who obtains the token. Keep sensitive data server-side behind an opaque identifier.

What claims should every token include?

iss, aud, exp and iat as a minimum, plus sub to identify the principal. Verify iss, aud and exp on every request.

Security🌐 YAS server-sideAPI availableadvanced

JWT Encode / Sign

Builds and signs a JWT with HS256 in your browser using a secret key.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Payload (JSON)

Secret

Loading tool…

What does this tool do?

Builds and signs a JWT with HS256 in your browser using a secret key.

Why would I use it?

You are testing a JWT-based API and need a signed token.
You want to understand how HMAC-signed JWTs are constructed.
You are prototyping an auth flow.

Real-life example

Input

payload: {"sub":"123","role":"admin"}, secret: "test-secret"

Output

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signed-part

The signature is HMAC-SHA256 of header.payload with the secret.

Input → Process → Output → Next

Input: Enter payload JSON and a secret.
Process: YAS builds the JWT and signs it.
Output: The complete JWT.
Next action: Verify it with jwt-decoder or your server before shipping.

Common mistakes

Using a weak secret — HS256 is only as strong as the secret.
Pasting production signing secrets into any website.
Using HS256 with a shared secret across untrusted parties (use RS256).

What the result means

The signature proves the token was produced with the secret.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/jwt-encode

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/jwt-encode" \
  -H "Content-Type: application/json" \
  -d '{"payload":{"sub":"123","name":"Yas"},"secret":"your-secret"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/jwt-encode", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "payload": {
    "sub": "123",
    "name": "Yas"
  },
  "secret": "your-secret"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/jwt-encode", json={"payload":{"sub":"123","name":"Yas"},"secret":"your-secret"})
data = r.json()

Field	Type	Required	Description
payload	object	Yes	JWT claims (object or JSON string)
secret	string	Yes	HMAC signing secret

Success response

{ "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "alg": "HS256" }

Build and sign a JWT (HS256) from header + payload + secret.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How JWT Encode / Sign works

Signing builds three parts: a header naming the algorithm, a payload of claims, and a signature. Header and payload are serialized to JSON, Base64URL-encoded and joined with a dot; that exact ASCII string is then signed. For HS256 the signature is HMAC-SHA256 with a shared secret, and the Base64URL-encoded MAC is appended as the third segment.

The security of an HS256 token is exactly the security of its secret. Anyone holding it can mint tokens with any claims, which makes HMAC-based JWTs appropriate when one party both issues and verifies, and inappropriate when many services verify tokens they did not issue — that case needs an asymmetric algorithm so verifiers hold only a public key.

When to use it: real-world scenarios

Producing a token to test an authorization middleware

Constructing a token with specific roles or scopes exercises access-control paths that are otherwise awkward to reach.

Reproducing an expiry or clock-skew bug

Set exp deliberately in the past or the near future to confirm your verifier's leeway behaves as documented.

Building a fixture for integration tests

A signed token with known claims and a test secret makes authenticated test requests deterministic.

Understanding what a claim set costs in bytes

Tokens travel in headers on every request; seeing the encoded length makes the case for keeping payloads small.

Pro tips

Always set exp, and keep access tokens short-lived — minutes, not days. Revocation is otherwise impossible without extra infrastructure.
Set aud and iss and verify both. A token minted for one service being accepted by another is a real and frequently exploited flaw.
Use a secret of at least 256 bits from a random source for HS256. A human-chosen secret is brute-forceable offline from a single captured token.
Pin the expected algorithm in your verifier rather than reading alg from the token, which is the algorithm-confusion attack.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

HS256 only. RS256/ES256 signing needs a private key, which should never be uploaded to a web tool.
Payloads are readable by anyone holding the token — signing is not encryption.
Tokens generated here are for development. Production tokens must be issued by your identity provider with keys under your control.
This page carries no advertising, since it processes secrets.

Frequently asked questions

Is it safe to sign a token with my production secret here?: No. Sending a signing secret to any external service means it can mint tokens for your system. Use a throwaway secret for testing and generate production tokens in your own environment.
Why only HS256?: Asymmetric algorithms require a private key. Deliberately not accepting one removes the possibility of a user pasting the most sensitive key their system has.
Can I put sensitive data in the payload?: No. The payload is Base64URL — encoded, not encrypted, and readable by anyone who obtains the token. Keep sensitive data server-side behind an opaque identifier.
What claims should every token include?: iss, aud, exp and iat as a minimum, plus sub to identify the principal. Verify iss, aud and exp on every request.