hidekazu-konishi.com

AWS Signature Version 4 Request Signer and Explainer - Visualize SigV4 Signing Step by Step

First Published: 2026-06-24
Last Updated: 2026-06-24

Features

• Step-by-step explainer: See the canonical request, its hash, the string to sign, the signing key chain (kDate, kRegion, kService, kSigning), the signature, and the Authorization header - each in its own copyable box.
• Faithful to the official process: Implements AWS Signature Version 4 exactly as documented in the AWS IAM User Guide, including canonical URI and query encoding, header normalization, and credential scope.
• Validated against the official example: The S3 GET Object preset reproduces the signature published in the AWS worked example.
• Examples included: S3 GET Object, EC2 DescribeInstances (query string), and an API request with a JSON body - all using AWS public dummy credentials.
• Temporary credentials supported: Add a session token to sign with x-amz-security-token, or use UNSIGNED-PAYLOAD for S3.
• Fully client-side: Uses the self-hosted CryptoJS library for SHA-256 and HMAC-SHA256. No network calls, no data sent, nothing stored.
• Accessible UI: Labelled form controls, 44px minimum touch targets, and WCAG AA contrast.

How to Use

1. (Optional) Click an Example to load a preset request, or fill in the fields yourself.
2. Choose the HTTP method, enter the full Request URL (including any query string), the Region, and the service code.
3. Set the Timestamp (or click Now (UTC)) and enter an Access Key ID and Secret Access Key - use dummy or temporary credentials only.
4. Add any Additional Headers and a Request Body if needed, and choose how the payload hash is computed.
5. Click Compute Signature and read each signing stage in order. Use the Copy buttons to copy any stage, the Authorization header, the signed headers, or the curl command.

About This Tool

AWS Signature Version 4 (SigV4) is the process AWS uses to authenticate API requests. The caller derives a signing key from their secret access key and uses it to sign a canonical representation of the request; AWS recomputes the same signature on its side and rejects the request if the two do not match. This tool reproduces that process entirely in your browser so you can see exactly how a request is signed, without sending anything to AWS.

The signing flow is shown in six stages: (1) the Canonical Request normalizes the method, URI, query string, headers, signed-header list, and payload hash into a single string; (2) that string is hashed with SHA-256; (3) the String to Sign combines the algorithm, timestamp, and credential scope (date / Region / service / aws4_request) with that hash; (4) the signing key is derived through the HMAC chain kDate → kRegion → kService → kSigning; (5) the Signature is the HMAC-SHA256 of the String to Sign with that key; and (6) the Authorization header assembles the credential, signed-header list, and signature for the request. The tool also builds an equivalent curl command, which it never executes.

The algorithm follows the AWS IAM User Guide and was verified against AWS's published Amazon S3 GET Object worked example as of 2026-06-23: the tool reproduces the documented signature exactly. SigV4 details and service-specific behavior (for example, single vs. double URI encoding) can change over time - confirm against the current AWS documentation before relying on a signature for production debugging.

Frequently Asked Questions

What is the credential scope?
The credential scope is YYYYMMDD/region/service/aws4_request. It appears in the string to sign and is also used to derive the signing key, which restricts the resulting signature to a specific date, Region, and service. The Region and service codes must be lowercase.

Why does my signature differ from the one AWS computed?
The most common causes are: the timestamp does not match the x-amz-date header (or is outside the allowed clock skew); the set of signed headers differs; header values were not normalized (lowercased names, trimmed values, collapsed spaces, sorted); the payload hash does not match the body; or the Region or service code is not lowercase. Header and query ordering must be exactly as specified.

Is my secret access key sent anywhere?
No. The signature is computed entirely in your browser with the CryptoJS library. There are no network requests, and nothing is written to localStorage or cookies. Still, treat secret keys as sensitive and use temporary or dummy credentials with this tool.

What are UNSIGNED-PAYLOAD and x-amz-content-sha256?
Amazon S3 requires an x-amz-content-sha256 header that carries the SHA-256 hash of the payload (the hash of an empty string for requests with no body). For large or streaming uploads you can set the literal value UNSIGNED-PAYLOAD as both the hashed payload in the canonical request and the header value.

Does this tool support SigV4A (multi-Region)?
No. This tool implements SigV4 (AWS4-HMAC-SHA256). SigV4A uses AWS4-ECDSA-P256-SHA256 (ECDSA over the NIST P-256 curve) with an X-Amz-Region-Set header and a credential scope that omits the Region. AWS SDKs and the CLI switch to SigV4A automatically for Amazon S3 Multi-Region Access Points.

Related Tools

• Hash Generator Tool - Multi-Algorithm Hash Calculator with File Support - compute SHA-256 and other digests, useful for payload hashes.
• AWS CLI Command Generator - Build AWS CLI Commands from GUI Form - generate AWS CLI commands that sign requests for you.
• ARN Parser and Builder Tool - parse and build Amazon Resource Names.
• JWT Decoder Tool - decode and inspect JSON Web Tokens.

Related Articles

• AWS IAM Policy Evaluation Logic Explained Step by Step
• AWS IAM Glossary
• Amazon S3 Security and Access Control Guide
• History and Timeline of AWS Identity and Access Management (IAM)

Important Notes

• This tool computes AWS Signature Version 4 entirely in your browser for learning and debugging, following the official signing process as of 2026-06-23. Your access keys are never sent anywhere and are not stored. Do not paste production secret keys; use temporary or dummy credentials. This tool does not send the signed request.
• This tool implements SigV4 (AWS4-HMAC-SHA256). SigV4A (AWS4-ECDSA-P256-SHA256) is out of scope.
• The canonical URI path is URI-encoded once, which matches the AWS IAM reference and the Amazon S3 worked example. A few non-S3 services historically double-encode the path, so a signature for those services may differ.
• When you send a real request, AWS rejects timestamps outside an allowed clock skew window. The date in the credential scope must match the date in x-amz-date.
• Source of the signing process: AWS IAM User Guide, Create a signed AWS API request and Elements of an AWS API request signature (verified 2026-06-23).