Dev
Mock Webhook Signature Generator
Webhook signature verification is a critical security check, but it is easy to test only the happy path and never verify that your code actually rejects invalid or replayed signatures. To test the rejection path, you need headers that look plausible but carry a signature that will not verify. This tool generates a set of four webhook-related headers that match the common HMAC-based signing pattern. There are no inputs. Each click generates X-Webhook-Timestamp (a Unix timestamp), X-Webhook-Signature (in the Stripe-style format t={timestamp},v1={hex-signature} with a random 64-character hex value), and X-Webhook-Id (evt_ + 24 random hex characters). A comment block explains how real verification works: compute HMAC-SHA256 over "{timestamp}.{raw_body}" using your signing secret and compare to the v1 value. Paste these headers into a test case and confirm your verifier rejects them — because the signature is random and not computed from the real body and secret. For the success path, compute a real HMAC with your actual signing secret and the matching test body, then verify that passes too.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Click Generate to produce signature headers.
- Copy them into your test.
- Test that your verifier rejects them.
- Compute a real HMAC to test success.
Use Cases
- •Testing webhook signature verification
- •Documenting a webhook scheme
- •Learning how webhooks are signed
- •Seeding signature headers
- •Testing rejection of bad signatures
Tips
- →Always verify incoming webhooks.
- →HMAC covers timestamp and body.
- →The timestamp guards against replays.
- →This signature will not verify by design.
FAQ
what headers does the generator produce
X-Webhook-Timestamp (a Unix timestamp), X-Webhook-Signature (t={timestamp},v1={64-char hex}), and X-Webhook-Id (evt_ + 24 hex characters). A comment explaining the HMAC-SHA256 verification algorithm is included in the output text.
will the generated signature pass verification
No, intentionally. The v1 value is a random 64-character hex string, not an actual HMAC computed from the body and your signing secret. Use these headers to test that your verifier correctly rejects invalid signatures. For a test of the success path, compute a real HMAC over your test payload with your actual signing secret.
how does webhook signature verification work
You compute HMAC-SHA256 over a string combining the timestamp and the raw request body using your signing secret, then compare the result to the v1 value in the signature header. The timestamp is also verified to be recent (typically within 5 minutes) to defeat replay attacks where an attacker resends a captured valid request.
why include a timestamp in the signature
Signing the timestamp alongside the body means a valid signature is only good for the moment it was issued. If an attacker captures a legitimate signed webhook and resends it later (a replay attack), your verifier checks the timestamp and rejects it as too old. Without the timestamp check, any captured valid request could be replayed indefinitely.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.