The Complete Guide to HTML Form Handling Without a Backend

A client site we inherited in 2023 had a contact page with a mailto: link dressed up as a form. It looked fine. It converted almost nothing, because roughly a third of the desktop visitors clicking it had no mail client configured, got a browser dialog asking them to choose an application, and left. The fix took twenty minutes and the enquiry volume tripled in the first month.

That’s the thing about building an HTML form without a backend. The hard part was never the HTML. It’s everything around it: spam, validation states, where the data goes when it arrives, and what happens when JavaScript fails to load on a train.

This guide assumes you already know what a <form> tag is. We’ll cover the request lifecycle, progressive enhancement that genuinely degrades, spam defence that doesn’t punish real users, and the specific cases where you should stop fighting it and stand up a server.

Why mailto: and the JS email hacks keep failing

Three patterns show up again and again in audits. All three are broken in ways that don’t appear in your own testing.

mailto: forms depend on the visitor having a configured mail handler. On a MacBook with Mail.app set up, it works beautifully. On a Windows machine where the user lives entirely inside Gmail in Chrome, it opens a dialog nobody understands. You never see the failure because the failure is a bounce, and a bounce looks like disinterest in your analytics.

Then there’s the SMTP-from-the-browser approach: EmailJS-style services where credentials sit in your client bundle. They work, and there are legitimate uses, but understand what you’ve shipped. Anyone can open DevTools, copy your public key and template ID, and send mail through your quota. We’ve seen an agency burn through a 200 email monthly tier in about six hours because a scraper found the key and hammered it.

Finally, the Google Forms iframe. Functional, free, and it makes your carefully designed site look like a 2011 intranet. It also drops a cross-origin frame into your page that you cannot style, cannot validate, and cannot instrument properly.

What a form endpoint actually does

Strip it back and a form endpoint is a URL that accepts POST requests, validates the payload, and forwards it somewhere useful. The lifecycle:

1. The browser serialises your form fields using the names in the name attributes. Fields without a name are not sent. This is the single most common bug in hand-rolled forms.
2. It POSTs to the endpoint as application/x-www-form-urlencoded, or multipart/form-data if there’s a file input.
3. The endpoint checks the Origin header against a domain allowlist you configured, runs spam heuristics, and stores or forwards the payload.
4. It responds. For a native submit that means a 302 redirect to your thank-you page. For a fetch submit it means JSON with a success flag and a field-level error map.

Because the browser handles steps 1 and 2 natively, the minimum viable contact form is genuinely six lines of HTML. Services like WebForms exist to be that endpoint, routing to email, Slack, Telegram, Zapier or your own webhook without you running anything. Whether you use a hosted endpoint or a 30 line serverless function, the contract is identical.

Build the no-JS path first

Write the form so that it works if every script on the page 404s. Then enhance. Here’s the base:

<form id="contact" action="https://webforms.to/submit/YOUR_ID" method="POST">
  <input type="hidden" name="_redirect" value="https://example.com/thanks">
  <input type="hidden" name="_subject" value="New enquiry from example.com">

  <label for="name">Name</label>
  <input id="name" name="name" type="text" autocomplete="name" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email"
         inputmode="email" required>

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="6" required minlength="20"></textarea>

  <!-- Honeypot: real users never see or fill this -->
  <div class="hp" aria-hidden="true">
    <label for="company_url">Leave this empty</label>
    <input id="companyurl" name="companyurl" type="text" tabindex="-1" autocomplete="off">
  </div>

  <button type="submit">Send message</button>
</form>

Note autocomplete on both real fields. Browsers fill these in one tap on mobile and it measurably reduces abandonment on longer forms. Note also that the honeypot is hidden with CSS, not type="hidden", because bots skip hidden inputs and happily fill visible-in-the-DOM text fields:

