Get the next one in your inbox.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.
Bots have gotten more sophisticated, but most spam hitting your form still comes from simple scripts that fill in every field they can find — which is exactly what a honeypot catches.
Get an instant summary, key takeaways, action items, and answers to your questions about this article.
Honeypot fields still work because the large majority of form spam comes from unsophisticated, scripted bots that fill in every input they can find in a form's HTML, including ones hidden from human view. A honeypot is a field hidden from real visitors via CSS that silently flags or rejects any submission that fills it in.
It's true that some bots today are genuinely advanced — full browser automation, behavioral mimicry, even solving CAPTCHAs with paid human-solving services. It's also true that the volume of spam hitting a typical public contact form doesn't come from those bots. It comes from cheap, disposable scripts that parse a form's HTML and submit a POST request filling in every field they find. No browser rendering, no visual inspection, no judgment about what's actually shown to a person.
That gap is exactly what a honeypot exploits.
A honeypot is an ordinary input added to your form, hidden from real visitors with CSS — positioned off-screen, given zero height, or set to display: none in a way that still leaves it present in the markup (rather than removed entirely or marked with type="hidden", which some bots specifically know to ignore). A human never sees it and never fills it in. A script scanning the raw HTML for inputs to fill doesn't know the difference and fills it anyway.
Any submission where that field comes back non-empty gets silently flagged as spam, no CAPTCHA puzzle, no extra click, nothing for a legitimate visitor to notice or be slowed down by. FormBridge's spam protection includes exactly this: a hidden field, named honeypot by default or renamed to whatever you choose, that quietly rejects any submission that fills it in.
A honeypot's whole value comes from a bot's laziness. Anything written specifically to target your form — a script that's been told to skip fields matching common honeypot patterns, or a human manually filling out the form to send spam — walks right past it. It's also no help against submissions that are technically well-formed but low-quality, since it only checks one signal: did something fill in a field it shouldn't have.
That's why it belongs as a first layer, not the only layer. Pair it with CAPTCHA for a stronger check on suspicious traffic, or an authorized-domains list if you know exactly which sites should be submitting to your endpoint. The honeypot's job is to filter out the bulk of low-effort spam for free, so whatever comes after it only has to deal with what's left.
No. A honeypot catches unsophisticated bots that indiscriminately fill every field, but it does nothing against a targeted script written specifically for your form, or a human filling it out by hand. It's best used as a free first layer alongside other protections like CAPTCHA or authorized domains, not a complete solution.
It's a normal form input that's visually hidden using CSS (for example, positioned off-screen or given zero size) rather than removed with the HTML `hidden` attribute or type=\'hidden\', which some bots specifically know to skip. Because it's still present in the page's markup, a bot scanning the raw HTML for fields to fill still finds and fills it.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.