Two ways to answer the same question — is this a person? — with opposite costs. What each one catches, what it misses, and why the comparison is less useful than it looks.
A CAPTCHA asks the visitor to prove they are human. A honeypot asks nothing and watches whether an invisible field gets filled in. They are opposite philosophies: one puts the burden on the person, the other on the page.
| Honeypot | CAPTCHA | |
|---|---|---|
| Visitor sees | Nothing | A challenge on every submission |
| Conversion cost | None | Real, and hardest on mobile |
| Accessibility | Safe if hidden correctly | A known barrier needing an alternative |
| Effort to add | Minutes | Minutes, plus a third-party account |
| Catches naive bots | Yes | Yes |
| Catches commercial form-fillers | Rarely | Sometimes |
| Catches paid human fillers | No | No |
| Fails | Silently, invisibly | Loudly, in front of the customer |
A form-filler that parses your HTML and populates every input it finds will fill the honeypot too, and identify itself. That describes a great deal of low-effort spam traffic, which is why the technique has survived: it is close to free and it removes the bottom tier.
The ceiling arrives with tools that render the page properly. Once a bot evaluates
computed styles it can see that a field is positioned off screen or set to
display:none, and skip it. Once it has seen a thousand sites it also
recognises the naming conventions. A honeypot is a single rule, and single rules are
readable.
Hiding the field with display:none and stopping there. Some assistive
technology still exposes it, so a screen reader user can focus the input, fill it
in, and be rejected without ever knowing why. Add
aria-hidden="true" and tabindex="-1", and never use
type="hidden" — bots skip that by default, so it catches nothing at
all.
More than a honeypot, and less than its reputation suggests. A challenge stops the traffic that will not or cannot execute it, which is a broader set than "bots that fill hidden fields". But solving services have made passing one cheap to buy, and the score-based invisible variants make a judgement before the form is filled in — so they never observe the composition of the submission at all.
The cost is not theoretical either. Every real customer pays it, on every submission, and the people who pay most are the ones already having the hardest time: mobile users, people with low vision, anyone with a motor impairment. See the reCAPTCHA comparison for what changes when detection moves after capture.
Add the honeypot. It is nearly free, it costs your visitors nothing, and it removes real volume. There is no argument against it as long as you hide it properly.
Do not expect either to be sufficient. The comparison people usually want — which one should I choose? — has an unsatisfying answer: on modern automated traffic, both are weak, and the honeypot is merely weak for free while the CAPTCHA is weak at the expense of your conversion rate.
Do not run both. Stacking gates gives you the friction of the CAPTCHA and very little extra catch, since the bots a honeypot misses are largely the ones a CAPTCHA misses too. Network-level protection at your CDN sits at a different layer and is fine alongside either.
Scoring behaviour instead of testing one property. SpamKill renders two versions of every form — clean for people, obfuscated for automated fillers — and judges the submission on how it was composed, at 99.9% accuracy across more than 100M+ submissions screened for 1,500+ businesses. No challenge, no hidden-field trick to discover: the rare flagged person verifies in one step and continues, and anything held is recoverable. From $29/month with a 30-day free trial, no credit card.
For your visitors, unquestionably — a honeypot is invisible and costs them nothing, while a CAPTCHA taxes every real person to inconvenience a few bots. For raw catch rate on modern automation, neither is strong. The honest comparison is that a honeypot is free and catches the lazy traffic, and a CAPTCHA is expensive in conversion and catches only slightly more.
Against naive form-fillers, yes. Against commercial spam tooling, decreasingly — those tools render the page, read computed styles, and skip inputs that are visually hidden or named like a trap. Keep a honeypot because it is nearly free, but do not treat it as your defence.
Not with type="hidden", which every bot ignores by default. Use CSS to take it out of the visual flow, give it an innocuous name that fits your form, and hide it from assistive technology with aria-hidden="true" and tabindex="-1" so a screen reader user never focuses it. A honeypot that a blind visitor fills in is a trap for the wrong person.
You can, and it is usually the wrong trade. You keep the full conversion cost of the CAPTCHA while adding a filter that only catches bots the CAPTCHA would likely have caught anyway. If you are going to accept friction, get something back for it.
Reading how the submission was actually composed — interaction, typing cadence, field order, timing — instead of testing one property of it. There are many signals rather than one rule, they update as automation changes, and a bot has to defeat all of them simultaneously.
Paste your form HTML into the Form Transformer and compare what a person receives with what an automated filler receives.
Open the Form Transformer