Static Forms - Secure form backend and form endpoint for contact forms
Back to all posts
How to Create Website Forms: An End-to-End Developer Guide

How to Create Website Forms: An End-to-End Developer Guide

16 min read
Static Forms Team
how to create website formshtml formsjamstack formsserverless formsreact forms
Share:

You're probably here because the frontend part is done, the page looks fine, and the form still isn't really finished. That's the usual trap. A form isn't production-ready when the fields render. It's production-ready when submissions arrive, errors are understandable, spam stays manageable, uploads are safe, and the emails land where they should.

For developers building static and JAMstack sites, that means treating the form as a full pipeline. Markup, validation, transport, storage, notifications, compliance, and debugging all matter.

Building the Foundation with Semantic HTML

A good form starts with plain HTML that browsers and assistive tech can understand without guessing. If you get this part right, everything else gets easier. If you get it wrong, you'll spend time patching avoidable issues with JavaScript later.

Adobe's guidance recommends browser autofill and common field naming patterns like name, email, and phone number, plus HTML5 input types that help devices show the right keyboard and reduce typing friction in the first place, as noted in Adobe's web form design guidance.

A laptop screen displaying HTML code for a web contact form within a code editor environment.

Start with the real form element

The <form> tag still matters. Set action to the endpoint that receives submissions, and set method="post" unless you have a very specific reason not to.

Use real labels. Don't use placeholder text as the label. Placeholders disappear once typing starts, which makes error recovery worse and hurts accessibility.

Here's a clean contact form you can paste into a static page:

HTML
<form
  action="https://api.example.com/contact"
  method="post"
  accept-charset="UTF-8"
>
  <fieldset>
    <legend>Contact us</legend>

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

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

    <div>
      <label for="phone">Phone number</label>
      <input
        id="phone"
        name="phone"
        type="tel"
        autocomplete="tel"
        inputmode="tel"
      />
    </div>

    <div>
      <label for="subject">Subject</label>
      <input
        id="subject"
        name="subject"
        type="text"
        autocomplete="off"
        required
      />
    </div>

    <div>
      <label for="message">How can we help?</label>
      <textarea
        id="message"
        name="message"
        rows="6"
        required
      ></textarea>
    </div>

    <div>
      <input id="consent" name="consent" type="checkbox" required />
      <label for="consent">I agree to be contacted about this request.</label>
    </div>

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

Use the right field types and grouping

A lot of forms still use type="text" for everything. That works, but it's lazy. type="email", type="tel", type="date", and numeric input types reduce friction and improve validation before any custom script runs.

Ramotion's workflow for how to create website forms starts with purpose and required fields first, then semantic HTML and backend handling later, which is the right order to follow in practice. If a field doesn't support the form's purpose, cut it.

Practical rule: every field needs a reason to exist. If you can't explain why the backend needs it, remove it.

A few defaults I use:

  • Use fieldset and legend when fields belong together, such as contact details, billing details, or event preferences.
  • Use autocomplete tokens so browsers can help users finish faster.
  • Use explicit submit buttons with type="submit" instead of clickable divs or JavaScript-only controls.
  • Keep names stable because backend systems, webhooks, and dashboards often depend on exact field names.

If you want a deeper breakdown of field types and where each one fits, this guide on HTML form input types is worth bookmarking.

Sometimes the “form” isn't a business contact form at all. If you're building an event site and want something more memorable than a standard guestbook, this Wedding guest idea is a good example of matching the input experience to the context instead of forcing a generic contact form pattern everywhere.

Adding Client-Side Validation and Better UX

Most broken forms don't fail because the CSS is ugly. They fail because people can't recover when something goes wrong. That's why accessibility and error handling deserve as much attention as layout.

NN/g guidance emphasizes visible labels, clear instructions, and specific error messages, and warns that placeholder text is often overused and errors shouldn't rely on color alone, as described in NN/g's form design guidance.

Use browser validation first

Native validation gets you surprisingly far. It's fast, consistent enough for many use cases, and doesn't require framework code just to reject an empty field.

This is a decent baseline:

