Moayyad Faris
AWS and DevOps

Processed locally in your browser — not uploaded

AWS SigV4 Canonical Request Debugger

Debug AWS SignatureDoesNotMatch errors by rebuilding the canonical URI, sorted query string, normalized headers, payload SHA-256, canonical-request hash, and string to sign. No AWS secret key is requested and all processing stays in the browser.

No credentials needed · Canonicalization and hashing stay in your browser

Enter the exact request values, then reconstruct the canonical request.

01

How to use

  1. Enter the HTTP method, complete AWS endpoint URL, request headers, payload, and optional SignedHeaders list.
  2. Compare the reconstructed canonical URI, query string, headers, payload hash, and canonical request with your SDK or server logs.
  3. If an Authorization header and x-amz-date are present, compare the generated string to sign as well.
02

Understanding the output

The debugger applies AWS SigV4 encoding, sorting, whitespace normalization, and SHA-256 hashing rules. It intentionally does not request an AWS secret or calculate a final signature.

03

Common issues & tips

  • Signing a header that is absent, normalizing a path twice, or encoding spaces as plus signs changes the canonical request.
  • API Gateway, S3, and some proxies can preserve or normalize paths differently; compare against the exact request received by AWS.

Frequently asked questions

Do I need to paste my AWS secret access key?
No. The debugger intentionally stops before signing. It reconstructs the canonical request and string to sign, which are the safest and most useful values to compare.
Why does the canonical request still differ from AWS?
Use the exact URL, payload bytes, and headers received by AWS. Proxies, SDK encoding, duplicate query parameters, path normalization, and whitespace changes can all alter the canonical form.
Does request data leave my browser?
No. URL parsing and SHA-256 hashing use browser APIs locally.

Related tools