“Honeypot or CAPTCHA: which should I use?”

Honeypot or CAPTCHA: which should I use?

Updated October 18, 2026By the CaptchaKit team

Short answer

Use a honeypot first and a CAPTCHA when the honeypot stops being enough. A honeypot is a form field hidden from people but present in the HTML; scripts that blindly fill every field reveal themselves, and your server quietly drops those submissions. It costs nothing and no real visitor sees it. A CAPTCHA costs a few seconds of visitor time and needs server-side verification, but it also stops scripts built to skip honeypots. On quiet forms the honeypot often wins; under real attack it does not.

Side by side

Honeypot versus CAPTCHA as form protections.

Honeypot versus CAPTCHA as form protections.
Feature	Honeypot	CAPTCHA
Visitor sees it	No, it is hidden	Often visible; invisible variants exist
Catches naive autofill bots	Yes Yes	Yes Yes
Stops scripts built for your form	No No	Partly Partly
Server work	Reject if the field is filled	Verify a token with your provider
Cost to real visitors	None	A few seconds
Main failure mode	Targeted scripts skip it; browser autofill can trip it	Some visitors cannot complete it

How a honeypot works

The field looks ordinary to a script and invisible to a person. Hide it with CSS, keep it out of the tab order, and give it a name worth filling, such as company_website. On the server, any submission with a value in that field is a bot: drop it quietly, without an error that teaches the script anything.

Hide the field from assistive technology too, so nobody is asked to skip a field they cannot perceive, and do not rely on display: none alone, since some bots parse styles.

<input type="text" name="company_website" tabindex="-1"
       autocomplete="off" aria-hidden="true"
       style="position: absolute; left: -9999px;">

What a CAPTCHA adds

A CAPTCHA makes the visitor prove something a generic script cannot fake, and the proof is a token your server verifies with the provider. That closes the honeypot's gap: a bot that renders the page, skips known honeypot names and submits headlessly still has to pass the challenge. The trade is real: the challenge takes time, it must be accessible to everyone, and it adds a server call to every submission. See are CAPTCHAs accessible for the obligations that brings.

Where each one fails

Honeypots fail against anything purpose-built for your site: a headless browser that only fills visible fields, or a bot taught your field name. CAPTCHAs fail the visitor who cannot solve the challenge, and any challenge can be farmed out to solving services by a determined attacker, which is why the server-side check and rate limits matter more than the puzzle itself. Neither is a wall; both are cost multipliers.

Layer them, cheapest first

The practical order: a honeypot on every form, because it is free; rate limits per IP on the server; then a CAPTCHA on the forms abuse actually targets, usually signup, login and checkout. A honeypot and a CAPTCHA can share one form, since the two checks are independent. See the signup and contact form guide for matching the challenge to the form.

Questions

Is a honeypot enough on its own?

On a quiet form, often yes. Targeted bots skip known honeypots, so watch your spam volume.

Do bots know about honeypot fields?

Generic scripts fill every field and fall in. A script written for your form can be taught to skip yours.

Can a honeypot break accessibility?

It can if the field is reachable by keyboard or screen reader and someone fills it. Hide it from assistive technology and keep it out of the tab order.

Can I use a honeypot and a CAPTCHA together?

Yes, and it is a common combination: the honeypot catches the lazy scripts, the CAPTCHA the determined ones.

Which CAPTCHA pairs well with a honeypot?

Any of them; the two checks are independent. A short game such as CaptchaKit's keeps the visible cost low.

What about invisible CAPTCHAs?

They remove the visible cost but still run a check and a server verification. See reCAPTCHA alternatives for the options.