What this HTTP signature calculator does
"The request signature we calculated does not match the signature you provided" is one of the most frustrating errors in API work, because the server never tells you which step went wrong. This calculator reproduces the whole signing process for AWS Signature Version 4, Alibaba Cloud ACS3-HMAC-SHA256, Tencent Cloud TC3-HMAC-SHA256 and OAuth 1.0a HMAC-SHA1, and shows every intermediate value: the canonical request, its hash, the string to sign, the derived signing key and the final signature and headers. It also verifies incoming webhook signatures from GitHub, Stripe and Slack. All cryptography uses the browser's Web Crypto API, so your secret keys stay on your device.
How to use it
- Pick the provider tab.
- Enter the method, URL, headers (one
Name: valueper line) and body exactly as your code sends them. - Enter the access key, secret key and, where relevant, region and service. Click Use current time or pin a fixed timestamp to compare with a captured request.
- Compare each step with what your SDK or code logs. The first step that differs is where your bug is.
- For webhooks, paste the raw request body byte-for-byte, the signature header and your signing secret, and the tool tells you whether it matches.
Common causes of signature mismatches
- Canonical URI encoding: AWS encodes each path segment; S3 does not double-encode.
- Query ordering: parameters must be sorted by encoded key, and empty values still need
=. - Signed headers: header names are lowercased, trimmed, sorted and joined with
;. Forgettinghostorx-amz-dateis common. - Payload hash: S3 requires the
x-amz-content-sha256header; other services just hash the body. - Clock skew: most providers reject requests more than 5–15 minutes off.
- Webhooks: frameworks often parse and re-serialize JSON before you see it. Verify against the raw bytes, not a re-encoded object. Stripe signs
timestamp.body, Slack signsv0:timestamp:body.