HTML
<form id="contact-form" action="https://api.example.com/contact" method="post" novalidate>
  <div>
    <label for="email">Email address</label>
    <input
      id="email"
      name="email"
      type="email"
      required
      minlength="5"
      aria-describedby="email-error"
    />
    <p id="email-error" class="error" aria-live="polite"></p>
  </div>

  <div>
    <label for="message">Message</label>
    <textarea
      id="message"
      name="message"
      required
      minlength="20"
      aria-describedby="message-error"
    ></textarea>
    <p id="message-error" class="error" aria-live="polite"></p>
  </div>

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

The novalidate attribute is optional. I use it when I want custom JavaScript messages instead of browser defaults. If you're fine with native messages, remove novalidate and let the browser handle the first pass.

Add JavaScript only where native rules stop helping

JavaScript validation is useful for cross-field rules, conditional sections, and cleaner message presentation. It's not a replacement for server-side validation.

Here's a minimal pattern:

HTML
<script>
  const form = document.getElementById('contact-form');

  form.addEventListener('submit', (event) => {
    let hasErrors = false;

    const email = form.elements.email;
    const message = form.elements.message;

    const emailError = document.getElementById('email-error');
    const messageError = document.getElementById('message-error');

    emailError.textContent = '';
    messageError.textContent = '';

    if (!email.value.trim()) {
      emailError.textContent = 'Enter your email address.';
      hasErrors = true;
    } else if (!email.validity.valid) {
      emailError.textContent = 'Enter a valid email address.';
      hasErrors = true;
    }

    if (!message.value.trim()) {
      messageError.textContent = 'Enter a message.';
      hasErrors = true;
    } else if (message.value.trim().length < 20) {
      messageError.textContent = 'Your message must be at least 20 characters.';
      hasErrors = true;
    }

    if (hasErrors) {
      event.preventDefault();
    }
  });
</script>

What works:

  • Specific messages instead of “Invalid input”
  • Errors near the field where the problem happened
  • Persistent labels that stay visible during correction

What doesn't:

  • Red border only with no text explanation
  • Placeholder-only prompts
  • Validation on every keystroke for fields that don't need it

A form should help people finish, not punish them for typing.

For more complex cases, especially custom rules and async checks, this walkthrough on JavaScript form validation shows practical client-side patterns.

Choosing a Backend to Process Submissions

On a static site, the form isn't doing anything until something receives the POST request. That's the line where a lot of otherwise solid frontend projects get stuck.

The practical workflow is simple: define the purpose, list only the required fields, choose the build method, write semantic HTML, then add server-side handling for delivery or persistence, as outlined in Ramotion's web form workflow.

A diagram comparing three methods for backend form submission handling: custom servers, serverless functions, and managed services.

Option one, build your own handler

If you need full control, write a serverless function or API route. That's usually the cleanest fit for JAMstack apps that already have deployment infrastructure in place.

A simple Vercel or Netlify function can:

  • Accept POST data
  • Validate and sanitize fields
  • Send email through a provider
  • Store submissions in a database
  • Trigger a webhook or queue

This approach gives you maximum flexibility, but you own everything. Spam filtering, retries, logging, storage, file handling, and email deliverability all become your problem.

Option two, use a managed form backend

Managed form services exist for a reason. They remove the need to maintain submission plumbing for straightforward contact, signup, support, and lead forms.

Here's the honest trade-off:

Approach Good fit Main cost
Serverless function Custom logic, existing backend knowledge, unusual workflows Ongoing maintenance
Traditional app backend Complex products, authenticated users, custom databases More infrastructure
Managed form backend Static sites, quick delivery, common form workflows Less custom control

A managed service usually works by giving you a submission endpoint and identifying the form with a token or API key. You post form data there, then configure delivery, storage, redirects, and integrations in the service dashboard.

One example is email form submission handling. Static Forms fits this model by letting you point a form at https://api.staticforms.dev/submit, identify the form with an API key, and receive submissions by email or through connected destinations. That's useful when you want working forms on a static site without building a dedicated handler.

