How to Handle Form Submissions on a Static Website

A static site is, by definition, a folder of HTML, CSS, and JavaScript files served exactly as written — there's no server executing code per request, which means there's nothing on your own infrastructure to catch a form's POST request and do something with it. That's not actually a problem, but it does mean picking the right one of three fundamentally different approaches.

Quick Answer

Static sites handle form submissions one of three ways: a third-party form-endpoint service that receives the POST directly, a serverless function you deploy alongside the static files (Netlify Functions, Vercel Functions, Cloudflare Workers), or — on a handful of platforms — built-in form detection that requires no code at all. All three need the same underlying HTML: method="POST", an action pointed at the right place, and a name attribute on every field. Form Studio generates that markup regardless of which approach you pick.

Use the Free Tool

Form Studio's Delivery tab supports pointing your generated form at any custom endpoint URL — a form-endpoint provider, your own serverless function, or a platform's native form-handling target — and produces the matching HTML or fetch-based submission code for whichever export format you're using.

Option 1: A Form-Endpoint Provider

The simplest option for most static sites: sign up with a provider, get an endpoint URL or verified action target, and point your form at it directly. No code of yours runs anywhere.

<form action="https://your-provider.com/f/your-form-id" method="POST"> <input type="text" name="name" required> <input type="email" name="email" required> <button type="submit">Send</button> </form>

This works identically regardless of host — GitHub Pages, a plain S3 bucket behind a CDN, Netlify, Vercel, or a folder on any shared host. The provider does the receiving, spam filtering, and email delivery. For the full setup — required markup, honeypot spam protection, and picking a provider — see How to Send an HTML Form to Email Without PHP.

Option 2: A Serverless Function

If your host supports them (Netlify Functions, Vercel Functions, Cloudflare Workers/Pages Functions), you can deploy a small function alongside your static files that receives the POST and calls an email-sending API directly — no third-party form provider needed:

// A Cloudflare Pages Function at /functions/contact.js export async function onRequestPost({ request, env }) { const data = await request.formData(); const payload = Object.fromEntries(data.entries()); await fetch('https://api.resend.com/emails', { method: 'POST', headers: { Authorization: `Bearer ${env.RESEND_API_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ from: 'forms@yourdomain.com', to: 'you@yourdomain.com', subject: `New submission from ${payload.name}`, text: JSON.stringify(payload, null, 2), }), }); return Response.redirect(new URL('/thanks', request.url), 303); }

The exact deployment shape differs by platform — Netlify uses a netlify/functions/ folder, Vercel uses api/ route files, Cloudflare uses functions/ — but the underlying pattern is the same: your static HTML's action points at a path your host maps to a small server-side function, and that function (and only that function) actually executes code, with any API keys staying entirely server-side.

Option 3: Platform-Native Form Handling

A small number of static hosts detect and process forms with zero backend code of your own, by inspecting your HTML at build/deploy time. Netlify is the best-known example — adding a data-netlify="true" attribute (plus a hidden form-name field) to a form is enough for Netlify to capture submissions into its own dashboard and forward email notifications, without you writing a function or connecting a third-party provider:

<form name="contact" method="POST" data-netlify="true"> <input type="hidden" name="form-name" value="contact"> <input type="text" name="name" required> <input type="email" name="email" required> <button type="submit">Send</button> </form>

This is genuinely the least code you'll ever write for this problem — but it's specific to Netlify and doesn't transfer if you ever migrate hosts. Weigh that lock-in against the convenience before committing a large project to it.

Which One Should You Use?

Step-by-Step Workflow

Step 1: Build the form fields in Form Studio, making sure every field has a name attribute regardless of which option you choose.

Step 2: Pick one of the three options based on your host and how much control you need over the destination.

Step 3: For Option 1, set the endpoint URL in the Delivery tab and copy the generated HTML. For Option 2, deploy your function first, then point the Delivery tab's custom endpoint at its path. For Option 3, add the platform-specific attributes manually — Form Studio's generic HTML export is the right starting point, but native platform detection needs its own attributes layered on afterward.

Step 4: Deploy and submit a real test — some form-endpoint providers and platform-native handlers require a one-time verification step before they'll deliver.

Step 5: Confirm the submission actually arrives, and check spam/junk on the first one.

Common Mistakes

Assuming a <form> tag alone does something on a static host. With no backend and no third-party endpoint configured, a static form's default behavior is to reload the current page with the field data appended to the URL — nothing gets processed or stored anywhere.

Mixing platform-native detection syntax with a third-party endpoint's action. Netlify's form detection, for example, requires the form to be present in your built HTML with its specific attributes — pointing action somewhere else at the same time creates ambiguity about where the submission actually goes.

Putting an email-provider API key in client-side JavaScript when using Option 2. The function itself runs server-side; the API key belongs in that function's environment variables, never bundled into anything shipped to the browser.

Not testing on the actual deployed static build. Local development servers sometimes behave differently from a genuinely static, pre-built deployment — always verify the real thing after deploying.

Best Practices

• Add a honeypot field regardless of which option you choose — spam bots don't care whether your backend is serverless or third-party.

• Keep the HTML markup identical across options where possible — only the action/endpoint target should change, which makes switching providers later a small edit rather than a rebuild.

• Avoid platform-native form detection for anything you might migrate off that platform — it's convenient but creates lock-in that a portable form-endpoint provider or your own function avoids.

• Log or store a copy of submissions somewhere you control, even when using a third-party provider, if the data matters — provider retention policies vary and some purge data after a fixed window.

Related Tools

• Form Studio — Build a static-site-ready form for any of these three approaches

• JSON Formatter — Inspect the JSON payload a serverless function receives

• HTML Text Input Generator — Generate a single named, labeled input

The Developer Tools category has the rest of the form and API utilities. See also How to Send an HTML Form to Email Without PHP for a deeper walkthrough of Option 1.

FAQ

Can I use PHP if my static host happens to support it?

If your host runs PHP (some shared hosts serving otherwise-static sites do), a mail.php script is still a valid option — this guide focuses on the more common case of genuinely static hosting with no server-side runtime at all.

Does a static site need a database to store submissions?

Not necessarily — a form-endpoint provider or an email-only serverless function needs no database at all if you only need email notification. A database becomes relevant if you want a searchable submission history beyond what's in your inbox.

Is client-side-only form handling (no endpoint at all) ever acceptable?

Only if you don't actually need the data to go anywhere off the visitor's own device — for example, a form that generates a downloadable file or a calculation result entirely in the browser. Anything meant to reach you requires one of the three options above.

Do serverless functions cost money?

Most platforms offer a generous free tier for low-traffic functions (Netlify, Vercel, and Cloudflare all have free allowances well beyond what a typical contact form generates), so cost usually isn't a practical concern until traffic is substantial.

Can I switch between these options later without rebuilding the form?

Mostly yes — since all three options work with fundamentally the same HTML shape (method="POST", named fields), switching usually just means changing the action/endpoint URL, not rebuilding the form fields themselves.

Build a Static-Site-Ready Form Now

Form Studio generates the correctly-attributed HTML for any of these three approaches — free, and it runs entirely in your browser.