Spam-Free React & Next.js Contact Form (No CAPTCHA)

Why client-rendered React forms are easy spam targets

A React contact form feels more sophisticated than a plain HTML <form>, so it's tempting to assume it's harder to spam. It isn't. From a bot's point of view, your beautifully-built controlled-component form and a raw HTML form are identical, because the bot never sees either one. It sees the request they make.

Here's the chain of reasoning that makes SPA forms attractive:

• The endpoint is exposed. Your form submits to a URL — an API route, a Server Action, or a hosted backend like https://splitforms.com/api/submit. That URL shows up in the browser's network tab the first time anyone submits. Once a bot has it, your component is irrelevant.
• Bots POST directly. A spam script doesn't render your React tree, hydrate, and click your button. It reads the network request once, copies the JSON shape, and fires its own POST with forged data — thousands of times an hour, from a script that never loaded your page.
• Client-side checks are unreachable. Every guard you wrote in onSubmit, every required attribute, every react-hook-form resolver or Zod schema runs in a browser the bot isn't using. It's convenience for humans and zero friction for bots.

This is the same problem covered in the complete form spam protection guide, viewed through a React lens: the framework that rendered the form has no bearing on what reaches the server. If your defense lives in the component, your defense is optional.

The rule: you can't trust the client, so filter on the server

There's exactly one place a bot can't skip: the server that receives the submission. Whatever protection you want has to live there, after the request arrives, because that's the only code path both a real React form and a forged curl request are forced through.

That reframes the job. You're not trying to make the React form harder to use — you're trying to make the submission easy to judge. A good server-side stack asks a series of cheap questions about every incoming POST:

• Did a field that should be empty arrive with a value? (honeypot)
• Did the submission arrive impossibly fast for a human? (time-trap)
• Is this IP flooding the endpoint? (rate limit)
• Does the content read like spam — link stuffing, banned TLDs, known spam corpora, an LLM-written sales pitch? (content scoring)
• Have we seen and blocked this sender before? (blocklist)

You can build all of that yourself. The honest reality is that most teams build the first two, skip the rest, and then watch AI-written spam walk through the front door. A hosted backend exists so you don't maintain that pipeline: splitforms runs every layer server-side on every submission, in roughly 50ms, regardless of which framework sent it. This post is specifically about keeping a React form spam-free — if you just want to add a working React form first, start with how to add a contact form to a Vite + React app, then come back here to harden it.

Wiring a honeypot + time-trap into a React fetch() form

The two defenses you can implement from the client side — even though they're enforced on the server — are the honeypot and the time-trap. Both come down to sending two extra values in your fetch() body:

• botcheck — a hidden field that must arrive empty. A real user never sees it; a bot that auto-fills every input it finds will populate it and convict itself.
• _start_time — the timestamp captured when the form mounted. The server subtracts it from the arrival time; anything under two seconds wasn't typed by a human.

Capture the start time once with a useRef so it survives re-renders (state would work too, but a ref won't trigger one). Keep botcheck as a controlled value that defaults to an empty string and is bound to a visually-hidden input:

import { useRef, useState } from "react";

export function ContactForm() {
  // Captured once on first render; survives re-renders, never re-triggers one.
  const startTime = useRef(Date.now());
  const [botcheck, setBotcheck] = useState(""); // must stay empty
  const [status, setStatus] = useState("idle");

  async function onSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    setStatus("sending");

    const form = e.currentTarget;
    const res = await fetch("https://splitforms.com/api/submit", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        access_key: "YOUR_ACCESS_KEY",
        name: form.name.value,
        email: form.email.value,
        message: form.message.value,
        botcheck,                      // empty for humans, filled by bots
        _start_time: startTime.current // ms since epoch, set on mount
      })
    });

    const data = await res.json();
    // Spam is rejected server-side: { success: false, message: "Spam detected" }
    setStatus(data.success ? "ok" : "error");
  }

  return (
    <form onSubmit={onSubmit}>
      <input name="name" placeholder="Your name" required />
      <input name="email" type="email" placeholder="Your email" required />
      <textarea name="message" placeholder="Your message" required />

      {/* Honeypot: off-screen, skipped by keyboard + screen readers + autofill */}
      <input
        type="text"
        name="botcheck"
        value={botcheck}
        onChange={(e) => setBotcheck(e.target.value)}
        tabIndex={-1}
        autoComplete="off"
        aria-hidden="true"
        style={{ position: "absolute", left: "-9999px" }}
      />

      <button type="submit" disabled={status === "sending"}>
        {status === "sending" ? "Sending…" : "Send"}
      </button>
    </form>
  );
}

