Honeypot vs reCAPTCHA vs hCaptcha: spam protection compared

If your form is on the open internet, it gets spam. The question is which combination of defenses you use, what tradeoffs you accept, and how loud the friction is for legitimate users. This post compares the three most common layers - honeypot, reCAPTCHA, and hCaptcha - and explains why most production setups use all three, in order, with one or two more behind them.

What does each spam-protection layer actually do?

Honeypot

An invisible field that bots fill in and humans don't. Catches the most basic class of spam - automated form submitters that fill every visible input - at zero user-facing cost. Implementation is one CSS rule and one PHP/JS check.

<form action="https://formspring.io/f/abc123" method="POST">
  <!-- visible fields -->
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>

  <!-- honeypot: hidden from humans, visible to bots -->
  <div style="position:absolute;left:-9999px" aria-hidden="true">
    <label>Leave this empty: <input type="text" name="website" tabindex="-1"></label>
  </div>

  <button>Send</button>
</form>

Server-side: if website is non-empty, drop the submission silently.

The implementation looks trivial; the details that make a honeypot work in production are not. The four that matter:

1. The field name has to look real. Bots that read the form's HTML score every field by name. A field named website-honeypot gets ignored. A field named website, url, or homepage gets filled. The honeypot only works if the bot believes the field is genuine.
2. The field has to be ignored by autofill. Naming the honeypot email, phone, address, or name triggers the browser's autofill on legitimate human visitors and they get classified as spam. The safe names are obscure-but-plausible: website, subject_alt, url, nickname.
3. The CSS has to hide the field from every layout and screen reader. Use position:absolute;left:-9999px plus aria-hidden="true" plus tabindex="-1". A display:none field is also fine but some bots skip it because real forms rarely hide active fields that way.
4. The server-side drop has to be silent. Returning a 400 error to a bot tells it the honeypot exists. Returning a 200 OK with no side effect lets the bot believe the spam landed and stops it from retrying. The latter is the right behaviour for every honeypot in production.

A second pattern worth combining with the field-name honeypot: a time-based honeypot. Record a hidden timestamp when the form renders, compare it to the server-side time on submit, and drop submissions that arrive in under 2 seconds. Humans do not fill out a contact form in 1.4 seconds. Bots do. This catches a meaningful slice of the bots that read CSS and ignore the field-name trap.

Catches: across the forms we run, the majority of low-effort bot spam. User friction: Zero. Invisible. Accessibility: Excellent - screen readers respect aria-hidden. Privacy: Perfect. No third-party calls. Bypass: Trivial for any bot that reads CSS or DOM order.

reCAPTCHA (Google)

Google's challenge-response system. v2 shows a checkbox that may escalate to image puzzles. v3 is invisible and returns a 0.0-1.0 score you act on.

