Guide · 5 min read
Stopping spam on public forms
Updated 2026-09-17
TL;DR
Combine a challenge that filters bots without a puzzle for humans, a rate limit that caps how fast one source can submit, and required fields that make junk responses harder to fire off blind.
Any form with a public link eventually attracts bots, not because it's popular, but because bots submit to any form URL they find, automated and untargeted. The fix isn't to make humans prove they're human with a fiddly puzzle — it's a layered approach: a lightweight challenge that runs invisibly for most people, a limit on how fast one source can submit, and validation that makes a blind, scripted submission more likely to bounce. This guide covers what actually works and what to skip.
Challenge-based anti-spam
Modern anti-spam services run a challenge in the background — checking browser signals and behavior — and only show a visible puzzle to traffic that looks suspicious. Most real visitors never see anything at all, which is the point: spam filtering that adds friction for legitimate respondents just trades one problem for another.
This is a meaningfully better trade-off than an old-style CAPTCHA that interrupts every single submission, since it only asks for confirmation from the traffic that actually looks automated.
Rate limiting
A rate limit caps how many submissions can come from one source in a given window, which blunts the most common bot pattern: a script firing the same form repeatedly as fast as it can. It doesn't require the bot to look suspicious first — it just stops volume.
Rate limits should be generous enough that a real person filling out a form a few times (testing it, or a family submitting separately from one connection) never notices them, and tight enough that a scripted flood gets cut off quickly.
Required fields as a filter
Marking the fields you actually need as required does double duty: it keeps your response data usable, and it raises the bar for a bot that's submitting blind without inspecting the form's structure. A submission missing required data gets rejected before it ever reaches your response list.
This isn't a primary defense on its own, but layered with a challenge and a rate limit, it closes off the crudest scripted submissions that don't bother filling in a real payload.
What to skip
Resist the urge to add a visible security question or an obvious math puzzle to every form — it filters out unsophisticated bots but also frustrates real respondents, and a determined bot operator just adapts to it anyway. A background challenge that only escalates for suspicious traffic gets you the same filtering without that tax on real people.
Also resist reflexively locking a form behind a password to stop spam. Passwords are for restricting who can see the form at all, not for spam — use them when you genuinely want to limit access to a known group, not as an anti-bot measure for a public form.
How YeetForm handles it
In YeetForm, public form submissions are checked against Cloudflare Turnstile (a background challenge, not a visible puzzle for most visitors) and are rate-limited server-side, on top of whatever fields you've marked required. Turnstile no-ops automatically in local development or any environment where it isn't configured, so testing isn't blocked.