JWT Decoder, Base64, Hash and HMAC Toolkit

Small developer utilities as one cheap, deterministic call, with no web calls and no AI model. Useful in data pipelines and for AI agents, because Apify Actors can be called through Apify's MCP server (https://mcp.apify.com).

Operations (one billed result per input string):

• jwt_decode: read the header and payload of a JWT, convert exp / nbf / iat to ISO times, tell whether it is expired at a reference time, and warn about alg: none, a missing exp, an empty signature or non-numeric dates. If you supply a secret, HS256 / HS384 / HS512 signatures are checked in constant time.
• base64_encode / base64_decode: standard Base64 and URL-safe Base64URL (padding optional on decode). Binary results are reported as hex with is_utf8: false.
• hash: MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512 as hex, base64 or base64url.
• hmac: the same algorithms keyed with your secret.

Input

Field	Meaning
items	Strings, one per line (up to 10,000, each up to 100,000 characters)
operation	jwt_decode (default), base64_encode, base64_decode, hash, hmac
algorithm, outputEncoding	for hash and hmac
secret	HMAC key, or optional JWT verification key. Marked secret in the input form and never echoed in output
urlSafe	Base64 encode with the URL-safe alphabet and no padding
referenceTime	ISO time used for the expiry check; empty means now

Output example

Real output of the bundled test input (the public jwt.io sample token, secret your-256-bit-secret, reference time 22 Oct 2026):

{
  "index": 0, "operation": "jwt_decode", "ok": true, "error": null,
  "algorithm": "HS256", "type": "JWT",
  "header": { "alg": "HS256", "typ": "JWT" },
  "payload": { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 },
  "claim_times": { "iat": "2018-01-18T01:30:22.000Z" },
  "expired": null, "signature_present": true, "signature_verified": true,
  "warnings": ["no exp claim: the token never expires"]
}

Important limits (read before relying on it)

• Decoding is not trust. Without a secret, jwt_decode does not verify anything: anyone can forge a payload. signature_verified is null unless you give a secret and the token uses HS256, HS384 or HS512. RS256, ES256, PS256, EdDSA and other asymmetric algorithms are not verified (no public-key input). alg: none tokens are never reported as verified. See RFC 7519 (https://www.rfc-editor.org/rfc/rfc7519) and RFC 8725 (https://www.rfc-editor.org/rfc/rfc8725).
• Encrypted tokens (JWE, 5 parts) cannot be read; the Actor says so.
• Do not paste live production tokens or secrets into a run you do not control: inputs are stored in your run's storage and logs on Apify. Use test tokens or rotate afterwards.
• MD5 and SHA-1 are broken for security purposes; they are provided for checksums and legacy interoperability. A plain hash is not a safe way to store passwords; this Actor has no bcrypt, scrypt or Argon2.
• Text is hashed and encoded as UTF-8. Expiry uses the comparison now >= exp (RFC 7519 section 4.1.4); no clock-skew leeway is applied.
• Implemented with Node's built-in node:crypto; outputs for the standard test vectors (RFC 4648, RFC 4231, FIPS examples) are checked in the repository's tests.

Pricing (pay-per-event)

Uses Apify's built-in apify-default-dataset-item event: each input string is one result. The owner sets the price in Apify Console. Suggested: USD 1.00 per 1,000 results. The one hash Actor with a visible price found is listed from USD 0.00025 per hash (USD 0.25 per 1,000, https://apify.com/hipersoft/hash-generator); see apify/RESEARCH-3.md for the competitor snapshot.

FAQ

Does it call a website, API or AI model? No. Everything is computed locally.

Can it verify RS256 / ES256 JWTs? Not in this version.

Is the secret stored? It is part of your run input, so it is stored by Apify like any input; it is not written to the output dataset.