Create a signed JWT
Create a signed JWT from your own claims: give a subject, a role such as admin and a shared secret, and you get a ready HS256 token back, or sign with a private key for RS256. Your key is used once and then discarded. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Minting a correct JWT means getting the header, the claim set and the signature aligned exactly right, and a single wrong expiry format or missing audience claim can silently break every service downstream.
Who actually needs to mint tokens outside a full auth system
Full identity providers exist for user login flows, but plenty of legitimate work happens outside that path: service-to-service calls that need a short-lived token, test environments that need a token representing a specific user role, staging scripts that impersonate a tenant to reproduce a bug, and internal tools that issue scoped tokens for temporary access. Standing up an entire auth server for those cases is overkill; a single signing call is not.
Why HS256 and RS256 cover almost every case
HS256 signs and verifies with the same shared secret, which is fast and simple when a single service or a small trusted group controls both ends. RS256 signs with a private key but lets anyone verify with the matching public key, which is what you want when multiple independent services need to check tokens without ever holding the signing secret. Since the JWT spec's 2015 standardization in RFC 7519, this pairing has become the default choice across the vast majority of production systems.
What you get back and what you don't
The response is the signed token string, nothing else attached, and your signing key is used only for that single operation and then discarded, never logged or reused. Claims that are structurally invalid, such as a non-numeric exp, are rejected with a specific error before anything is signed, and because failed tasks are never billed, iterating on your claim structure costs nothing extra.
What you can do with it
CI and integration tests
Generate a fresh, correctly signed token for each test case without maintaining a mock authentication server.
Staging and QA impersonation
Mint a token representing a specific user or tenant role to reproduce a reported bug in a controlled environment.
Scoped internal access tools
Issue narrowly scoped tokens on demand for internal dashboards or admin scripts that need temporary, auditable access.
FAQ
Which algorithms can sign my tokens?
HS256 with a shared secret and RS256 with a private key, covering symmetric and asymmetric signing needs.
Do you store the signing keys I send?
No, keys are used only to sign that single token and are discarded immediately after, never retained or used for training.
Can I generate tokens in bulk?
Yes, submit as many separate signing requests as you need; each is billed and processed independently at the same per-request price.
How do I set an expiry on the token?
Give the number of seconds the token should stay valid, and the expiry is written into it for you. If you leave it out, the token is issued with no expiry at all.
Should I choose HS256 or RS256?
HS256 signs and verifies with one shared secret, which is simple when one service or a small trusted group controls both ends. RS256 signs with a private key while anyone can verify with the public key, so independent services can check tokens without holding the secret.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/jwt-sign \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"payload":{"sub":"user_1"},"secret":"s3cr3t"}'const res = await fetch("https://api.kit.forhosting.com/dev/jwt-sign", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/jwt-sign",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/jwt-sign", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"payload":{"sub":"user_1"},"secret":"s3cr3t"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"payload":{"sub":"user_1"},"secret":"s3cr3t"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/jwt-sign", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"payload": {
"sub": "user_1"
},
"secret": "s3cr3t"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.jwt_sign",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This API issues a properly signed token from the claims you provide, using HS256 or RS256, so you can stop hand-rolling token logic for scripts, tests and internal services.
What the request looks like
POST /dev/jwt-sign with your claims payload — things like sub, exp, aud and any custom fields your services expect — plus the algorithm and key: a shared secret for HS256, or a private key for RS256. The task runs asynchronously, returning a task_id immediately, and the finished, ready-to-use token arrives by signed webhook or a signed link valid for 24 hours.
How it fits into automated pipelines
Teams call this endpoint from CI test suites that need fresh tokens per test run, from internal admin tools issuing scoped access tokens on demand, from microservices generating short-lived tokens to call a peer service, and from load-testing scripts that need thousands of distinct but valid tokens without spinning up a real login flow for each one.
Integration use cases
Service-to-service calls
Issue short-lived tokens for a backend job to authenticate against a peer API without sharing long-lived credentials.
Technical questions
How do I generate a JWT with this API?
Send POST /dev/jwt-sign with your claims, the algorithm and the signing key, and the finished token arrives by webhook or signed link.
Is the JWT generator API free?
The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.
What does it cost to generate a token?
$0.002 per request regardless of algorithm, and a failed signing attempt is never charged.
Can I set a custom expiration or custom claims?
Yes, you control the full claims payload, including exp, aud, sub and any custom fields your services need.
What happens if my claims payload is invalid?
The API rejects it with a specific, actionable error before signing, so you can fix the structure without guessing.