Decide based on failure modes, not just setup time

People often compare these options based on how fast they can ship. That matters, but the more useful question is what happens when the form breaks.

If you own the handler, ask:

  • Where will failed submissions be logged
  • How will retries work
  • Who gets alerted when email delivery fails
  • What's the plan for spam bursts
  • How will uploads be stored and cleaned up

If you use a service, ask:

  • Can it handle your spam stack
  • Does it support redirects, webhooks, and file uploads
  • Can you export or delete data when needed
  • Does it support custom sending domains if you care about inbox placement

The backend choice isn't about elegance. It's about who owns the boring failure cases after launch.

Implementing Forms in React Nextjs and Vue

Frameworks change the wiring, not the fundamentals. You still have the same job: collect values, validate them, submit them asynchronously, and reflect success or failure in the UI.

Developers often overbuild. A contact form doesn't need a form state library by default. Plain component state and fetch are enough for many sites.

Screenshot from https://www.staticforms.dev

React example

JSX
import { useState } from 'react';

export default function ContactForm() {
  const [form, setForm] = useState({
    name: '',
    email: '',
    message: '',
  });
  const [status, setStatus] = useState('idle');

  async function handleSubmit(event) {
    event.preventDefault();
    setStatus('submitting');

    try {
      const res = await fetch('https://api.example.com/contact', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(form),
      });

      if (!res.ok) throw new Error('Request failed');

      setStatus('success');
      setForm({ name: '', email: '', message: '' });
    } catch (error) {
      setStatus('error');
    }
  }

  function handleChange(event) {
    const { name, value } = event.target;
    setForm((prev) => ({ ...prev, [name]: value }));
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="name">Name</label>
      <input id="name" name="name" value={form.name} onChange={handleChange} required />

      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" value={form.email} onChange={handleChange} required />

      <label htmlFor="message">Message</label>
      <textarea id="message" name="message" value={form.message} onChange={handleChange} required />

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

      {status === 'success' && <p>Thanks, your message was sent.</p>}
      {status === 'error' && <p>Something went wrong. Try again.</p>}
    </form>
  );
}

Next.js example

If you want to keep secrets or vendor logic off the client, post to an API route first.

app/api/contact/route.js

JavaScript
export async function POST(request) {
  const body = await request.json();

  const upstream = await fetch('https://api.example.com/contact', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });

  if (!upstream.ok) {
    return new Response(JSON.stringify({ ok: false }), { status: 500 });
  }

  return new Response(JSON.stringify({ ok: true }), { status: 200 });
}

Client component:

JSX
'use client';

import { useState } from 'react';

export default function ContactForm() {
  const [email, setEmail] = useState('');
  const [message, setMessage] = useState('');

  async function submit(event) {
    event.preventDefault();

    await fetch('/api/contact', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ email, message }),
    });
  }

  return (
    <form onSubmit={submit}>
      <input
        type="email"
        name="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        required
      />
      <textarea
        name="message"
        value={message}
        onChange={(e) => setMessage(e.target.value)}
        required
      />
      <button type="submit">Send</button>
    </form>
  );
}

Vue example

Vue
<template>
  <form @submit.prevent="submitForm">
    <label for="name">Name</label>
    <input id="name" v-model="form.name" name="name" required />

    <label for="email">Email</label>
    <input id="email" v-model="form.email" name="email" type="email" required />

    <label for="message">Message</label>
    <textarea id="message" v-model="form.message" name="message" required></textarea>

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

    <p v-if="status === 'success'">Message sent.</p>
    <p v-if="status === 'error'">Submission failed.</p>
  </form>
</template>

<script setup>
import { reactive, ref } from 'vue';

const form = reactive({
  name: '',
  email: '',
  message: ''
});

const status = ref('idle');

async function submitForm() {
  status.value = 'submitting';

  try {
    const res = await fetch('https://api.example.com/contact', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(form)
    });

    if (!res.ok) throw new Error();

    status.value = 'success';
    form.name = '';
    form.email = '';
    form.message = '';
  } catch {
    status.value = 'error';
  }
}
</script>