Two details that matter. First, the honeypot is hidden with off-screen positioning rather than type="hidden" — bots know hidden inputs carry tokens to preserve, not fields to fill, so a true hidden input catches nothing. Second, the tabIndex=-1, autoComplete="off", and aria-hidden="true" trio keeps keyboard users, password managers, and screen readers from ever springing your own trap on a real visitor. For the full background on naming and hiding traps correctly, see what is a honeypot field.

Notice what this code does not do: it doesn't decide whether the submission is spam. It just transmits the signals. The actual rejection happens on the server — which is the only place it can't be bypassed. Point this form at splitforms and the backend recognizes botcheck as a honeypot and enforces the time-trap with no server code from you.

Next.js: the fetch() client component and the Server Action

Next.js gives you two distinct shapes for a contact form, and the spam story differs slightly between them.

Option A — a client component with fetch(). This is identical to the React example above. Mark the file "use client", capture _start_time on mount, send botcheck and the timestamp in the JSON body, and let the backend filter. Use this when your form lives on an otherwise-static page and you don't want a server round-trip just to relay a submission.

Option B — a Server Action. Here the handler already runs on the server, so you can read the honeypot and start-time directly from the submitted FormData and bail out early — no separate client check to forge around. But a Server Action still has to deliver the submission somewhere, and its action endpoint still receives direct POSTs. The cleanest pattern is to do a fast local honeypot/time-trap reject for the obvious cases, then forward the FormData to a hosted backend that adds the IP rate limit, content scoring, and blocklist you'd otherwise have to build:

// app/contact/actions.ts
"use server";

export async function submitContact(formData: FormData) {
  // 1. Honeypot — this field must be empty. Bail silently if it isn't.
  if (formData.get("botcheck")) {
    return { success: true }; // look successful so the bot learns nothing
  }

  // 2. Time-trap — reject anything submitted in under 2 seconds.
  const startedAt = Number(formData.get("_start_time")) || 0;
  if (Date.now() - startedAt < 2000) {
    return { success: true };
  }

  // 3. Forward to the hosted backend for IP rate limiting,
  //    ML content scoring, and the account-wide blocklist.
  const res = await fetch("https://splitforms.com/api/submit", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      access_key: process.env.SPLITFORMS_ACCESS_KEY,
      name: formData.get("name"),
      email: formData.get("email"),
      message: formData.get("message"),
      botcheck: "",                                  // already verified empty
      _start_time: Number(formData.get("_start_time"))
    })
  });

  const data = await res.json();
  return { success: data.success === true };
}

The client form that drives this just renders the same off-screen botcheck input plus a hidden _start_time field populated on mount, and passes submitContact to the <form action={...}> prop. Whether a Server Action on its own is even the right tool — versus a dedicated backend — is its own decision, weighed in Next.js 15 Server Actions vs a hosted form backend.

What a hosted backend blocks that client code can't

The honeypot and time-trap are the two layers you can wire up from the form. They catch the high-volume, low-effort majority of spam — but on their own they top out around an 85% catch rate, and they're blind to the spam that matters most in 2026: LLM-written messages submitted through the real form. The remaining layers all have to live server-side, and they're what lifts the catch rate to 95–99%:

