Cut down spam on your forms
Five minutes, once per site. Four settings, all under LocalForm → Settings → Security, all site-wide: turn them on before you advertise a form rather than after the first hundred junk submissions.
None of them asks your visitors to prove anything. There is no puzzle to solve, no images of traffic lights, and nothing to sign up for.
1. Spam Protection
Turn it on. It adds an invisible honeypot field to every form: a question no visitor can see, which automated scripts fill in anyway. A submission that has filled it in is discarded.
This is the one that does most of the work, and it costs a real visitor nothing - people using a screen reader or a password manager are unaffected, because the field is hidden from them too.
The field's name is different on your site than on anyone else's, and changes daily, so a bot cannot be taught to skip "the LocalForm honeypot" once and be done with it.
2. Browser check
Also on the Spam Protection card, and also invisible. It turns away two things the honeypot alone lets through:
- Submissions that never opened your form. Most spam is sent by a script posting straight to your site, having read the form's address once. Anything that did not load the page in a real browser is rejected.
- Submissions sent too fast. A script fills a form in milliseconds. A person does not. Anything arriving within about three seconds of the form loading is treated as automated.
Leave it on unless you have a specific reason not to. It does nothing to a visitor filling in your form normally, and someone who leaves the page open for hours is quietly given a fresh pass when they submit, rather than being shown an error.
Two things worth knowing:
- It needs JavaScript - but so does submitting a LocalForm form at all, so it rules out nobody who could have registered anyway.
- After updating the plugin, sites that serve cached pages get a 24-hour grace period before the check is enforced, so a form cannot break mid-campaign while an old cached copy of the page is still being served. If you run a caching plugin, clearing its cache after updating makes the check take effect immediately.
Repeated rejections from this check or the honeypot count against the sender: after a handful, that visitor is turned away outright for the rest of the rate-limiting window, so a bot cannot keep trying for free.
3. Rate Limiting
Cap how many submissions one IP address may send within a time window.
Pick something a person could never hit but a script will: for a registration form where each visitor submits once, a handful per hour is generous. Be more careful on a form a household or an office might legitimately submit several times in a row - people behind one router share an IP address.
4. Duplicate Submissions
Block a repeated, identical submission for a number of seconds. A blocked resubmission shows "This submission has already been received." instead of saving again.
This is aimed at a different problem from the other two: the visitor who double-clicks the button, or reloads the thank-you page. A window of a minute or two catches both without ever bothering anyone.
What to expect afterwards
The honeypot and the browser check together stop the great majority of automated spam, which for most sites is all of it. What they do not stop is a human being typing junk into your form by hand - nothing invisible can, and that is what the other two settings and your own eye on Responses are for.
If junk is still arriving after all four are on:
| What you see | What tends to help |
|---|---|
| Bursts of similar submissions, seconds apart | Tighten Rate Limiting - a burst from one script is one IP address |
| A trickle of hand-typed junk | Close registration when you do not need it open (registration limits), or add a question a bot-farm worker will not bother answering |
| The same submission stored twice | Raise the Duplicate Submissions window |
| Real registrations being blocked | Loosen Rate Limiting first - it is the setting most likely to catch a genuine visitor, since people behind one router share an IP address |
| "Submission rejected" right after a plugin update | Clear your caching plugin's cache, so visitors stop being served the old cached version of the form page |
Fewer places to be found
Two habits that matter more than any setting:
- Close what you are not using. A form that no longer takes registrations should be set to Draft, or given a closing time - see registration limits.
- Do not leave test forms published. They are indexed like any other page, and they are found.
Developers hooking in their own rules - a members-only window, an allowlist - can filter the final accept/reject decision with localform_is_accepting. The spam checks themselves are tunable with localform_min_fill_seconds, localform_token_max_age and localform_spam_block_threshold.