SigV4 is a well-designed signing scheme with an unforgiving failure mode: SignatureDoesNotMatch, with no indication of which of the dozen inputs was wrong. This tool shows every intermediate value so you can diff yours against a known-good one.
The four stages
1. Canonical request. Method, URI-encoded path, sorted query string, sorted lowercase headers, the list of signed header names, and a SHA-256 of the payload — joined by newlines.
2. String to sign. The algorithm name, the timestamp, the credential scope (date/region/service/aws4_request), and a SHA-256 of the canonical request.
3. Signing key. Four chained HMACs, deriving from your secret through the date, region and service. This scoping is why a signing key for s3 in us-east-1 on one day cannot be replayed against another service, region or day.
kDate = HMAC("AWS4" + secret, date)
kRegion = HMAC(kDate, region)
kService = HMAC(kRegion, service)
kSigning = HMAC(kService, "aws4_request")4. Signature. HMAC of the string to sign under the signing key, hex-encoded, assembled into the Authorization header.
Debugging SignatureDoesNotMatch
AWS returns the canonical request it computed in the error response. Diff it against the one shown here — the mismatch is visible immediately, and it is almost always one of:
- Path encoding. S3 requires the path encoded once; most other services require it twice. A path with a space or a
+exposes the difference. - Query ordering. Parameters must be sorted by key, with values URI-encoded before sorting.
- Header mismatch. Every header in
SignedHeadersmust be sent, byte-identical. Adding a header after signing without updating the list breaks it. - Payload hash. For an empty body, the hash is the SHA-256 of the empty string, not an empty value.
- Clock skew. The signature covers
x-amz-dateand AWS rejects anything more than 15 minutes off.
Fifteen-minute validity
Because the timestamp is signed, the header expires 15 minutes after generation. That is a deliberate replay defence, and it means a signature you generate here is for immediate use.
Use the SDK
Every AWS SDK implements SigV4 correctly, including the service-specific path-encoding quirks. Hand-rolling it is worth doing only when you are debugging, working in an environment with no SDK, or building a signing proxy. This tool is for the first of those.
Frequently asked questions
Why does my S3 request fail when the same signature works for API Gateway?
S3 does not double-encode the path; most other services do. If your path contains anything requiring encoding, that difference alone breaks the signature.
Do I need x-amz-content-sha256?
S3 requires it. Other services accept the payload hash in the canonical request without the header. Including it is harmless and makes the request self-describing.
Can I use temporary STS credentials?
Yes. Supply the session token, and it is included as x-amz-security-token in the signed headers. STS credentials start with ASIA rather than AKIA.
Is it safe to enter my secret access key?
The signing runs in your browser and nothing is transmitted. That said, use a scoped test credential rather than a production administrative key — and if you have pasted a production key anywhere, the revocation generator has the rotation commands.