Sign and verify a payload
Sign mensaje with the key clave-secreta using HMAC-SHA-256 and you get a signature starting fd7e5bf1 that only someone holding that key can reproduce. Check incoming signatures the same way to spot altered messages. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
HMAC, free in your browser
What a keyed signature proves
An HMAC is a fingerprint of a message made with a secret that both sides share. Anyone can compute an ordinary hash, so it only shows that data was not damaged. An HMAC also shows who made it: without the secret, nobody can produce a signature that checks out. You choose the hash behind it, SHA-256, SHA-384 or SHA-512, and receive the signature as hexadecimal or base64 text, or ask the tool to verify a signature you were sent and get a valid or invalid answer.
Where HMAC signatures are used
Signed links are a common case: an HMAC over the address and its expiry makes download or password reset links tamper-evident. Message queues use it too, so consumers can reject anything altered in transit, and services use it to trust automatic notifications sent by another system. The construction was formalized in RFC 2104 in 1996 and standardized as FIPS 198, and three decades of analysis have left it largely unscathed, which is why it remains the default for message authentication.
A little history that still matters
HMAC was formalized in RFC 2104 back in 1996 and later standardized as FIPS 198, precisely because early attempts at keying a hash function by simple concatenation turned out to be exploitable. The construction survived three decades of cryptanalysis largely unscathed, which is why it remains the default choice for message authentication instead of something newer and less battle-tested.
What you can do with it
Signed URLs
Generate an HMAC over a URL's query parameters to create tamper-evident download or reset links with an expiry baked in.
Message queue integrity
Stamp messages with an HMAC before publishing to a queue so consumers can reject anything altered in transit.
FAQ
Do you store my secret key?
No. The secret you send is used only to compute or check the signature for that single request and is discarded once the task completes.
Is HMAC still considered secure in 2026?
Yes, HMAC paired with SHA-256 or stronger remains a recommended construction; its security depends on keeping the secret private and choosing an adequately long key.
What is the difference between a hash and an HMAC?
A plain hash such as SHA-256 proves a message was not corrupted, but anyone can compute it, including someone forging a message. HMAC mixes a shared secret into the hashing, so only a holder of that secret can produce a signature that verifies.
How do I check a signature I received?
Choose the verify option and enter the message, the shared secret and the signature you were given. The answer is a plain valid or invalid, so you know at once whether the message was altered or signed with another key.
Why not just put the key in front of the message and hash it?
Early attempts to key a hash by simple joining turned out to be exploitable. HMAC was formalized in RFC 2104 in 1996, later standardized as FIPS 198, precisely to close that gap, and it has held up for three decades.
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/hmac \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"payload","secret":"s3cr3t"}'const res = await fetch("https://api.kit.forhosting.com/dev/hmac", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "payload",
"secret": "s3cr3t"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/hmac",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "payload",
"secret": "s3cr3t"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/hmac", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"payload","secret":"s3cr3t"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"payload","secret":"s3cr3t"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/hmac", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "payload",
"secret": "s3cr3t"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.hmac",
"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
Every webhook, API key exchange or internal message queue that claims to be tamper-proof rests on one primitive: a keyed hash. The HMAC API signs or verifies a payload against a secret you control, so your services can trust that a message came from where it says it came from and wasn't altered in transit.
Why a keyed hash beats a plain checksum
A regular hash like SHA-256 proves a message wasn't corrupted, but anyone can compute one, including an attacker forging a request. HMAC mixes a shared secret into the hashing process, so only someone holding that secret can produce a signature that verifies. That single distinction is why HMAC sits at the center of webhook authentication, signed URLs, OAuth token integrity and inter-service trust across almost every API-driven company.
What the endpoint actually does
Send POST /dev/hmac with a payload, a secret and a chosen algorithm (SHA-256, SHA-384 or SHA-512), and tell it whether you want a signature generated or an existing one checked. The task runs asynchronously: you get a task_id immediately, and the result — a hex or base64 digest, or a simple valid/invalid verdict — lands via signed webhook or a signed link you can fetch for 24 hours.
Where it plugs into your stack
Because it is stateless and async, it drops into existing automation without you having to manage a cryptography library, key rotation code or timing-safe comparison logic yourself. Teams call this endpoint from webhook senders that need to sign outgoing payloads, from receivers validating an inbound webhook against a shared secret, from queue workers stamping messages before they hit a broker, and from CI pipelines that sign release artifacts.
What to expect on delivery
Every response includes the algorithm used and the resulting digest or verification result, nothing more, nothing retained. A failed task, such as a malformed payload, is never billed — the API retries transient failures automatically up to three times before returning a clear, actionable error.
Integration use cases
Webhook senders
Sign each outgoing webhook payload before delivery so receivers can confirm it genuinely came from your system.
Inbound webhook validation
Verify the signature header on webhooks you receive from third parties before trusting the body.
Technical questions
What is an HMAC signature used for?
It proves both that a message wasn't altered and that it came from someone holding the shared secret, which is why it's the standard for webhook and API authentication.
Which algorithms does the HMAC API support?
SHA-256, SHA-384 and SHA-512, selectable per request depending on the security margin your system requires.
Is there a free tier for the HMAC signature API?
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.
How much does it cost to sign or verify a payload?
$0.002 per request, with no separate charge for verification versus signing, and failed tasks are never charged.
Can I use this to verify webhooks from other providers?
Yes. As long as you know the algorithm and shared secret the provider uses, POST /dev/hmac can validate the signature header on any incoming payload.
How do I get the result back?
Either through a signed webhook callback, recommended for automated pipelines, or a signed link that stays valid for 24 hours before the result is deleted.