If the form takes payments, registration fees, or deposits, the submission pattern changes because you usually need tokenized payment flows and gateway-specific callbacks. For Australia-based projects, Website Builder Australia's advice on payments is a useful starting point before you mix payment logic into a normal contact form.

Handling Spam File Uploads and Webhooks

A form that works in local dev can still be a mess in production. Spam arrives. Uploads fail. Downstream systems timeout. Many simple tutorials often conclude at this point.

An infographic titled Production-Ready Forms explaining advanced topics like spam protection, secure file uploads, and webhooks.

Spam protection that doesn't annoy everyone

Spam controls are layered. One technique rarely covers everything.

A sensible stack looks like this:

  • Honeypot field for low-friction bot filtering. Add a field humans won't fill, then reject submissions when it contains data.
  • Server-side validation for required fields, accepted formats, and suspicious payloads. Never trust the browser.
  • Challenge-based protection when needed. reCAPTCHA v2, reCAPTCHA v3, Cloudflare Turnstile, and Altcha all solve slightly different problems.

Simple honeypot example:

HTML
<div style="position:absolute;left:-5000px;" aria-hidden="true">
  <label for="company_website">Leave this field empty</label>
  <input type="text" id="company_website" name="company_website" tabindex="-1" autocomplete="off" />
</div>

On the backend, reject any submission where company_website isn't empty.

The trade-off is straightforward. Honeypots are invisible to people, but smarter bots can bypass them. CAPTCHA-style checks catch more abuse, but they can add friction and raise privacy concerns depending on the provider.

File uploads need different plumbing

As soon as a form accepts files, the transport changes. You need multipart/form-data, server-side size validation, MIME checks, and sane storage.

A minimal upload form:

HTML
<form action="https://api.example.com/apply" method="post" enctype="multipart/form-data">
  <label for="resume">Upload your resume</label>
  <input id="resume" name="resume" type="file" accept=".pdf,.doc,.docx" required />

  <button type="submit">Submit application</button>
</form>

For production, I'd treat 5MB as a practical upper bound when the receiving system supports it, because larger uploads create slower requests and more failure points. More importantly, validate on the server:

  • Check file size
  • Check allowed extensions and MIME type
  • Rename files before storage
  • Scan for malware if the workflow justifies it
  • Store outside public web root unless public access is intentional

Don't trust the filename, the extension, or the browser-reported content type on its own.

Webhooks turn forms into workflows

A webhook is just an HTTP callback after a successful submission. That simple piece changes a form from “send an email” into “kick off a process.”

Common uses:

Trigger Destination Result
Contact form Slack Team sees new lead immediately
Lead form Google Sheets Submission appended for review
Support form Notion or ticket system Task created automatically

If you're building your own backend, fire the webhook after validation and persistence succeed. If you're using a managed backend, look for retries and failure logs. Silent webhook failures are one of the most annoying form bugs because the user thinks the submission worked.

Ensuring GDPR Compliance and Email Deliverability

Developers often treat privacy and inbox placement as someone else's department. That's a mistake. If your form collects personal data and your notifications never arrive, the form is broken even if the POST request succeeded.

GDPR starts with what you collect

The cleanest GDPR move is still product restraint. Keep forms short, group related fields, use a single-column layout, and put the most important fields first, as recommended in B13's web form optimization guidance. That helps usability, but it also reduces unnecessary data collection.

From an implementation standpoint:

  • Add explicit consent checkboxes when consent is the lawful basis you're relying on
  • Don't pre-check consent
  • Separate consent from terms acceptance if they serve different purposes
  • Store consent state with the submission
  • Make deletion and export possible if your backend or vendor supports it

This is technical guidance, not legal advice. But the engineering part is clear. If a user asks what data you have or asks for deletion, your form pipeline should make that possible without manual archaeology.

Deliverability is part of the form system

The usual complaint is “the form works, but nothing hits the inbox.” Often the form did submit. The email side failed later.