.hp {
  position: absolute;
  left: -9999px;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
/ Do NOT use display:none. Some bots specifically ignore display:none fields. /

The fetch upgrade

Now add JavaScript that intercepts the submit, posts the same FormData, and renders an inline result. Because it’s built on top of a working form, a script error means the user gets the redirect flow instead of nothing.

const form = document.getElementById('contact');
const status = document.getElementById('form-status');
const btn = form.querySelector('button[type="submit"]');
const openedAt = Date.now(); // used for the time trap

form.addEventListener('submit', async (e) => {
  e.preventDefault();
  if (!form.reportValidity()) return; // native messages, free a11y

  // Humans do not fill a real form in under 3 seconds.
  if (Date.now() - openedAt < 3000) {
    status.textContent = 'Please take a moment to review your message.';
    return;
  }

  btn.disabled = true;
  btn.textContent = 'Sending...';
  status.textContent = '';

  try {
    const res = await fetch(form.action, {
      method: 'POST',
      body: new FormData(form),
      headers: { Accept: 'application/json' } // ask for JSON, not a redirect
    });

    if (res.ok) {
      form.reset();
      status.textContent = 'Thanks. We reply within one business day.';
      status.className = 'success';
    } else {
      const data = await res.json().catch(() => ({}));
      status.textContent = data.message || 'Something went wrong. Email us at [email protected]';
      status.className = 'error';
    }
  } catch (err) {
    // Network failure: give them a route that does not depend on us
    status.textContent = 'Connection failed. Email [email protected] instead.';
    status.className = 'error';
  } finally {
    btn.disabled = false;
    btn.textContent = 'Send message';
  }
});

Two details people skip. The finally block re-enables the button, because a disabled button after a failed request is a dead end. And the catch branch gives a fallback address, since a user whose corporate proxy blocks your endpoint domain has no other way through.

Spam defence, in the order you should apply it

Start cheap. Escalate only on evidence.

Honeypot. Free, invisible, catches the dumb bulk of it. On the sites we run it kills somewhere around 80 to 90 percent of automated submissions on its own.

Time trap. The 3 second floor above. Costs nothing and catches scripted POSTs that fill and fire instantly. Keep the threshold low; some genuine users paste a prepared message and submit fast.

Origin allowlist at the endpoint. Any decent endpoint service lets you restrict which domains may POST. Configure it. Without it, someone can point their own spam form at your endpoint and use your inbox as a dumping ground. This is not a hypothetical; it’s the most common abuse we see.

Rate limiting. Per IP, per endpoint. Five submissions in ten minutes is generous for a contact form.

CAPTCHA, last. Cloudflare Turnstile is the least hostile option and is invisible for most visitors. But it adds an third-party script, a privacy consideration, and a failure mode where the widget doesn’t load and nobody can submit anything. Add it when your logs prove the earlier layers are being beaten, not before.

Skip the maths puzzles and the “select all traffic lights” walls entirely. They cost you real conversions to stop spam that a hidden text field would have caught.

Validation and error states that screen readers survive

The Constraint Validation API gives you most of what you need without a library. required, type="email", minlength, pattern and :invalid cover the common cases. The trap is styling: :invalid matches an empty required field the instant the page loads, so everything is red before the user has typed a character. Use :user-invalid, which only matches after interaction and has been supported across Chrome, Firefox and Safari since 2023.

input:user-invalid,
textarea:user-invalid {
  border-color: #d33;
}
input:user-invalid + .field-error { display: block; }

For custom error messages, announce them politely and wire them to the field:

<input id="email" name="email" type="email" required
       aria-describedby="email-error" aria-invalid="false">
<p id="email-error" class="field-error" role="alert"></p>

<!-- Global status region, updated on submit -->
<p id="form-status" role="status" aria-live="polite"></p>

Set aria-invalid="true" when you mark a field as failed and move focus to the first invalid input. A sighted user sees red borders. A screen reader user gets nothing at all unless you do this.

One more time, because people keep getting it wrong: client-side validation is not security. Every rule that matters must be re-checked server-side at the endpoint. The browser is a suggestion box.

Where the data goes, and what not to collect

Email is a terrible system of record. It’s fine as a notification, but if enquiries only exist in one inbox, you lose them the day that person leaves. Route every submission to at least two destinations: a notification channel (email or Slack) and a durable store (a sheet, a CRM, a webhook into your own database). We wrote up the full pattern in lead capture architecture for agencies. The short version: the endpoint should be a fan-out point, not a pipe.

On data itself, a few rules we hold to on client work:

• Don’t collect fields you won’t use. Every extra field costs conversions and adds a compliance obligation. If nobody reads the “company size” dropdown, delete it.
• Never put payment details, passwords or health information through an third-party form endpoint. If you’re asking, you need a backend with a defined processing agreement.
• Check data residency if you serve EU users. Ask the provider where submissions are stored and for how long, and get it in writing. “It’s just a contact form” is not a GDPR defence.
• Consent checkboxes must be unticked by default and the text must say what you’ll actually do. A marketing opt-in bundled into “I agree to the terms” is not valid consent.

File uploads deserve a caution. Most hosted endpoints cap attachments somewhere around 5 to 25 MB and will reject a 40 MB PSD without a helpful message. If your form takes portfolios or design files, upload direct to S3 or Cloudflare R2 with a presigned URL and post the resulting link, rather than pushing binaries through a form endpoint.

When a static site form is the wrong call

Three situations where you should stop and build a server.

You need to read state before responding. Booking systems are the classic example. Showing available slots requires querying real availability, and you cannot do that from a static page without an API in front of a datastore. There’s more on the timezone and slot-collision mess in our piece on booking and appointment forms.

The submission triggers something with money or authorisation attached. Payments, account creation, anything that grants access. Secrets belong on a server.

Multi-step flows that must survive a refresh. You can fake this with sessionStorage and it works until someone switches devices mid-way. If completion rate matters, persist server-side.

Everything else, contact forms, newsletter signups, quote requests, feedback widgets, RSVPs, support intake, is genuinely well served by a form endpoint. Most sites never outgrow it. If you’re wiring up a signup specifically, the conversion mechanics matter more than the plumbing, and we covered those in newsletter signup forms that convert.

Test it like you mean it

Before launch, run through this. It takes ten minutes and catches nearly every form bug we’ve ever been called in to fix.

1. Disable JavaScript entirely and submit. You should land on the thank-you page.
2. Submit with an empty required field and confirm the error is announced, not just coloured.
3. Submit twice fast. Confirm you don’t get two identical emails (disable the button on submit).
4. Throttle to Slow 3G in DevTools and submit. Watch for a stuck “Sending…” state.
5. POST to the endpoint from curl with a fake Origin header. It should be rejected.
6. Check where the notification email lands. If it’s in spam, add SPF and DKIM for the sending domain or use a provider that sends from its own verified domain with your address in reply-to.

Number six is the one that bites. A form that works perfectly and delivers to the junk folder is indistinguishable from a form that’s broken.