Webhook Signature Validator
Enter webhook payload and secret to compute and verify the HMAC-SHA256 signature against platform-specific formats for GitHub, Stripe, Twilio, Svix, and generic HMAC.
Calculations run locally in your browserWebhook Signature Validator
The Webhook Signature Validator computes and verifies HMAC-SHA256 signatures against GitHub, Stripe, Twilio, and Svix webhook formats with replay attack timestamp checking.
• Verify a webhook signature during integration development
• Debug a webhook that's failing signature validation in production
• Understand GitHub's X-Hub-Signature-256 header format
• Check timestamp validation for replay attack prevention
How Webhook Signature Validator fits into production review
Webhook Signature Validator belongs in the intake path for events from Stripe, GitHub, Twilio, Svix, and similar systems where the sender proves possession of a shared secret. The review is not just whether a hex digest matches. The exact signature base matters: Stripe signs a timestamp plus raw body, GitHub signs the raw request body, Twilio historically signs URL and parameter material, and Svix includes message id and timestamp fields. Mixing those bases creates false failures and, worse, false confidence.
In production work, the raw bytes are the evidence. A framework that parses JSON, reorders fields, normalizes newlines, changes charset, or decompresses a body before verification may make the same payload verify differently from the provider's own calculation. The right review record includes the provider header names, the timestamp, the canonical string used for HMAC, the algorithm, and which secret version was selected. That is the material an incident responder needs when a webhook queue starts accepting or rejecting events unexpectedly.
Replay handling is part of the same decision. A valid HMAC only proves that the message came from a party with the secret at some point; it does not prove that the message is fresh. Check the timestamp tolerance, duplicate event id storage, and secret-rotation path alongside the calculated signature. A useful finding says whether the endpoint can reject stale or repeated delivery attempts without losing legitimate retries.
When this result can be misleading
A passing signature can hide an authorization problem. The sender may be authentic while the event type is not allowed for that endpoint, the account id may belong to a sandbox tenant, or the event may reference an object that the receiving service should not mutate. Signature verification should sit before business logic, but it does not replace provider-account scoping, tenant checks, idempotency, or event-type allowlists.
Infrastructure can corrupt the verification input. CDN rules, request body limits, middleware, logging filters, and API gateway transformations can all alter the bytes used for HMAC comparison. That is why a local paste test is weaker than a captured request from the edge path. If production rejects a provider event while the dashboard claims it was signed correctly, inspect whether a proxy changed the body or the URL before it reached application code.
Secret rotation creates another misleading state. Providers may send multiple signatures during overlap windows, and receivers may accept old and new secrets for a limited time. A single successful comparison does not prove the active secret inventory is sane. Record which secret matched, whether expired secrets still match, and whether the deployment can remove the old value without dropping retries already in flight.