If you send notifications or auto-responses from your own domain, set up SPF, DKIM, and DMARC for that sending domain. At a high level:

  • SPF tells receiving servers which senders are allowed for your domain
  • DKIM signs outgoing mail so receivers can verify it wasn't altered
  • DMARC tells receivers how to handle failures and gives you reporting structure

Without those records aligned, notification mail is more likely to be filtered, spoofed, or distrusted. This matters even more if you send auto-responses to the person who filled out the form, because those messages feel transactional and people expect them quickly.

A good pattern is to separate sender identity from reply handling. Use an authenticated sending domain for the notification itself, and set Reply-To to the submitter's address when that fits the workflow. That keeps deliverability cleaner than trying to impersonate the submitter as the sender.

Troubleshooting Common Form Issues

When a form fails, the bug is usually in one of four places: the browser request, the endpoint, the response handling, or the email layer. Debug it in that order.

Online forms are a serious conversion surface, not a minor UI detail. One industry roundup says 74% of businesses use online forms for lead generation, and cites an average conversion rate around 21.5%, which is why form work belongs on the production checklist, not the afterthought list, according to this web form statistics roundup.

Submissions aren't arriving in my inbox

Check whether the network request succeeded first. If the request failed, this isn't an email problem.

If the request succeeded, inspect the backend logs or provider dashboard. Common causes include invalid sender configuration, spam filtering, missing required fields, or webhook errors blocking later steps in your pipeline.

The form redirects to a blank JSON page

That usually means the endpoint responded with JSON and your plain HTML form redirected directly to it. Nothing is technically broken, but the UX is wrong.

You have two clean fixes:

  • Handle submission with JavaScript fetch and render a success state in the page
  • Configure a success redirect so the browser lands on a thank-you page

I'm getting a CORS error

CORS errors usually happen when frontend JavaScript posts to an endpoint that doesn't allow your origin. Plain HTML form posts often avoid this because the browser handles them as navigation, not as cross-origin XHR or fetch.

If you need AJAX submission, make sure the receiving endpoint is configured to allow your site's origin and expected headers. Also check that you're not sending unnecessary custom headers that trigger a stricter preflight request.

My custom success page isn't showing

Usually one of three things happened:

  • The redirect URL wasn't configured
  • JavaScript intercepted the submit and never followed the redirect
  • The form failed validation before it ever left the page

Open devtools, submit again, and confirm whether the request left the browser. If it didn't, look at client-side validation and event handlers first.

File uploads fail even though the form submits

That points to an encoding or backend limit problem. Confirm that the form uses enctype="multipart/form-data" and that the backend accepts multipart requests.

Then verify size rules, allowed file types, and storage behavior. Upload bugs are often partial failures where the text fields arrive but the file is dropped.

Spam still gets through

That's normal if you rely on a single filter. Add layers. Honeypot plus server-side checks is a reasonable baseline. If abuse continues, add Turnstile, reCAPTCHA v2 or v3, or Altcha based on your privacy and UX requirements.

Required fields look correct, but the backend says they're missing

Check name attributes. The input can have the right id, label, and visible text and still submit nothing useful if name is missing or mismatched.

This happens a lot in component refactors where UI code survives but the payload shape changes underneath.

If you want a form backend that fits static sites without writing submission handlers from scratch, Static Forms is one practical option. You point the form at its submission endpoint, identify the form with an API key, and handle delivery, redirects, uploads, spam checks, webhooks, and dashboard storage from there. For JAMstack projects, that's often enough to get from a <form> tag to a reliable live pipeline without maintaining backend infrastructure.

Related Articles

AI Form Builder: Choose the Best for 2026

Discover AI form builders for 2026. Learn how they work with React & Next.js and choose the best based on privacy, integrations, and cost.

·15 min read

Build a Secure Form Builder Html: Expert Guide 2026

Master form builder html with our 2026 guide. Get copy-paste code for secure forms, backend integration, file uploads, and spam protection.

·13 min read

10 Best Form Builder React Libraries for 2026

Explore the top 10 form builder react libraries for 2026. Compare React Hook Form, schema-driven tools, and visual builders for performance and features.

·21 min read