RFC 9421 signature base
Paste a signed HTTP request and see the signature base over which the signature was created. Ideal for comparing with your own implementation.
How it works
With HTTP Message Signatures, not the whole request is signed but a signature base made of the components listed in the Signature-Input header. The tool reads request line and headers, derives components such as @method, @path and @authority and assembles the signature base line by line following RFC 9421. The last line contains the signature parameters.
What it helps with
The most common cause of invalid HTTP signatures is a deviating signature base: a header written differently, a missing path part, a wrong host. With the tool, you compare your implementation's base with the one a verifying party expects. The example from Appendix B.2.6 of the standard yields exactly the base published there.
What the tool does not do
It does not verify the signature and knows no keys. Components with parameters such as ;sf or ;key are shown but not mapped. To verify the signature, use the verification page or the HTTP signature guide.
Typical uses
- Testing an implementation: compare your own signature base line by line with the expected one.
- Troubleshooting Web Bot Auth: find out why a website rejects a signed request.
- Checking configuration: see which components an agent actually signs and whether the path is among them.
Troubleshooting tips
Header names are written in lowercase, values taken over without leading and trailing spaces. Several headers of the same name are joined with a comma and a space. The last line must contain the signature parameters exactly as they appear in the Signature-Input header.
Frequently asked questions
Why does the tool assume https as the scheme?
A request line usually contains only the path, not the scheme. For @target-uri and @scheme, the tool therefore assumes https and says so.
Which components are supported?
Header fields plus @method, @authority, @path, @query, @scheme, @request-target and @target-uri. Components with parameters are reported as not mapped.
Does this also apply to Web Bot Auth?
Yes. Web Bot Auth and the Trusted Agent Protocol use HTTP Message Signatures following RFC 9421 and therefore the same signature base.
What do I do with several signatures in one request?
The tool takes the first signature from Signature-Input. Further signatures can be checked by temporarily removing the other entries.
Can I use the tool for server responses?
No, the tool builds the signature base for requests. Responses also use components such as @status, which are not mapped here, and need a verification of their own.