Decode a token in one request
Call the free JWT decode API endpoint with the token in data and the shared secret in secret. Nothing else is required.
curl -X POST https://aisenseapi.com/services/v1/jwt_decode \
-H "Content-Type: application/json" \
-d '{"data":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.vD5nf5S8f8zwk4JnH8hLwU_RH1HcXbixoFUax8V2SAw","secret":"your_secret_key"}'{"decoded_payload":{"user":"alice"}}Richer claims come back the same way. Here is a token carrying a subject, a display name and a boolean flag:
curl -X POST https://aisenseapi.com/services/v1/jwt_decode \
-H "Content-Type: application/json" \
-d '{"data":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImFkbWluIjp0cnVlfQ.7q-5kntFHsnrbkp1ti1pwS1CA-enTLghvjjy37395f4","secret":"your_secret_key"}'{"decoded_payload":{"sub":"1234567890","name":"Ada Lovelace","admin":true}}Nothing is added or removed on the way out. What lands in decoded_payload is what the payload segment carried, key for key. Need a token to practise on? Mint one with the JWT Encode API endpoint first.
What the free JWT decode API endpoint verifies
Decoding here is verification, not merely parsing. HS256 is symmetric, so the secret that signed a token is also the secret that proves it. The service recomputes the HMAC over the header and payload segments, compares the result against the signature segment, and only then hands the claims back.
Two conditions stop a token from returning. A signature that does not match the secret you supplied fails. So does a token whose exp claim has already passed. Neither case produces a decoded_payload, which is the honest answer: the token did not verify.
The algorithm is fixed at HS256. There is no header field to override, so the classic "alg none" trick has nothing to attack here.
A payload is encoded, not encrypted
Verification protects integrity. It does nothing for secrecy. The payload segment is base64url text, and base64url is a transport encoding rather than a cipher. Anyone holding the token can read every claim inside it, with no secret at all.
One more request proves it. Take the middle segment of the token above and run it through the Base64 Decode API endpoint, passing no secret anywhere:
curl -X POST https://aisenseapi.com/services/v1/base64_decode \
-H "Content-Type: application/json" \
-d '{"data":"eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImFkbWluIjp0cnVlfQ"}'{"sub":"1234567890","name":"Ada Lovelace","admin":true}Same claims, no signature check, no key. That is the whole lesson of the format in two requests.
Never put a secret inside a payload, and never send a production signing key to a public API. Passwords, API keys and card numbers do not belong in claims, because a claim is readable by every party that touches the token. A key that has left your own infrastructure can no longer prove anything. Decode real tokens locally.
Three ways to send the token
The endpoint accepts three input shapes, so you can call it from a shell, a form or a file pipeline without reshaping anything first.
1. JSON body. The form shown in the quick start. The token goes in data, the secret in secret. Best when a program builds the request.
2. Plain text body with an X-Secret header. The raw body is the token itself and the secret stays in a header. This suits piping a token straight out of a log line.
curl -X POST https://aisenseapi.com/services/v1/jwt_decode \
-H "Content-Type: text/plain" \
-H "X-Secret: your_secret_key" \
--data 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.vD5nf5S8f8zwk4JnH8hLwU_RH1HcXbixoFUax8V2SAw'{"decoded_payload":{"user":"alice"}}3. Multipart file upload. The token already lives in a file, so upload it in the jwt_data field with the secret beside it.
curl -X POST https://aisenseapi.com/services/v1/jwt_decode \
-F "jwt_data=@token.txt" \
-F "secret=your_secret_key"{"decoded_payload":{"user":"alice"}}Response fields
| Field | Type | Description |
|---|---|---|
| decoded_payload | object | The claims from the payload segment, returned only after the signature verifies against the secret you supplied. |
| error | string | Returned with HTTP 400 when the input cannot be used. |
Two input errors are worth memorising. An empty body returns {"error":"No data to process or invalid input."}. A token sent without a secret returns {"error":"Secret key is required for decoding."}. Both arrive with HTTP 400.
Want to read a token you cannot verify, because the secret belongs to somebody else? Skip this endpoint. Split the token on its dots and decode the middle segment with the Base64 Decode API endpoint instead.
Common uses
Reading a token from a log
An Authorization header turns up in a trace. Paste the token in and read its subject, scope and expiry instead of squinting at base64.
Debugging a rejected login
Your gateway says the token is invalid. Decode it with the same secret and find out whether the signature or the expiry is the culprit.
Checking a signing library
Sign claims in your own code, decode them here, and confirm the payload survives the round trip untouched.
Teaching how JWTs work
Verify a token, then decode its payload with a plain base64 call. The room sees that a signature guards integrity, not confidentiality.
Privacy and limits
Tokens and secrets travel in the POST body rather than the URL, so they never land in a request path. That is a reason to prefer the body, not a reason to trust a public service with anything real.
The free JWT decode API endpoint is stateless. No token is stored, no history is kept, and no endpoint lists what was decoded earlier. The service-wide limit is 5000 requests per IP per 24 hours, with no key and no account. The base URL is https://aisenseapi.com/services/v1.