Free JWT Encode API Endpoint

One call to the free JWT encode API endpoint

Send a JSON body with two keys and read one field back.

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -H "Content-Type: application/json" \
  -d '{"data":{"user":"alice"},"secret":"your_secret_key"}'

{"jwt":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.vD5nf5S8f8zwk4JnH8hLwU_RH1HcXbixoFUax8V2SAw"}

That is the entire contract for the free JWT encode API endpoint. There is no key to request, no account to create and no signup step. The service-wide limit is 5000 requests per IP per 24 hours.

The algorithm is always HS256, and it cannot be overridden. No algorithm parameter is read from your request, so the alg: none foot gun does not exist here.

The result is deterministic. The service never injects iat, exp, jti or an issuer of its own, so identical claims and an identical secret always produce a byte-identical token. That property is what makes this endpoint useful as a reference to diff your own signing library against.

Encoded, never encrypted

A signature protects integrity. It does not protect confidentiality. Those are different jobs, and conflating them is the most expensive mistake people make with tokens.

Proving it takes one more call and no credentials. Split the token above on the dots, take the middle segment, and decode it with the Base64 decode API endpoint:

curl -X POST https://aisenseapi.com/services/v1/base64_decode \
  -H "Content-Type: application/json" \
  -d '{"data":"eyJ1c2VyIjoiYWxpY2UifQ"}'

{"user":"alice"}

A JWT payload is encoded, not encrypted. Anyone holding the token reads every claim inside it without the secret, exactly as the request above demonstrates. Never put a password, an API key, a card number, a health record or any other confidential value in a payload. And never send a production signing secret to this or to any other public API. A signing key that has left your own infrastructure can no longer prove anything, and every token it ever signed has to be treated as forgeable. Use this service to learn, to debug and to mint throwaway tokens in test environments. Sign your real tokens locally, in your own process, with a secret that never leaves it.

Claims as an object or as a string

The free JWT encode API endpoint reads the data key in two shapes. Both produce the same token, so you can pick whichever fits the caller.

1. A JSON object. The form shown above. Reach for it when you build the claims programmatically.

2. A string containing JSON. Useful when the claims arrive already serialised and you would otherwise parse them only to serialise them again:

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -H "Content-Type: application/json" \
  -d '{"data":"{\"user\":\"alice\"}","secret":"your_secret_key"}'

{"jwt":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.vD5nf5S8f8zwk4JnH8hLwU_RH1HcXbixoFUax8V2SAw"}

Compare that token with the first one. They match character for character.

A string that does not parse as JSON is rejected rather than signed as a bare string. A serialisation bug upstream therefore surfaces as an HTTP 400 instead of a valid token wrapped around a useless payload.

Two further shapes exist for awkward callers. A text/plain body carries the claims directly and keeps the secret out of the body, in an X-Secret header:

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -H "Content-Type: text/plain" \
  -H "X-Secret: your_secret_key" \
  --data '{"user":"alice"}'

A multipart post reads the claims from a file in the jwt_data field, for when they already live on disk:

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -F "jwt_data=@claims.json" \
  -F "secret=your_secret_key"

All four routes converge on the same token.

Response fields

Field	Type	Description
jwt	string	The complete token: three base64url segments joined by dots, signed with HS256.
error	string	Returned with HTTP 400 when the input cannot be used.

Three failures on the free JWT encode API endpoint are worth knowing before you meet them. A data string that is not parseable JSON returns {"error":"Invalid data provided. Send a JSON object, or a string containing JSON."}. A request with claims but no secret returns {"error":"Secret key is required for encoding."}. An empty body returns {"error":"No data to process or invalid input."}.

Each of those arrives with status 400, so check the status code rather than sniffing for a jwt key.

What the free JWT encode API endpoint builds

A JWT is three base64url segments joined by dots. Sign a slightly richer claim set and the structure becomes easy to read:

curl -X POST https://aisenseapi.com/services/v1/jwt_encode \
  -H "Content-Type: application/json" \
  -d '{"data":{"sub":"user_42","role":"editor","exp":1893456000},"secret":"your_secret_key"}'

{"jwt":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIiwicm9sZSI6ImVkaXRvciIsImV4cCI6MTg5MzQ1NjAwMH0.0ZJbp4Q3ft7X4PpfXUuU9u46lJ1Rrpz2aBqF0YeNtTY"}

Header
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 decodes to {"typ":"JWT","alg":"HS256"}. It names the token type and the signing algorithm, and this service always writes exactly those two values.
Payload
eyJzdWIiOiJ1c2VyXzQyIiwicm9sZSI6ImVkaXRvciIsImV4cCI6MTg5MzQ1NjAwMH0 decodes to {"sub":"user_42","role":"editor","exp":1893456000}. Your claims, verbatim, in the order you sent them.
Signature
0ZJbp4Q3ft7X4PpfXUuU9u46lJ1Rrpz2aBqF0YeNtTY is an HMAC-SHA256 over the first two segments, keyed with your secret, then base64url encoded. It proves nobody without the secret altered the header or the payload.

Base64url is a transport encoding rather than a cipher. Padding is stripped and the alphabet swaps +/ for -_ so the value survives a URL, and that is the whole of it.

Claims such as exp are passed through untouched at signing time. They acquire meaning at verification, which is a separate call documented on the JWT decode API endpoint page. HS256 is symmetric, so the same secret that signed a token verifies it there.

Common uses

Cross-checking a signing library

Sign the same claims with the same secret here and in your own code, then compare the strings. Because nothing is auto-injected, any difference is a real difference in your header, your claim ordering or your HMAC.

Test fixtures

Mint tokens carrying fabricated user ids, roles and scopes for integration tests and API mocks, using a throwaway secret your suite also knows.

Teaching how tokens work

Encode a token, decode its middle segment with a plain Base64 call, and a class sees for itself that a signature protects integrity rather than confidentiality.

Giving an agent a signer

A language model with HTTP access can produce a test token in one call, with no code sandbox involved.

Privacy and limits

Claims, tokens and secrets travel in the POST body rather than the URL, so they never land in request paths. That is a reason to prefer the body, not a reason to trust a public endpoint with anything real. Treat every value you send here as disclosed.

The free JWT encode API endpoint is stateless. No token store exists, there is no lookup by identifier, and no endpoint lists what was signed earlier. No account exists and no API key is issued. The service-wide limit is 5000 requests per IP per 24 hours.