Free signup and contact form checker for static sites

Paste the HTML of a newsletter, waitlist or contact form and get a list of problems that bots, screen readers and mail providers will find before you do: unlabelled fields, a form that puts addresses in the URL, a mailto: action, a honeypot that browsers autofill, and no bot check at all. It runs in your browser and nothing you paste is sent anywhere.

What each check means

• Every field has a label. A placeholder disappears as soon as someone types and is not announced reliably by screen readers. WCAG 2.2 success criteria 1.3.1 and 3.3.2 ask for a real label.
• Email field: type="email", autocomplete="email", required. The first gives phone users the right keyboard, the second lets browsers fill the address (WCAG 1.3.5), the third stops empty submits.
• Method is POST. A form with no method sends a GET request, which puts the address in the URL, in server logs and in browser history. If a script submits the form instead, the attribute is only a fallback, so this is reported as a note.
• mailto: action. It opens the visitor's mail program instead of sending anything, and publishes your address in the page for harvesters. It cannot be rate limited or checked.
• Third-party action. Not wrong, but the address goes to that host, so your privacy text has to name it.
• Honeypot. A text field hidden from people that bots fill in. It should be hidden with CSS or aria-hidden, have tabindex="-1" and autocomplete="off", and carry a name browsers do not autofill: a field called company or website is filled by some password managers and then rejects real people.
• Bot check. We look for Cloudflare Turnstile, hCaptcha, reCAPTCHA, Altcha, mCaptcha, Friendly Captcha or the Signup Shield script. A honeypot alone stops only the simplest form-fillers.
• Status region. An element with role="status" or aria-live is how a screen reader hears "Check your inbox" or "That address looks wrong".
• Message length. A contact form textarea with no maxlength accepts a megabyte of text per request.

What markup cannot tell you

The form is only the front half. Whether it can be turned against strangers depends on the back end that receives it, which this page cannot see. Ask of whatever receives the form:

1. Does it send anything to an address before that address has confirmed? What exactly, and how often?
2. If the same address is submitted 300 times, from 300 IP addresses, how many emails go out? (The answer you want is one.)
3. Does opening the confirmation link subscribe the person, or does it show a button? Mail scanners open links.
4. Is there a daily ceiling on emails sent, and what happens to real visitors when it is reached?
5. If the email provider or your store is down, does it send nothing, or retry in a loop?

The guide Stop subscription bombing on a static site's signup form goes through these in order, and the proof-of-work difficulty tester shows what a proof-of-work check costs on your device. If you would rather not build the back end, Signup Shield Kit is a Cloudflare Worker that answers all five, with three finished sites and an attack simulator, for $15 once.

How this was built: the checks are a plain-JavaScript reading of the markup through the browser's own HTML parser, which never runs the pasted scripts. They mirror the form checker shipped in the kit, extended with the general checks above. They are not a full accessibility audit; for that, use a tool such as axe on the live page.