splitforms.com
no captcha · no third-party js

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.

Hiding technique
Hidden — paste after <form>

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;">
Visible — verify trap fires

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;">
Drop submissions where field is non-empty

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, _gotcha,
// hp, honey, trap, do_not_fill, leave-blank, fax, website, url
// are all recognized as honeypot fields. Submissions where any are
// non-empty get tagged as spam in your dashboard.

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 a substantial portion of contact-form spam — somewhere between 40% and 60% in our experience — 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 common honeypot field names — botcheck, _gotcha, hp, honey, trap, do_not_fill, leave-blank, fax, website, url — and any submission where one of those fields is non-empty gets tagged as spam. You don't have to write the rejection logic; the field 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

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 roughly 40–60% of contact-form spam 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 ~600KB of 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 + AI classifier 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?

Use a name a bot would plausibly fill. Bots prioritize fields that look 'real' — website, phone-number-confirm, email_verify, company_url, fax. Avoid names that scream 'honeypot' (literally honeypot, trap, _gotcha) — sophisticated bots strip those before submitting. The default 'botcheck' is a sensible middle ground: human-readable, common in form-backend documentation (so devs recognize it), but not so obviously a trap that bots skip it. splitforms recognizes botcheck, _gotcha, hp, honey, trap, do_not_fill, leave-blank, fax, website, and url as honeypot fields automatically — submissions where any of those are non-empty get classified as spam.

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. splitforms shows honeypot-triggered submissions in the dashboard with a 'spam: honeypot' tag so you can monitor real catches over time.

Honeypot in your HTML. Spam handling on the server.

splitforms recognizes honeypot fields automatically and runs an AI spam classifier on every submission. Free for 1,000 submissions per month — point your form's action at our endpoint and you're done.

Try splitforms free →