Honeypot Field Generator — copy-paste anti-spam.
Pick a field name, a hiding technique, and accessibility flags. Get a production-ready HTML <input> that bots fill but humans never see — plus a visible test-mode snippet so you can verify the trap fires before deploying.
Production HTML
<!-- Honeypot field — bots fill this; humans never see it. Place immediately after <form>. -->
<input type="text" name="botcheck" autocomplete="off" tabindex="-1" aria-hidden="true" style="position:absolute;left:-9999px;top:auto;width:1px;height:1px;overflow:hidden;opacity:0;">Test mode HTML
<!-- TEST MODE — visible honeypot. Do NOT deploy this version. -->
<!-- Submit once with this field empty (should succeed) and once filled (should be rejected). -->
<input type="text" name="botcheck" autocomplete="off" tabindex="-1" style="border:2px dashed #d97706;padding:8px;background:#fff7ed;color:#9a3412;">Backend rejection logic
// Reject any submission where the honeypot field is non-empty.
// Pseudo-code — works in any backend:
if (formData.get("botcheck")) {
return new Response("ok", { status: 200 }); // silently drop
}
// splitforms handles this for you automatically — "botcheck" is
// one of the names it recognizes (botcheck, _gotcha, hp, honey,
// trap, do_not_fill, leave-blank). No server code needed.How honeypots work
A honeypot is a regular text input that real users never see because CSS hides it from view. Bots crawling your form parse the HTML, see a field they think is real, and dutifully fill it. Your backend reads the submission, notices the honeypot value is non-empty, and silently drops the message before it reaches your inbox. The bot doesn't learn it failed — there's no error page — so it doesn't adapt.
The technique works because bots optimize for volume, not intelligence. A spammer running scrapers across millions of forms can't afford to render each one in a real browser to check which fields are visible. They parse the HTML, fill every input, and submit. Honeypots exploit that exactly: cheap to add, cheap to detect server-side, no UX cost. They catch that whole class of high-volume scripted spam for zero development effort.
The two failure modes are accessibility and autofill. A poorly-implemented honeypot (just display: none with no other flags) can be read out by some screen readers as a real field, confusing assistive-tech users into submitting a value and getting silently rejected. Browser autofill can also try to fill the honeypot if the field has a name like email. The generator handles both: aria-hidden="true" tells assistive tech to ignore the field; autocomplete="off" tells browsers not to suggest values; tabindex="-1" keeps it out of keyboard focus order.
splitforms processes honeypots automatically. The backend recognizes a fixed set of honeypot field names — botcheck, _gotcha, hp, honey, trap, do_not_fill, leave-blank — and any submission where one of those fields is non-empty gets tagged as spam. Pick a name outside that list (even a plausible-looking one like "website" or "fax") and splitforms delivers it as an ordinary field instead. You don't have to write the rejection logic for a recognized name; it just needs to exist in your HTML. The dashboard shows honeypot catches separately so you can see the bot pressure on your form over time.
For a deeper comparison of anti-spam techniques, see our guide on honeypot vs reCAPTCHA — when to use which, and why most contact forms shouldn't ship CAPTCHA at all.
Why honeypots beat CAPTCHA on most forms
- Zero visible friction. Real users see nothing different. CAPTCHA adds 5–15 seconds of cognitive load per submission.
- No third-party scripts. reCAPTCHA loads Google JavaScript that profiles your visitors. Honeypots are pure HTML and CSS.
- Accessibility-friendly. Implemented with aria-hidden, honeypots are invisible to screen readers. CAPTCHA fails WCAG audits regularly.
- Free and unlimited. No API keys, no rate limits, no per-request charges.
- Faster page load. No render-blocking external script.
- Related reading: honeypot vs reCAPTCHA, why your contact form is full of spam, splitforms spam protection.
Honeypot generator FAQ
What is a honeypot field?
A honeypot is a hidden form field that real users never see and never fill in. Bots that auto-fill every input fill it. Your backend drops any submission where the value is non-empty. It's free, fast, accessibility-friendly when implemented correctly, and catches the scripts that fill every input they find at zero CPU cost. Unlike CAPTCHA it doesn't add visible friction, doesn't load third-party scripts, doesn't profile your visitors, and doesn't fail open-source / GDPR audits.
Why are honeypots better than CAPTCHA for low-volume forms?
Five reasons. (1) Zero friction — your real users never see anything different. (2) No third-party JS — reCAPTCHA loads Google scripts that fingerprint your visitors. (3) No accessibility tax — CAPTCHA is one of the worst sources of WCAG complaints; honeypots are invisible to assistive tech when done right. (4) Free — reCAPTCHA Enterprise charges per request once you scale. (5) Faster page load — no external script blocks rendering. CAPTCHA earns its place on high-value forms (signup, payment) targeted by sophisticated bots. For a contact form on a marketing site, honeypot + rate limiting is enough. splitforms ships honeypot + rule-based scoring on every plan including the free tier.
Which hiding technique should I use?
Off-screen positioning (position: absolute; left: -9999px) is the safest single technique because screen readers ignore visually-positioned-off-screen content the same way they handle skip-links. CSS display: none works but some screen readers and modern browsers' autofill still see the field. tabindex="-1" alone doesn't hide the field at all — it just removes it from keyboard focus order. The strongest combination uses all three plus aria-hidden="true" and autocomplete="off" — the field is offscreen, not focusable, ignored by accessibility tools, and not eligible for browser autofill. The generator defaults to the combined recipe.
What field name should I pick?
If you're pointing the form at splitforms, pick from the fixed set it recognizes automatically: botcheck, _gotcha, hp, honey, trap, do_not_fill, or leave-blank — anything else (including plausible-looking names like website, phone-number-confirm, or fax) is delivered as a normal field instead of dropped. 'botcheck' is the sensible default: human-readable and common in form-backend documentation, but not so obviously a trap that a bot skips it. Building your own backend instead? You're free to pick any plausible-looking name a bot would fill, since you write the check yourself.
Why not just type="hidden"?
Bots are smart enough to skip <input type="hidden">. They look for visible-looking fields: text, email, tel, url. A type="hidden" honeypot catches almost nothing. The trick is to declare the field as type="text" (a normal input bots will fill) but hide it visually with CSS so humans never see it. The generator forces type="text" for this reason — choosing 'hidden' would defeat the trap.
Will browser autofill fill the honeypot?
It can if the field has a name like 'email' or 'phone' that triggers form autofill. Two defenses: (1) autocomplete="off" on the honeypot tells the browser not to suggest values for this field, (2) aria-hidden="true" tells browsers it's not a real field. Avoid honeypot names that exactly match common autofill keys (email, name, tel, address). The generator adds both autocomplete="off" and aria-hidden="true" by default and warns when you pick a name that overlaps autofill keywords.
How do I verify the honeypot is actually catching spam?
Use the 'test mode' snippet the generator produces alongside the production version. The test version makes the honeypot visible (no off-screen, no display: none) so you can fill it in yourself and confirm your backend rejects the submission. Submit it once with the field empty (should succeed) and once with the field filled (should fail or get classified as spam). Once verified, swap in the production hidden version. On splitforms, honeypot-triggered submissions are dropped silently — the bot gets the same success response a real visitor does — so they never reach your inbox or dashboard.
Honeypot in your HTML. Spam handling on the server.
splitforms recognizes honeypot fields automatically and runs a rule-based spam filter on every submission. Free for 500 submissions total — point your form's action at our endpoint and you're done.
Try splitforms free →