Add a Contact Form to Remix / React Router 7 (2026)

The two paths: route action() vs. direct-to-endpoint

React Router 7's framework mode gives every route an optional action() — a function that runs on the server (or whatever runtime your adapter targets) when a Form submits with method="post". It's the framework's own data-mutation primitive, the same role Next.js Server Actions play — see server actions vs. form backend for the Next.js version of this exact decision. An action() is routing plumbing, not a backend: it still gives you no storage, no email delivery, and no spam filtering unless you wire those yourself or forward to something that already has them.

You don't have to use it at all. A form is still just a form — pointing its action attribute at a URL works with zero React Router involvement, the same plain-HTML technique covered in Add a Contact Form to React, since React Router 7 is still React underneath. Direct-to-endpoint wins when the form's only job is reaching an inbox and a dashboard: no server runtime required, so it works in SPA mode and static builds too. A route action() wins once you have logic that has to run inside your own app — validating against your own rules, writing a database row, or keeping the visitor on the page instead of navigating away.

Path A: a plain HTML form, no action() at all

Point the form's action attribute straight at a hosted endpoint and skip React Router's data APIs entirely. This is a normal route component — no action export, no Form import:

// app/routes/contact.tsx
export default function Contact() {
  return (
    <form action="https://splitforms.com/api/submit" method="POST">
      <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
      <input type="hidden" name="redirect" value="https://yoursite.com/thanks" />

      <input name="name" type="text" required />
      <input name="email" type="email" required />
      <textarea name="message" required />

      {/* Honeypot — real visitors never see or check this */}
      <input type="checkbox" name="botcheck" style={{ display: "none" }} tabIndex={-1} />

      <button type="submit">Send</button>
    </form>
  );
}

The browser POSTs directly to splitforms.com and follows the redirect URL on success — React Router never sees the request. That means this works identically whether react-router.config.ts sets ssr: true (full framework mode) or ssr: false (SPA mode, prerendered to static HTML): there's no server route to run either way, the same reason this pattern is the default recommendation in jamstack form backend. That's the whole job of a Remix form backend: reachable inbox, searchable dashboard, spam filtering — storage, email delivery, and the honeypot/time-trap/rate-limiting stack all run on splitforms' side, free on every plan, including the 500-submission/month Free tier.

Path B: Form + an action() that forwards with fetch

When you want to run your own code before the submission leaves your server — validate a field your own way, log the attempt, or simply avoid a page navigation — write an action() that reads the posted FormData and forwards it:

// app/routes/contact.tsx
import type { ActionFunctionArgs } from "react-router";
import { Form, useActionData, useNavigation } from "react-router";

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();

  const response = await fetch("https://splitforms.com/api/submit", {
    method: "POST",
    body: formData,
    headers: { Accept: "application/json" },
  });
  const result = await response.json();

  if (!response.ok) {
    return { ok: false as const, error: result.message ?? "Something went wrong. Try again." };
  }
  return { ok: true as const };
}

export default function Contact() {
  const actionData = useActionData<typeof action>();
  const navigation = useNavigation();
  const submitting = navigation.state === "submitting";

  return (
    <Form method="post">
      <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
      <input name="name" type="text" required />
      <input name="email" type="email" required />
      <textarea name="message" required />

      <button type="submit" disabled={submitting}>
        {submitting ? "Sending…" : "Send"}
      </button>

      {actionData?.ok === true && <p>Thanks — we got your message.</p>}
      {actionData?.ok === false && <p role="alert">{actionData.error}</p>}
    </Form>
  );
}

That's the whole pattern: await request.formData(), forward it with fetch, return a small JSON-serializable result. React Router's Form component intercepts the submit, posts to the route's own action(), and re-renders with actionDatainstead of doing a full navigation — that's what keeps the visitor on the page.

React Router 7's framework-mode API has been stable since its November 2024 release. If you're on an older Remix v2 app that hasn't adopted the react-router package yet, check your installed version before copying the imports above verbatim.

Progressive enhancement: both paths work without JavaScript

Every code sample above degrades gracefully. Path A is a plain form element — browsers have POSTed forms since before JavaScript existed, so it works with scripting fully disabled. Path B's Form component renders a real HTML form with method="post" in the markup it sends to the browser; without JavaScript, clicking submit triggers a normal full-page POST to the route, the action() still runs, and the response renders the page server-side. JavaScript only adds the on-page re-render via useActionData and the pending state via useNavigation — neither is required for the form to function.

That's a deliberate design choice inherited from Remix: build on standard browser behavior first, then layer client-side enhancement on top, rather than requiring JavaScript to make a form work at all.

Validation and error UX

To validate before forwarding, check the field inside the action() and return early — no extra library required for a simple contact form:

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const email = String(formData.get("email") ?? "");

  if (!email.includes("@")) {
    return { ok: false as const, error: "Enter a valid email address." };
  }

  const response = await fetch("https://splitforms.com/api/submit", {
    method: "POST",
    body: formData,
  });
  return { ok: response.ok };
}

useActionData surfaces whatever the action returned — success or your custom error — without a redirect. useNavigation().state flips to "submitting" the instant the form posts, so the disabled-button pending state in the Path B component needs no extra state variable of its own. Both hooks come from the same react-router package as Form.

Which to pick

Honest version: most contact forms don't need an action(). If the form's job is "deliver this to my inbox and let me search past submissions," Path A does that in fewer lines, works in SPA mode, and never touches your server. Write an action()when you have server logic that has to live inside your own app — writing to a database you own, calling another internal API, or enforcing validation rules a client-side check can't be trusted to enforce alone.

Either way, the delivery problem is the same one splitforms solves regardless of which path calls it: the honeypot, time-trap, and rate-limiting spam stack runs server-side by default on every form, and email notifications are free on every plan, including Free (500 submissions/month, unlimited forms, forever). Nothing about choosing Path A over Path B — or the reverse — changes what happens after splitforms receives the POST.

Next steps

• Building with plain React and skipping React Router's data APIs entirely? The same two paths apply — see contact form for React.
• Want the full list of what runs server-side on every submission by default? See the spam-protection feature page — honeypot, time-trap, and rate limiting, included free on every plan.

FAQ