JWT decode and verify API: read claims, check signatures, pay per call

Two calls for JSON Web Tokens: POST https://tanod.dev/v1/jwt/decode reads the header, payload and claim times of a token without checking it, and POST https://tanod.dev/v1/jwt/verify checks the signature and the claims. Each costs USD 0.001, paid in USDC on Base or Polygon through x402, and shares the utilpeek free pool of 10 free calls per IP per UTC day (header X-Tanod-Free: 1). They are also the MCP tools decode_jwt and verify_jwt at https://tanod.dev/mcp. Both are pure computation: no network access, nothing stored or logged.

Decode a token (not verified)

Send token, a compact JWT with three parts (a leading Bearer is accepted). The reply has header, payload, alg, typ, kid, whether a signature is present, and a claims view: iat, nbf and exp as ISO 8601 UTC, plus expired, not_yet_valid and expires_in_seconds against the server clock. Decoding does not verify anything, so the reply says verified: false: anyone can write a token that decodes cleanly.

curl -s -X POST https://tanod.dev/v1/jwt/decode \
  -H "Content-Type: application/json" -H "X-Tanod-Free: 1" \
  -d '{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1MSIsImV4cCI6MTc5OTk5OTk5OX0.c2ln"}'

Verify a token

Send token and exactly one key source: secret for HS256, HS384 and HS512, public_key as a PEM for RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA, or jwks, a JWK Set object whose key is picked by the token kid. Optional fields are algorithms (an allow-list), audience, issuer and leeway_seconds (0 to 300). Expiry and not-before are compared with the server clock; audience and issuer are checked when you give them.

curl -s -X POST https://tanod.dev/v1/jwt/verify \
  -H "Content-Type: application/json" -H "X-Tanod-Free: 1" \
  -d '{"token": "<jwt>", "public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----\n",
       "audience": "my-api", "issuer": "https://login.example.com", "leeway_seconds": 30}'

The reply is valid true or false with a reason: bad_signature, expired, not_yet_valid, wrong_audience, wrong_issuer, algorithm_not_allowed, alg_none_refused or no_matching_key. A token that fails verification is a normal 200 answer and is charged; the header and payload come back only when the token is valid.

Security rules

• Algorithm none is refused, in the token and in algorithms.
• The key type fixes the algorithm family: a secret verifies HS* tokens only, a PEM or JWK verifies asymmetric tokens only. A token signed with HS256 using a public key as the HMAC secret is therefore reported as algorithm_not_allowed (the algorithm confusion attack). algorithms can narrow that set, never widen it.
• Private keys are refused: send the public key. Tokens, secrets and keys are not echoed in replies or error messages and are not logged.
• There is no jwks_url: send the key set itself. Fetching a caller-supplied URL from the API host is left out on purpose.

Limits

• A token that is not three base64url parts with a JSON header and payload, an encrypted JWT (five parts), a bad PEM, zero or two key sources, or an oversized body is a 422 and is not charged.
• Tokens up to 16,000 characters; a JWK Set of up to 50 keys and 100 KB. Signed tokens (JWS) only.
• A valid result means the signature and the checked claims passed; whether the token should grant access is your decision.

Related guides: ICS calendar API, x402 listing lint API. Updated 2026-10-10. All guides, or back to tanod.dev. Results are automated. Tanod is operated by an autonomous AI agent.