Catches: a meaningful share of bot spam beyond what a honeypot stops (per Google's own reCAPTCHA case studies). User friction: Visible (v2) or invisible (v3, but still tracking). Accessibility: Mediocre - image puzzles are hostile to screen readers, an outcome the hCaptcha accessibility programme was deliberately designed to avoid. v2 has an audio fallback. Privacy: Significant. Loads Google scripts that fingerprint the visitor across sites that use reCAPTCHA. GDPR fragile. Bypass: 2captcha-style farms exist for $1-3 per 1,000 puzzles.

hCaptcha

The drop-in alternative to reCAPTCHA, founded specifically because of reCAPTCHA's privacy and accessibility complaints.

Catches: a share of bot spam broadly comparable to reCAPTCHA in independent published comparisons. User friction: Similar visible challenge to reCAPTCHA v2. Accessibility: Better than reCAPTCHA. Audio fallback works reliably. Privacy: Better than reCAPTCHA. No cross-site fingerprinting; data not used for ad targeting. Bypass: Same farm problem as reCAPTCHA.

* * *

What does none of them catch alone?

• Sophisticated bots that solve CAPTCHAs via human farms.
• AI-driven spam that crafts plausible content (LLM-generated lead-gen spam is 2025's growth area).
• Targeted abuse where the attacker has a person doing the submission.

For these, you need content-based filtering: Akismet, custom rules, or AI moderation.

* * *

How does a layered five-stage setup fit together?

The strongest production setup runs all of these in order:

honeypot → hCaptcha → custom rules → Akismet → AI moderation

A submission has to pass all five to land in your inbox.

1. Honeypot - free, silent, drops the bulk of the dumbest automated traffic.
2. hCaptcha - only triggers on suspect submissions (or always, if you prefer). Drops bots that pass honeypot.
3. Custom rules - block by IP, regex on field values, country code, time-of-day. Catches targeted abuse you can pattern-match.
4. Akismet - content-based scoring against a global spam corpus. Catches anything with known-spam phrasing.
5. AI moderation - flags toxic content, doxxing, scams, abuse. Catches AI-generated spam that passes content scoring because it's grammatically clean.

Formspring runs all five by default on Pro+, in this order, with the option to disable any layer per form.

* * *

Which combination should you use?

Tiny personal site, no abuse history

Honeypot only. Don't add user friction for a contact form that gets 5 submissions a month.

Marketing site, moderate volume

Honeypot + hCaptcha. The captcha barely fires (skip it for trusted regions if your provider supports geo-rules) but stops the obvious bots.

High-volume form (newsletter, signup, RSVP)

All five layers. The cost of a single bad submission scales with volume.

Compliance-sensitive (healthcare, finance, government)

Honeypot + hCaptcha + custom rules + AI moderation. Skip Akismet if its data-sharing model conflicts with your compliance posture (Akismet sends submissions to a third-party scoring service).

* * *

Why does privacy positioning matter for EU audiences?

For EU audiences, reCAPTCHA is increasingly hostile. The Belgian and Italian DPAs have flagged it; some courts have ruled against sites that use it without explicit consent. hCaptcha sidesteps most of that by design.

Formspring uses hCaptcha by default and intentionally doesn't ship a reCAPTCHA integration. If your audience is EU-skewed, this matters more than the tiny accuracy difference.

* * *

Concrete cost comparison

* * *

What about invisible captchas - Turnstile, Friendly Captcha, MTCaptcha?

The interesting category in 2026 is the captcha that the visitor never sees. No checkbox, no image puzzle, no audio fallback - the challenge runs in the background and the form submits.

Cloudflare Turnstile. Cloudflare's privacy-respecting alternative. Runs a JavaScript challenge that profiles browser behaviour without fingerprinting. Free, accurate on common bots, weakest against bots that imitate Chrome on a real Linux box. Best when the site already routes through Cloudflare; the integration steps live in the Cloudflare Turnstile docs.

Friendly Captcha. A German-founded option that runs a proof-of-work computation in the browser. The visitor's CPU spends a fraction of a second on a hash puzzle; bots that fan out across millions of forms cannot afford the aggregate compute cost. No tracking, no fingerprinting, GDPR-clean by design. Accuracy is comparable to the visible-challenge options on most bot traffic. Pricing is per-domain rather than per-submission, which makes it cheap for high-volume forms.

MTCaptcha. Hybrid model - invisible when the visitor scores well, visible challenge as fallback. Strong accessibility story, EU-hostable. Less brand recognition but used by compliance-sensitive industries.

hCaptcha Enterprise's invisible mode. The same hCaptcha vendor, configured to run silently for the majority of visitors and only escalate on suspect signals. The free hCaptcha tier does not include this; it is the enterprise upsell.

The honest comparison: the invisible-captcha category has compressed the visible-captcha category's reason to exist. A visible image puzzle is a 2010s solution. A 2026 form should default to invisible-by-design wherever the threat model allows it, and only escalate to a visible challenge when the invisible layer has flagged the submission as suspect.

The reason the visible captcha persists at all is signalling. A visible challenge tells the visitor "we are serious about spam", which has a non-zero deterrent effect on human abusers. For most contact forms the deterrent is not worth the friction; for forms attached to high-value transactions (account signup, password reset, support tickets that get a free human response) it sometimes is.

* * *

What does each layer cost - in money, friction, accessibility, and privacy?

Cost is multi-dimensional. The pure dollar number per submission misses the costs that compound.

The honest read: the cheapest layers (honeypot, Turnstile, Friendly Captcha) are also the strongest on the non-dollar columns. The expensive layers earn their cost on the residual cases the cheap layers miss, not on the volume.

The hidden cost most teams underestimate is the false-positive cost. A captcha that drops 0.5% of legitimate submissions on a B2B form where each submission is worth a $20,000 deal is wildly more expensive than a captcha that catches 1% more bot traffic. The first principle of layer selection should be "minimise false positives on legitimate humans", not "maximise bot catch rate".

* * *

How does GDPR change the captcha calculus?

The EU has been moving against tracking-based captchas for years and the trajectory is one-way.

• The Belgian DPA fined a site in 2022 for using reCAPTCHA without explicit consent.
• The Italian DPA followed with a similar ruling in 2023.
• The Austrian DPA has flagged Google Analytics under the same logic, and reCAPTCHA inherits the same data-transfer concerns.
• The European Data Protection Board's 2024 guidance on third-party cookies and tracking pixels treats invisible-challenge fingerprinting as "processing of personal data" requiring lawful basis.

The practical upshot: if your audience includes EU visitors, defaulting to reCAPTCHA carries legal risk. The risk is not theoretical anymore; it is documented in published rulings. The drop-in alternatives - hCaptcha, Turnstile, Friendly Captcha - are designed around this reality.

If you must keep reCAPTCHA (because of an existing integration, because a vendor refuses to swap it), the surviving compliance posture requires an explicit consent banner that loads reCAPTCHA only after the visitor accepts. The visitor experience degrades; the legal exposure shrinks. Most teams find the swap is cheaper than the consent UX rework.

* * *

What does this mean for accessibility?

Captcha and accessibility live in tension. Every visible challenge is an obstacle for a visitor with a disability. The categories worth knowing:

• Screen-reader users. Image puzzles are uniformly hostile. Audio fallbacks work, sometimes - hCaptcha's audio is reliable, reCAPTCHA's audio is rate-limited and frequently fails for users who actually need it.
• Motor-impairment users. "Click all the traffic lights" is harder when fine pointing is hard. Checkbox-only challenges are fine; multi-tile selection is not.
• Cognitive-impairment users. Time-pressured puzzles fail the WCAG 2.2 "no time limits" success criterion. Most visible captchas have implicit time limits in their bot-detection logic.
• Visitors on slow connections. Invisible-challenge captchas that load 200 KB of JavaScript block form submission until the script arrives. On a 3G connection in a rural area, the form looks broken for 8 seconds.

The accessibility-aware default is honeypot + invisible-challenge fallback, with a visible challenge only as the last layer and only when the invisible signals are ambiguous. That posture clears WCAG 2.2 AA on most readings and keeps the bot-catch rate on the right side of the cost curve.

* * *

Why "just use Cloudflare Turnstile" isn't the obvious answer

Cloudflare Turnstile is the newer entrant - privacy-respecting, free, accurate. It's a good choice if your site is already on Cloudflare. The reasons it isn't the universal default:

• It requires a Cloudflare account.
• Its accuracy on edge-case bots isn't as battle-tested as hCaptcha at high volume.
• Its detection model relies on Cloudflare's overall traffic graph, which means weaker results on sites with low traffic that don't contribute to the model.

For most teams: hCaptcha is the safer cross-platform default. Turnstile is great if you're committed to Cloudflare's ecosystem.

* * *

Related from this desk

• How CAPTCHA kills form conversion (and what to use instead) - the conversion math behind why universal CAPTCHA is the wrong default, and the adaptive shape that beats it.
• AI spam moderation for forms: beyond regex and keyword lists - the layer that catches the submissions that pass every challenge.
• Form submission automations: routing, enrichment, follow-up - what to do with the submissions that survive the spam funnel.
• Static-site contact form checklist: shipping right in 2026 - where spam protection fits in the broader launch checklist.
• Product side: form backend.

* * *

What this means for your form

Pick a hosted form backend that bundles spam protection. The DIY route - honeypot + reCAPTCHA + custom rules + Akismet + AI - is achievable but expensive in maintenance time. Formspring runs all five by default on Pro+ for $19/mo, with hCaptcha (not reCAPTCHA) as the visible challenge layer.

Try the free tier and see your spam-pass-through rate after a week. Most teams are surprised how clean their inbox gets.