• Honeypot — the hidden botcheck field bots auto-fill and real users never see. Catches the dumb, high-volume bots at zero user friction.
• Time-trap (< 2s) — a submission completed in under two seconds wasn't typed by a human. The typical bot fills a form in roughly 50ms; a person takes seconds.
• IP rate limit (1/min) — one submission per IP per minute by default, which throttles flooders without affecting a real visitor who submits once.
• ML content scoring — a model that flags link spam, repeated phrases, banned TLDs, and known spam corpora. This is the layer that catches AI-written messages a honeypot can't, because it judges the content, not the field.
• Account-wide blocklist — block a sender once from the Spam folder and every form on your account is protected, trained by every "mark as spam" click your team makes.
• Spam folder — caught submissions land in a reviewable folder; recovering a false positive is one click, and it trains the filter to let similar messages through next time.

Crucially, all of this runs with no CAPTCHA and no third-party JavaScript in your bundle. There's no reCAPTCHA widget loading Google scripts and cookies, nothing for a real user to solve, and nothing that bloats your React app or complicates GDPR. It works on the very first submission — there's no model warm-up. On splitforms every layer is included on the free plan; there's no spam-protection upsell. If you're still weighing backends for a React stack, the field is compared in the top 10 React form backends, and the underlying approach is documented on the splitforms security page and the spam protection feature page.

The honest limits of a no-CAPTCHA approach

No layered system is a force field, and it's worth being clear about what still gets through so you set the right expectations:

• Headless-browser bots render your page, apply CSS, and only fill visible fields — so they walk past the honeypot. The time-trap and content scoring still get a shot at them, but the field-level trap is blind here by design.
• Targeted scripts written for your form specifically will inspect it once, note the trap and the timing threshold, and engineer around both. This is why the IP rate limit and blocklist matter — they raise the cost of sustained targeting.
• AI-generated spam that reads like a genuine inquiry is the hard case. No field trick detects it; only content-level analysis does. This is exactly the gap the ML content-scoring layer is built to close, but it's a probability, not a guarantee — which is why caught items are recoverable rather than silently destroyed.
• Human spam farms see what humans see and type at human speed. Nothing field-level or timing-based stops them; content scoring and the account-wide blocklist are your remaining defenses.

The takeaway is the same one that runs through all honest spam writing: it's layers, not a silver bullet. A honeypot is the first filter, not the only one, and "honeypot vs CAPTCHA" is the wrong framing — the right comparison is a layered server-side stack versus making every real visitor prove they're human. The layered stack wins on conversions every time, which is why no-CAPTCHA protection is the default rather than a compromise.

React spam-proofing checklist

Everything above, compressed into steps you can verify in a few minutes:

1. Stop trusting the client. Assume bots will POST to your endpoint directly and skip every onSubmit guard you wrote.
2. Add a hidden, off-screen botcheck input (not type="hidden") with tabIndex=-1, autoComplete="off", and aria-hidden="true". Keep it empty.
3. Capture _start_time on mount with a useRef and send it in your fetch() body (or a hidden field for a Server Action).
4. Filter on the server. In a Server Action, reject non-empty botcheck and sub-2-second submissions early; for everything else, let a hosted backend score the request.
5. Layer the rest server-side — IP rate limit, ML content scoring, blocklist — because the honeypot and time-trap alone leave AI spam and headless bots on the table.
6. Test both paths: submit normally and confirm delivery, then fill the honeypot via dev tools (or POST forged JSON with curl) and confirm it's dropped.

Using splitforms, steps 4 and 5 are already done for you — the backend recognizes the honeypot, enforces the time-trap, and runs the rest of the stack on every submission.

FAQ

Keep going on React forms and spam defense: add a Vite + React contact form, Server Actions vs a form backend, what is a honeypot field, the complete spam protection guide, and the framework quick-start guides.