Anti-spam teardown · Trap

Honeypot fields

Put a field on the form that no human will ever fill in. Anything that fills it is not a human. The idea is twenty years old, it is free, and it is still worth running — with two caveats that are rarely stated.

Corey Haines · San Diego · Aug 2026

One of 12 anti-spam teardowns. Bypass techniques change; this page states its date so you can judge how stale it is.

The short answer

Keep it. It costs nothing and it catches indiscriminate DOM-filling automation that challenges miss. But a naive honeypot is detected trivially, and — the part almost nobody handles — when it rejects a real customer it does so silently, by design.

What it stops

Scripted botsMass submitters that never render your page.
Yes
Targeted automationHeadless browsers, solver services, residential proxies — aimed at you.
No
Paid humansPeople doing it by hand, cheaply.
No
Real people, bad leadsGenuine humans who were never going to buy.
No
Cost to the real buyerWhat it asks of the person you actually wanted.
None

How it works

You add an input a real visitor will never interact with, give it a name a bot finds attractive — email2, url, company_website — and discard any submission that arrives with it populated. No challenge, no third party, no visible cost.

The mechanism is a bet about behaviour: automated fillers parse the DOM and fill what they find, while people fill what they see. That bet was excellent in 2008. It is now roughly a coin flip, depending on what is attacking you.

What it actually stops

Generic form-filling automation — the kind that hits ten thousand sites a day and cannot afford per-target logic. That is a large share of the internet’s background spam and it costs you nothing to remove.

It also produces a useful diagnostic almost nobody uses. A honeypot that catches nothing is telling you something specific: whatever is hitting your form is looking at your form. That is the moment to stop tuning traps and start reading logs.

I do have a hidden field on the form, and none of the bots filled it out. That’s what led me believe initially that it was actual people or a person.
u/robwalte · r/marketing · Jun 2024

How it’s defeated

By reading the same CSS the human’s browser reads. Any filler worth the name skips inputs that are display:none, visibility:hidden, type=hidden, zero-sized, aria-hidden, or positioned off-canvas — which covers essentially every honeypot tutorial published in the last decade.

Hidden fields don’t work any more. You’ll need a technically visible but humanely hidden field to catch these bots.
u/hymnzzy · r/marketing · Jun 2024

“Technically visible but humanely hidden” is the correct instruction and it is harder than it sounds: the field has to be renderable and reachable by the CSS engine while being invisible to a person and skipped by assistive technology. In practice that means a real element, sized and positioned so it never occupies visual space, tabindex=-1, autocomplete=off, and an aria-hidden label the screen reader announces as “leave this field empty.”

Which brings the second failure, and it is the one this page exists to say. Password managers fill fields named url and company. Browser autofill fills fields named address2. Screen readers announce fields their users then complete, helpfully. Every one of those is a real customer, and every one of them is rejected without a message, without a log line, and without anyone finding out.

When it’s still worth using

Always. There is no cost, no vendor, no consent banner and no friction, and it catches a class of traffic that challenges do not. It is the highest-return line of anti-spam code you will write.

Just do not let a quiet honeypot convince you the form is fine. Quiet means the attacker read your page, which is worse news than a full trap, not better.

The same mechanism has a second job worth knowing about — see hidden fields for how the invisible inputs carrying your GCLID and UTMs are the ones a filler reads first.

What to pair it with

No single method on this site is sufficient. These are the ones that fail differently enough to be worth running alongside it.

Time-traps and submit-delay heuristics
The other free, invisible signal. Neither is sufficient; both are close to free, and they fail on different attackers.
Cloudflare Turnstile
Covers the fillers that read your CSS properly, which is exactly the group a honeypot cannot see.
Email verification
Catches what gets past both, at the address rather than at the browser.

Concepts on this page