# Static Forms blog (full content)

Every published post on https://www.staticforms.dev/blog as Markdown, newest first. The documentation in full is at https://www.staticforms.dev/llms-full.txt.

## Turnstile Test Keys, Localhost and Token Errors, Fixed

Source: https://www.staticforms.dev/blog/turnstile-test-keys-token-errors  
Date: 2026-10-27  
Author: Static Forms Team

Turnstile test keys let you run a Cloudflare Turnstile form on `localhost`, in CI, or on a preview URL without registering a domain or solving a real challenge. They also let you force the failure cases on purpose, which is the only reliable way to see what your form does when a token is missing, expired or rejected.

Below you'll find Cloudflare's test site keys and secret keys, which pairs work together, two ways to test on localhost, and a map from the error text you see (from the widget, from Cloudflare's siteverify API, from Static Forms, or from your own backend) to a cause and a fix.

The Static Forms examples assume a form with Turnstile turned on in its Security tab, which is available on Starter and up. If you haven't added Turnstile to a form yet, start with the [Turnstile setup guide](/docs/forms/security/turnstile) and the [Cloudflare Turnstile best practices](/blog/cloudflare-turnstile-best-practices) post. This page assumes the widget is already on the page.

## Cloudflare Turnstile test keys

Cloudflare publishes dummy keys for testing. Copied from Cloudflare's [Turnstile testing docs](https://developers.cloudflare.com/turnstile/troubleshooting/testing/) on October 27, 2026:

| Key type | Value | What it does |
|----------|-------|--------------|
| Site key | `1x00000000000000000000AA` | Always passes (visible widget) |
| Site key | `2x00000000000000000000AB` | Always fails (visible widget) |
| Site key | `1x00000000000000000000BB` | Always passes (invisible widget) |
| Site key | `2x00000000000000000000BB` | Always fails (invisible widget) |
| Site key | `3x00000000000000000000FF` | Forces an interactive challenge (visible widget) |
| Secret key | `1x0000000000000000000000000000000AA` | Always passes validation |
| Secret key | `2x0000000000000000000000000000000AA` | Always fails validation |
| Secret key | `3x0000000000000000000000000000000AA` | Returns a "token already spent" error |

A test site key produces the dummy token `XXXX.DUMMY.TOKEN.XXXX`. Per Cloudflare, the test keys work on any domain, including `localhost`, `127.0.0.1`, `0.0.0.0` and any development domain.

![Matrix of Turnstile key pairs: a test site key with the 1x test secret passes, a production site key with a production secret passes, a test site key with a production secret is rejected, and a production site key with the 1x test secret accepts any token](/blog/turnstile-test-keys-token-errors-infographic.png)

## Which test key pairs work together

The site key and the secret key live in different places. The site key goes in your page. The secret key goes wherever siteverify runs, which with Static Forms is the form's Security tab.

Here's how the pairs behave:

- **Test site key + test secret key.** Works. The widget issues the dummy token and the `1x…` secret accepts it. The `2x…` and `3x…` secrets fail it on purpose.
- **Test site key + production secret key.** Fails. Cloudflare says production secret keys reject the dummy token.
- **Production site key + `1x…` test secret.** Don't rely on this one to fail. Cloudflare's docs say test secrets reject real tokens, but when we called siteverify on October 27, 2026, the `1x…AA` secret returned `success: true` for an arbitrary string that wasn't the dummy token. If submissions pass, that doesn't prove your keys match.

So when you swap the site key in your HTML for a test key, swap the secret key too, and keep test secrets on a separate test form. A form with the `1x…` secret saved on it accepts any non-empty `cf-turnstile-response`, so any bot can pass it.

## How to test Cloudflare Turnstile on localhost

You have two options, and they test different things.

**Option 1: test keys.** Put `1x00000000000000000000AA` in your page and save `1x0000000000000000000000000000000AA` as the Turnstile secret on a test form. Nothing to register, and it works on any port. Then swap the secret to `2x…`, `3x…` and a made-up string to exercise your failure handling. This tests your integration code, not Cloudflare's risk engine.

**Option 2: a separate development widget.** Create a second widget in the Cloudflare dashboard, add `localhost` under Hostname Management, and use its real keys on a test form. This issues real tokens with real expiry, which is what you want when debugging a token that expires on long forms. Cloudflare recommends that production site keys don't allow local domains, so keep `localhost` off your production widget.

If you skip both and load your production site key on `localhost`, the widget fails with client error `110200` (Domain not authorized).

## Turnstile token errors: lookup table

Find the exact text you're seeing. The tables are split by the layer that produces each message: Static Forms, Cloudflare's siteverify API, the widget in the browser, or your own backend.

### Errors from Static Forms

When a form has Turnstile selected and a secret key saved, `POST https://api.staticforms.dev/submit` returns HTTP 403 with one of these. Requests made with `fetch` get JSON (`success`, `error`, `code`). A url-encoded HTML form post that asks for `text/html` gets the `error` text as the response body, without the code. A `multipart/form-data` post, which any form with a file input sends, gets the JSON.

| `error` text | `code` | Cause | Fix |
|---|---|---|---|
| `Turnstile verification failed. Please complete the captcha.` | `captcha_required` | No non-empty `cf-turnstile-response` field reached the API | Send the token as `cf-turnstile-response`. Check the request payload in DevTools. |
| `Turnstile token expired or was already used. Please refresh the captcha and submit again.` | `captcha_expired_or_reused` | Cloudflare returned `timeout-or-duplicate` or `invalid-input-response`: the token is older than 300 seconds, was already verified, or is malformed. The `2x…` and `3x…` test secrets also land here. | Reset the widget and get a new token. Mint tokens at submit time (execute mode), not on page load. |
| `Turnstile verification failed. Please try again.` | `captcha_failed` | Any other failure: a wrong or invalid secret key (`invalid-input-secret`), or siteverify could not be reached | Copy the secret from the widget in the Cloudflare dashboard again and save it on the form. |

One more message has no `code`: HTTP 500 with `Turnstile verification failed due to server error. Please try again.` Static Forms returns it when an unexpected error stops the check on its side, for example when it can't read the form's stored secret. Nothing in your token or keys causes it, so retry the submission.

Two details from the API code:

- If the same field arrives twice (the widget's own hidden input plus a token you appended to `FormData`), Static Forms verifies the **last non-empty** value. An empty hidden input won't hide your token, but a stale token appended after the fresh one will be the one checked. `formData.set()` avoids the question.
- If the form has no Turnstile secret saved, or CAPTCHA is turned off in its Security tab, Static Forms skips verification and accepts the submission. A test that "passes" may not be checking anything, so save the `2x…` secret once and confirm you get a 403 with `captcha_expired_or_reused`.

### Errors from Cloudflare's siteverify API

You see these in the `error-codes` array if you call siteverify yourself, or in your server logs. Descriptions are Cloudflare's, from the [server-side validation docs](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/):

| Code | Cloudflare's description | Usual cause |
|---|---|---|
| `missing-input-response` | Response parameter was not provided | The token never made it into the request |
| `invalid-input-response` | Token is invalid, malformed, or expired | The token expired, was cut short, or was copied wrong. The `2x…` always-fail test secret also returns it. |
| `timeout-or-duplicate` | Token has already been validated | The same token was verified twice (retries, double submits, or the `3x…` test secret) |
| `invalid-input-secret` | Secret key is invalid or expired | The secret is wrong, for example mistyped or copied only in part |
| `missing-input-secret` | Secret parameter not provided | Your backend didn't send the secret |
| `bad-request` | Request is malformed | Check the request format and parameters |
| `internal-error` | Internal error occurred | Retry the request |

Tokens are valid for 300 seconds, can be validated once, and can be up to 2048 characters long.

### Errors from the widget in the browser

These come back through the widget's `error-callback`, before any token exists. From Cloudflare's [client-side error codes](https://developers.cloudflare.com/turnstile/troubleshooting/client-side-errors/error-codes/):

| Code | Meaning | Fix |
|---|---|---|
| `110100` | Invalid sitekey | Check the site key in the Cloudflare dashboard |
| `110110` | Sitekey not found | Check its spelling and the widget configuration |
| `110200` | Domain not authorized | Add the current hostname under Hostname Management, or use a test site key |
| `300*`, `600*` | Generic challenge failure | Cloudflare treated the visitor as a bot. Retry, then check browser extensions and VPNs, as Cloudflare's [challenge troubleshooting page](https://developers.cloudflare.com/cloudflare-challenges/troubleshooting/challenge-solve-issues/) suggests |

### "The cf-turnstile-response field is required."

Neither Cloudflare nor Static Forms returns this sentence. It's the shape of a server-side `required` validation rule; Laravel, for example, prints `The <field> field is required.` If you see it, your own backend received a request without the field. The usual causes:

- The widget never rendered, so its hidden input was never created.
- A custom `fetch` builds the body by hand (often JSON) and leaves the token out.
- A wrapper library renamed the response field or turned it off.

The fix is the same as for `captcha_required`: confirm the request payload contains a non-empty `cf-turnstile-response`.

## Complete Working Example

This page uses the always-pass test site key, so it works on `localhost` with no Cloudflare setup. Save `1x0000000000000000000000000000000AA` as the Turnstile secret on a **test** form in the Static Forms dashboard (Turnstile is available on Starter and up), then replace `YOUR_TEST_FORM_API_KEY` with that form's API key.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Turnstile test form</title>
  <script src="https://challenges.cloudflare.com/turnstile/v0/api.js?render=explicit&onload=onTurnstileLoad" async defer></script>
  <style>
    body { font-family: system-ui, sans-serif; max-width: 32rem; margin: 3rem auto; padding: 0 1rem; }
    label { display: block; margin-top: 1rem; }
    input, textarea { width: 100%; padding: 0.5rem; }
    button { margin-top: 1rem; padding: 0.5rem 1rem; }
    #status { margin-top: 1rem; }
  </style>
</head>
<body>
  <form id="contact-form" action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_TEST_FORM_API_KEY" />

    <label>Name <input type="text" name="name" required /></label>
    <label>Email <input type="email" name="email" required /></label>
    <label>Message <textarea name="message" rows="4" required></textarea></label>

    <div id="cf-widget"></div>

    <button type="submit" id="submit" disabled>Send</button>
    <p id="status" role="status"></p>
  </form>

  <script>
    // Cloudflare's always-pass test site key. Swap in your real site key for production.
    const SITE_KEY = '1x00000000000000000000AA';

    const form = document.getElementById('contact-form');
    const status = document.getElementById('status');
    const submitButton = document.getElementById('submit');
    let widgetId;
    let pending;

    window.onTurnstileLoad = function () {
      widgetId = turnstile.render('#cf-widget', {
        sitekey: SITE_KEY,
        // Get the token when the form is submitted, so it is seconds old
        // when Static Forms verifies it (tokens expire after 300 seconds).
        execution: 'execute',
        appearance: 'interaction-only',
        callback: function (token) {
          settle(null, token);
        },
        'error-callback': function (code) {
          // Client errors such as 110200 (Domain not authorized) land here.
          settle(new Error('Turnstile widget error ' + code));
        },
        // Without these, an interactive challenge the visitor leaves unfinished
        // would leave the form stuck on "Sending...".
        'timeout-callback': function () {
          settle(new Error('Turnstile challenge timed out'));
        },
        'expired-callback': function () {
          settle(new Error('Turnstile token expired'));
        },
      });
      submitButton.disabled = false;
    };

    // Resolve or reject the token request that is waiting, at most once.
    function settle(error, token) {
      if (!pending) return;
      const waiting = pending;
      pending = null;
      if (error) waiting.reject(error);
      else waiting.resolve(token);
    }

    function getFreshToken() {
      return new Promise(function (resolve, reject) {
        turnstile.reset(widgetId);
        pending = { resolve: resolve, reject: reject };
        turnstile.execute(widgetId);
      });
    }

    async function send() {
      const token = await getFreshToken();
      const formData = new FormData(form);
      // set(), not append(): replaces the widget's hidden input if it exists.
      formData.set('cf-turnstile-response', token);
      const response = await fetch(form.action, {
        method: 'POST',
        headers: { Accept: 'application/json' },
        body: formData,
      });
      // A proxy or platform error page may not be JSON; don't blame Turnstile for it.
      const isJson = (response.headers.get('content-type') || '').includes('application/json');
      const body = isJson ? await response.json() : {};
      return { ok: response.ok, body: body };
    }

    form.addEventListener('submit', async function (event) {
      event.preventDefault();
      submitButton.disabled = true;
      status.textContent = 'Sending...';

      try {
        let result = await send();

        // An expired or already-used token is safe to retry once with a new token.
        if (!result.ok && result.body.code === 'captcha_expired_or_reused') {
          result = await send();
        }

        if (result.ok) {
          status.textContent = 'Thanks, your message was sent.';
          form.reset();
        } else {
          status.textContent = result.body.error || 'Something went wrong. Please try again.';
          console.warn('Static Forms rejected the submission:', result.body);
        }
      } catch (error) {
        status.textContent = 'The spam check could not run. Please reload the page and try again.';
        console.error(error);
      } finally {
        submitButton.disabled = false;
      }
    });
  </script>
</body>
</html>
```

Serve it from a local server rather than opening the file directly, for example `python3 -m http.server 8080` in the file's folder, then open `http://localhost:8080`.

Then run four test cases by changing only the secret key saved on the test form. Keep the Network tab open:

1. `1x0000000000000000000000000000000AA`: the submission goes through and arrives in your inbox.
2. `2x0000000000000000000000000000000AA`: Cloudflare answers `invalid-input-response`, so Static Forms returns 403 with `captcha_expired_or_reused`. The example retries once with a new token, so you see two `submit` requests, and the page then shows "Turnstile token expired or was already used. Please refresh the captcha and submit again."
3. `3x0000000000000000000000000000000AA`: Cloudflare answers `timeout-or-duplicate`. The result matches case 2: two requests, then the same message.
4. A made-up secret, such as the `1x…` secret with one character changed: Cloudflare answers `invalid-input-secret`, so Static Forms returns 403 with `captcha_failed`. The example doesn't retry that code, so you see one request and "Turnstile verification failed. Please try again."

No test secret produces `captcha_failed`. Case 4 is the one to run if you want to see that message.

Before you go live, put your real site key back in the page and use the form whose Security tab holds the matching real secret.

## Troubleshooting checklist

Work through these in order.

1. **Is verification on?** The form needs Turnstile selected and a secret key saved in its Security tab. Without both, Static Forms doesn't check the token.
2. **Is the token in the request?** Open DevTools, find the `submit` request, and look for a non-empty `cf-turnstile-response` in the payload.
3. **Do the keys match?** The site key in your page and the secret on the form must come from the same widget, or both be test keys.
4. **Is the token fresh?** Tokens last 300 seconds and verify once. Render with `execution: 'execute'` and call `turnstile.reset()` before every new attempt, including after a failed submit.
5. **Is the hostname allowed?** A `110200` error means the page's hostname isn't on the widget. Use test keys or a separate development widget for `localhost` and previews.

For general submission debugging (CORS, redirects, status codes), see the [debugging guide](/docs/debugging) and the [troubleshooting page](/docs/troubleshooting).

## Next step

Set up a test form with the `1x…AA` secret, run the example above, then save the `2x…` secret and a mistyped secret in turn, so you've seen both failure messages your visitors can get. The [Turnstile setup guide](/docs/forms/security/turnstile) has the HTML, React and Next.js versions of the widget code for production.

---

## Add a Contact Form to Eleventy Without Writing a Backend

Source: https://www.staticforms.dev/blog/eleventy-contact-form  
Date: 2026-08-19  
Author: Hussain Fakhruddin

Eleventy turns templates into static HTML. That keeps an 11ty site fast and easy to deploy, but the generated site cannot process a contact form or send an email by itself.

You could add a serverless function and an email service. For a basic contact form, a hosted form endpoint is a smaller system to maintain. The visitor submits directly to Static Forms, which validates the request, stores the submission, and sends the notification email.

This guide gives you:

- a complete Nunjucks contact-page template;
- a custom thank-you page;
- honeypot spam protection;
- deployment and production test steps;
- fixes for common Eleventy form problems.

No client-side JavaScript is required.

> **Prefer a working project?** The [complete Eleventy example](https://github.com/static-forms/static-forms-examples/tree/main/apps/eleventy-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## How it works

The submission path is short:

1. Eleventy builds `contact.njk` into static HTML.
2. Your host serves the generated contact page.
3. The browser posts the fields to `https://api.staticforms.dev/submit`.
4. Static Forms delivers the message to your inbox and redirects the visitor to your thank-you page.

The form works on any host that can serve an Eleventy build, including Cloudflare Pages, Netlify, Vercel, GitHub Pages, and a regular web server.

## What you need

Before editing the site, make sure you have:

- an existing Eleventy project;
- a [Static Forms account](https://www.staticforms.dev/register);
- a form API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms);
- the production URL where the Eleventy site will be deployed.

The form API key appears in the generated HTML. That is expected for a browser-submitted form. Treat it as a form identifier rather than a server secret. You can prevent other websites from using it by enabling [domain restriction](/docs/forms/security/domain-restriction), available from the Starter plan up.

## Step 1: create the Eleventy contact template

Create `contact.njk` in your Eleventy input directory. Many projects use the repository root or a folder such as `src` for input files.

If your project already has a base layout, use this page template:

```html
---
layout: layouts/base.njk
title: Contact us
description: Send our team a message.
permalink: /contact/index.html
---

<section class="contact-card" aria-labelledby="contact-heading">
  <h1 id="contact-heading">Contact us</h1>
  <p>Send a message and we will reply by email.</p>

  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
    <input type="hidden" name="replyTo" value="@" />
    <input
      type="hidden"
      name="redirectTo"
      value="https://example.com/thank-you/"
    />

    <div class="honeypot" aria-hidden="true">
      <label for="website">Leave this field empty</label>
      <input
        id="website"
        type="text"
        name="honeypot"
        tabindex="-1"
        autocomplete="off"
      />
    </div>

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

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

    <div class="field">
      <label for="subject">Subject</label>
      <input id="subject" name="subject" type="text" />
    </div>

    <div class="field">
      <label for="message">Message</label>
      <textarea id="message" name="message" rows="7" required></textarea>
    </div>

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

Replace:

- `YOUR_API_KEY` with the key shown for this form in Static Forms;
- `https://example.com/thank-you/` with the absolute production URL of your thank-you page.

The `permalink` front matter makes the output path predictable. Eleventy will generate `_site/contact/index.html` when `_site` is your configured output directory.

### What the hidden fields do

The `apiKey` field associates the submission with your Static Forms form. `replyTo` set to `@` tells Static Forms to use the submitted `email` value as the Reply-To address, so replying to the notification reaches the visitor.

The honeypot is an ordinary text field moved out of view. Basic bots often fill it, while a person does not. Static Forms silently rejects submissions when the `honeypot` field contains a value. The [honeypot guide](/docs/forms/security/honeypot) explains how to test it.

## Step 2: style the form

Add these rules to your existing stylesheet:

```css
.contact-card {
  width: min(100%, 42rem);
  margin-inline: auto;
  padding: clamp(1.5rem, 5vw, 3rem);
  background: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 1rem;
  box-shadow: 0 1rem 3rem rgb(15 23 42 / 8%);
}

.field {
  margin-top: 1.25rem;
}

.field label {
  display: block;
  margin-bottom: 0.4rem;
  font-weight: 650;
}

.field input,
.field textarea,
.contact-card button {
  box-sizing: border-box;
  width: 100%;
  font: inherit;
}

.field input,
.field textarea {
  padding: 0.8rem;
  color: #111827;
  background: #ffffff;
  border: 1px solid #9ca3af;
  border-radius: 0.5rem;
}

.field input:focus,
.field textarea:focus {
  outline: 3px solid rgb(254 91 91 / 25%);
  border-color: #d93636;
}

.field textarea {
  resize: vertical;
}

.contact-card button {
  margin-top: 1.5rem;
  padding: 0.85rem 1rem;
  color: #ffffff;
  background: #d93636;
  border: 0;
  border-radius: 0.5rem;
  font-weight: 700;
  cursor: pointer;
}

.contact-card button:hover {
  background: #b91c1c;
}

.honeypot {
  position: absolute;
  left: -10000px;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
```

Do not remove the `label` elements to make the design shorter. Placeholders disappear while a person is typing and do not replace accessible labels.

If the stylesheet sits outside Eleventy's input directory or uses a path that Eleventy does not copy automatically, configure it as a [passthrough copy](https://www.11ty.dev/docs/copy/). Then confirm the final CSS file exists inside the generated output directory.

## Step 3: add the thank-you page

Create `thank-you.njk` in the same input directory:

```html
---
layout: layouts/base.njk
title: Message received
permalink: /thank-you/index.html
eleventyExcludeFromCollections: true
---

<section aria-labelledby="thank-you-heading">
  <h1 id="thank-you-heading">Thanks, your message was sent.</h1>
  <p>We will reply as soon as we can.</p>
  <p><a href="/">Return to the home page</a></p>
</section>
```

`eleventyExcludeFromCollections` keeps the utility page out of collections that automatically generate post lists or navigation. Your project may handle navigation separately, so check the generated menu before deploying.

A dedicated thank-you URL is also useful for analytics. Count a view of `/thank-you/` as a completed form submission, while remembering that a visitor can open the URL directly.

## Step 4: build and inspect the generated HTML

Run the build command used by your project. A standard Eleventy project commonly uses:

```bash
npx @11ty/eleventy
```

For a local development server:

```bash
npx @11ty/eleventy --serve
```

Eleventy configuration differs between projects. Check the `dir.input` and `dir.output` values in your [Eleventy configuration file](https://www.11ty.dev/docs/config/) if the pages appear in an unexpected directory.

Before deploying, inspect the generated contact page and confirm that:

- `YOUR_API_KEY` is no longer present;
- the form action is exactly `https://api.staticforms.dev/submit`;
- the method is `POST`;
- the thank-you URL points to production;
- every visible input has a unique `name`;
- the stylesheet loads from the generated site.

Avoid inserting the API key through a runtime environment variable on the hosting platform unless your build command actually reads that variable. Eleventy runs at build time. A variable that is configured but never referenced by the build will not change the generated HTML.

## Step 5: deploy and test the production page

Deploy the same output directory you inspected locally. With the default configuration, this is usually `_site`.

Run one complete test from the public URL:

1. Open `/contact/` in a private browser window.
2. Submit a recognizable message such as `Eleventy production form test`.
3. Confirm the browser reaches `/thank-you/`.
4. Check that the submission appears in the Static Forms inbox.
5. Confirm the notification reaches the recipient email.
6. Reply to the notification and verify that the submitted address is used.
7. Repeat once on a phone or narrow browser window.

Testing only on localhost misses problems caused by production domain restrictions, Content Security Policy headers, incorrect output directories, and stale deployments.

## Restrict submissions to your domain

Once the production form works, open the form's Security settings and add the site's hostname without a protocol or path:

```text
example.com
```

Add the host-provided domain too if people can access it directly, for example:

```text
example-project.pages.dev
```

If you enable domain restriction before local testing is finished, allow localhost temporarily. Remove access for unused preview hostnames after the site is stable.

## Common Eleventy contact-form problems

| Symptom | Likely cause | What to check |
| --- | --- | --- |
| `/contact/` returns 404 | The file is outside the Eleventy input directory, ignored, or has a different permalink | Inspect Eleventy configuration and confirm `_site/contact/index.html` exists |
| The page loads without styles | The stylesheet was not copied into the output | Add a passthrough-copy rule and inspect the generated CSS URL |
| The API reports an invalid key | The placeholder survived the build or the key belongs to another form | Search the generated HTML for `YOUR_API_KEY` and copy the current key from the dashboard |
| The form works locally but fails in production | Domain restriction does not include the production or preview hostname | Add each approved hostname without `https://` |
| The thank-you page returns 404 | `redirectTo` and the Eleventy permalink do not match | Compare the absolute redirect URL with the generated output path |
| A field is missing from the email | The input has no `name`, or two controls reuse the same name | Give each submitted field a stable, unique `name` |
| The browser reports a CSP violation | The site's `form-action` policy blocks the external endpoint | Allow `https://api.staticforms.dev` in the production CSP |
| Spam gets through | Honeypots mainly stop basic bots | Add reCAPTCHA v2 (any plan), or [Cloudflare Turnstile](/docs/forms/security/turnstile), hCaptcha, reCAPTCHA v3, or ALTCHA (Starter and up) |

## If your site has a strict Content Security Policy

A Content Security Policy can prevent the browser from sending the form even when the markup is correct. If the console mentions a `form-action` violation, allow the Static Forms endpoint:

```text
Content-Security-Policy: default-src 'self'; form-action 'self' https://api.staticforms.dev
```

Merge that source into the policy you already use. Do not replace an existing policy with the short example without checking the scripts, images, fonts, and connections required by the rest of the site.

## Production checklist

Before linking to the form from your navigation, verify that:

- the contact and thank-you pages exist in the deployed output;
- the generated form contains the correct API key;
- the redirect uses an absolute HTTPS production URL;
- visible controls have labels, names, and clear focus styles;
- a normal submission leaves the honeypot empty;
- the CSP permits `https://api.staticforms.dev` in `form-action`;
- production hostnames are present in domain restriction settings;
- a real submission appears in both the Static Forms inbox and the recipient inbox.

The result is still a static Eleventy site. Eleventy handles the templates and build, your host serves the generated HTML, and Static Forms handles the submission workflow without adding a backend to the project.

---

## How to Add a Contact Form to Cloudflare Pages

Source: https://www.staticforms.dev/blog/cloudflare-pages-contact-form  
Date: 2026-08-17  
Author: Hussain Fakhruddin

Cloudflare Pages can deploy an HTML site across Cloudflare's network, but static files cannot receive a form submission or send an email by themselves. You could add a Pages Function and an email provider. For a contact form, that is often more infrastructure than the job needs.

This tutorial uses a regular HTML form and Static Forms. The browser sends the submission to Static Forms, which validates it and delivers it to your inbox. Your Cloudflare Pages project stays static.

By the end, you will have:

- a contact form that works without client-side JavaScript;
- email delivery and a stored submission in the Static Forms inbox;
- a honeypot field for basic spam filtering;
- a custom thank-you page;
- a deployment and testing checklist for Cloudflare Pages.

## How the submission flows

The setup has three parts:

1. Cloudflare Pages serves your contact page.
2. The visitor's browser posts the form to `https://api.staticforms.dev/submit`.
3. Static Forms processes the submission and sends the notification email.

Cloudflare Pages does not need to run a function in this flow. That also means there is no server code, email credential, or runtime secret to maintain in the Pages project.

## Prerequisites

You need:

- a Cloudflare Pages project, or a static site ready to deploy;
- a free [Static Forms account](https://www.staticforms.dev/register);
- an API key from your form in the [Static Forms dashboard](https://www.staticforms.dev/app/forms).

A Static Forms form API key is used in browser-facing HTML, so visitors can see it in the page source. It is an identifier, not a server password. If you want to stop another website from reusing it, enable [domain restriction](/docs/forms/security/domain-restriction) (Starter plan and up) after your site is deployed.

## Step 1: create the contact page

Create `contact.html` in the directory Cloudflare Pages publishes. Depending on your site, that might be the repository root, `public`, or a generated output directory such as `dist`.

Paste this complete example:

```html
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Contact us</title>
    <meta
      name="description"
      content="Send our team a message and we will reply by email."
    />
    <style>
      :root {
        color-scheme: light dark;
        font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      }

      body {
        margin: 0;
        background: #f7f7fb;
        color: #1f2937;
      }

      main {
        width: min(100% - 2rem, 42rem);
        margin: 4rem auto;
      }

      .contact-card {
        padding: clamp(1.5rem, 5vw, 3rem);
        background: #ffffff;
        border: 1px solid #e5e7eb;
        border-radius: 1rem;
        box-shadow: 0 1rem 3rem rgb(15 23 42 / 8%);
      }

      h1 {
        margin-top: 0;
      }

      .field {
        margin-top: 1.25rem;
      }

      label {
        display: block;
        margin-bottom: 0.4rem;
        font-weight: 650;
      }

      input,
      textarea,
      button {
        box-sizing: border-box;
        width: 100%;
        font: inherit;
      }

      input,
      textarea {
        padding: 0.8rem;
        color: #111827;
        background: #ffffff;
        border: 1px solid #9ca3af;
        border-radius: 0.5rem;
      }

      input:focus,
      textarea:focus {
        outline: 3px solid rgb(254 91 91 / 25%);
        border-color: #d93636;
      }

      textarea {
        min-height: 9rem;
        resize: vertical;
      }

      button {
        margin-top: 1.5rem;
        padding: 0.85rem 1rem;
        color: #ffffff;
        background: #d93636;
        border: 0;
        border-radius: 0.5rem;
        font-weight: 700;
        cursor: pointer;
      }

      button:hover {
        background: #b91c1c;
      }

      .honeypot {
        position: absolute;
        left: -10000px;
        width: 1px;
        height: 1px;
        overflow: hidden;
      }

      @media (prefers-color-scheme: dark) {
        body {
          background: #0f172a;
          color: #e5e7eb;
        }

        .contact-card {
          background: #111827;
          border-color: #374151;
        }
      }
    </style>
  </head>
  <body>
    <main>
      <section class="contact-card" aria-labelledby="contact-heading">
        <h1 id="contact-heading">Contact us</h1>
        <p>Send a message and we will reply by email.</p>

        <form action="https://api.staticforms.dev/submit" method="POST">
          <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
          <input type="hidden" name="replyTo" value="@" />
          <input
            type="hidden"
            name="redirectTo"
            value="https://YOUR-PROJECT.pages.dev/thank-you.html"
          />

          <div class="honeypot" aria-hidden="true">
            <label for="website">Leave this field empty</label>
            <input
              id="website"
              type="text"
              name="honeypot"
              tabindex="-1"
              autocomplete="off"
            />
          </div>

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

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

          <div class="field">
            <label for="message">Message</label>
            <textarea id="message" name="message" required></textarea>
          </div>

          <button type="submit">Send message</button>
        </form>
      </section>
    </main>
  </body>
</html>
```

Replace two values before deploying:

- `YOUR_API_KEY` with the key shown for your form in Static Forms;
- `YOUR-PROJECT` with your Cloudflare Pages project name.

If your site uses a custom domain, put that domain in `redirectTo` instead. The value must be an absolute URL, for example `https://example.com/thank-you.html`.

### Why these hidden fields are present

`apiKey` tells Static Forms which form should receive the submission. `replyTo` set to `@` uses the submitted `email` field as the Reply-To address. This lets you reply to the visitor from the notification email.

The `honeypot` input catches basic bots that fill every text field. Real visitors never interact with it. See the [honeypot documentation](/docs/forms/security/honeypot) for testing instructions and stronger protection options.

## Step 2: add the thank-you page

Create `thank-you.html` beside `contact.html`:

```html
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Message received</title>
  </head>
  <body>
    <main>
      <h1>Thanks, your message was sent.</h1>
      <p>We will reply as soon as we can.</p>
      <p><a href="/">Return to the home page</a></p>
    </main>
  </body>
</html>
```

Keep the thank-you page out of your main navigation. A visit to this page can then serve as a clean form-completion event in your analytics tool.

## Step 3: deploy to Cloudflare Pages

Cloudflare supports Git integration and direct uploads. Use the one that matches your project.

### Git integration

Commit `contact.html` and `thank-you.html` to the connected repository. Cloudflare Pages builds the configured branch and publishes the output automatically.

Check your Pages build settings before pushing:

- The build command should match your static site generator. Plain HTML sites can leave it blank.
- The build output directory must contain both new files.
- Preview deployments use a different hostname from production, so test the production deployment before sharing the link.

Cloudflare's current [Git integration guide](https://developers.cloudflare.com/pages/get-started/git-integration/) explains the repository and build settings.

### Direct upload

If your site is not connected to Git, build it locally and upload the output directory from the Cloudflare Pages dashboard. Do not upload the source directory if your framework generates a separate `dist`, `build`, or `public` folder.

See Cloudflare's [Direct Upload guide](https://developers.cloudflare.com/pages/get-started/direct-upload/) for the current dashboard workflow.

After deployment, open:

```text
https://YOUR-PROJECT.pages.dev/contact.html
```

## Step 4: test the deployed form

Do not stop after checking that the page renders. Run one real submission through the production URL.

1. Open the contact page in a private browser window.
2. Enter a name, an email address you can access, and a recognizable test message.
3. Submit once and confirm that the browser reaches `thank-you.html`.
4. Check the Static Forms inbox for the submission.
5. Check the recipient inbox and spam folder for the notification email.
6. Reply to the notification and confirm that the response is addressed to the email entered in the form.
7. Repeat the test on a phone or narrow browser window.

Use a message such as `Cloudflare Pages production test 2026-08-17` so it is easy to find and delete later.

## Lock the form to your Cloudflare domain

Anyone can view a form API key in client-side HTML. That is expected. Domain restriction prevents another site from submitting with the same key.

In the form's Security settings, add the deployed hostname without `https://` or a path:

```text
YOUR-PROJECT.pages.dev
```

If you use a custom domain, add that too:

```text
example.com
```

Enable localhost only while you need local testing. Domain restriction is available from the Starter plan up; the [domain restriction guide](/docs/forms/security/domain-restriction) covers subdomains and common configuration mistakes.

## Fix a Content Security Policy error

A strict Content Security Policy can block the browser before the request reaches Static Forms. The console usually reports that the form action violates the page's `form-action` directive.

Cloudflare Pages reads response-header rules from a plain-text `_headers` file in the static asset directory. If you already send a CSP, add the Static Forms endpoint to `form-action`:

```text
/*
  Content-Security-Policy: default-src 'self'; form-action 'self' https://api.staticforms.dev
```

Do not copy that whole policy into an existing site without reviewing it. Merge the `form-action` source into the policy you already use, otherwise you may accidentally block scripts, images, fonts, or API calls needed by the rest of the site.

Cloudflare documents the file syntax in [Headers · Cloudflare Pages](https://developers.cloudflare.com/pages/configuration/headers/).

## Common problems

| Symptom | Likely cause | What to check |
| --- | --- | --- |
| The API reports an invalid key | The placeholder was not replaced, or the key belongs to another form | Copy the current key from the Static Forms dashboard |
| The form works locally but fails after domain restriction | The production hostname is missing from the allowed list | Add `YOUR-PROJECT.pages.dev` and any custom domain without a protocol |
| The submission succeeds but there is no email | The recipient is unverified, the message was filtered, or delivery is delayed | Check the Static Forms inbox first, then spam and recipient settings |
| The browser reports a CSP violation | `form-action` does not allow the Static Forms endpoint | Update the Pages `_headers` file and redeploy |
| The thank-you page returns 404 | The file was outside the published output directory | Inspect the deployed artifact and verify the exact filename and URL |
| You receive bot submissions | A honeypot stops only basic automated traffic | Add reCAPTCHA v2 (any plan), or [Cloudflare Turnstile](/docs/forms/security/turnstile), reCAPTCHA v3, hCaptcha, or ALTCHA (Starter and up), in the form's Security settings |
| A custom field is missing | The input has no `name` attribute | Give every submitted input a unique `name` |

## Optional: use Cloudflare Turnstile

Cloudflare Turnstile is a useful next step if the honeypot does not stop enough spam. Static Forms supports it from the Starter plan up. Create a Turnstile widget for your production hostname, then configure its secret in Static Forms and add the widget to the page.

Follow the [Static Forms Turnstile guide](/docs/forms/security/turnstile). Test both an accepted submission and a failed challenge before enabling domain restriction (Starter plan and up) on every environment.

## Production checklist

Before calling the form finished, verify that:

- the deployed form uses the correct API key;
- the recipient email is verified;
- the thank-you URL uses HTTPS and exists in production;
- every visible control has a label and a `name`;
- keyboard focus is visible;
- the honeypot remains empty during a normal submission;
- the Pages CSP permits `https://api.staticforms.dev` in `form-action`;
- production and custom hostnames are in the domain allowlist;
- a real submission appears in both the Static Forms inbox and the recipient inbox.

The page remains a static Cloudflare Pages deployment throughout this setup. Static Forms handles form processing, email delivery, submission storage, and optional spam controls without adding a Pages Function to your project.

---

## JavaScript Form Submit to Email: Developer Guide

Source: https://www.staticforms.dev/blog/javascript-form-submit-to-email  
Date: 2026-07-26T07:59:50.583Z  
Author: Static Forms Team

Most advice on **JavaScript form submit to email** skips the part that matters: the browser can collect the data, but it cannot send the email by itself. If you try to make the front end do the whole job, you end up with brittle `mailto:` hacks, exposed credentials, or a form that works in a demo and fails in production.

## Why JavaScript Cannot Send Email Directly

The hard constraint is simple, the browser does not provide direct SMTP capability, so **plain client-side JavaScript cannot reliably send email on its own**. That's been true for a long time, and the architecture still matters now, because the form UI and the mail delivery step are separate problems. Guides going back two decades framed the fallback the same way — a `mailto:` action in the form's `ACTION` attribute — and the conclusion hasn't changed: JavaScript alone can't email a form, a backend or hosted service has to do the actual sending. [InformIT's classic write-up on emailing form results](https://www.informit.com/articles/article.aspx?p=30105&seqNum=5) is a good look at how long this constraint has been true.

![An infographic explaining why JavaScript cannot send emails directly due to security, architectural, and browser limitations.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/d8c21d1e-edfd-4277-996d-7aee75f28f3d/javascript-form-submit-to-email-javascript-limitations.jpg)

### The browser handles interaction, not delivery

A clean mental model helps here. **JavaScript is for validation, serialization, and user experience**, while the server or email service is for delivery. If you keep those roles separate, the code stays predictable, and the failure modes become obvious.

`mailto:` is a weak fallback because it depends on the user's local mail client and can expose the recipient's address in page source. Client-side SMTP libraries look tempting, but they're a security problem because anything in front-end code is visible to users, including credentials and service secrets. That's why static-site developers usually choose a hosted form backend instead of trying to make the browser speak SMTP directly.

> **Practical rule:** if the browser is the only thing moving the data, it's not an email pipeline yet.

For a deeper dive into the SMTP side of the handoff, this internal guide on [Gmail SMTP server setup patterns](https://www.staticforms.dev/blog/gmail-smtp-server) fits the same architectural boundary. The key point is still the same, JavaScript can start the submission, but something mail-capable has to finish it.

## Building a Working Form That Submits to Email

A form that reaches an inbox starts with ordinary HTML, not clever JavaScript. The **action**, **method**, and every input's **name** attribute are the pieces that make the payload serializable. If a field doesn't have `name`, it won't show up in the submitted body, even if it looks fine on screen — the [guide to creating an HTML form](https://www.staticforms.dev/blog/create-an-html-form) covers the markup side in more detail.

![A laptop on a wooden desk displaying JavaScript code for a contact form submission.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/12f3cff0-0416-413f-940e-5d243ec07e91/javascript-form-submit-to-email-coding-workspace.jpg)

### Plain HTML that posts to a hosted endpoint

A static-site form can post straight to a mail-capable endpoint. The pattern below uses a realistic submission URL, a hidden API key, and form fields that will serialize correctly.

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />

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

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

  <label>
    Company
    <input type="text" name="company" autocomplete="organization" />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

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

The browser submits those fields as form data, and the endpoint handles the email delivery step. For a JavaScript-enhanced version, the front end can still intercept submit for validation or loading state, then pass the same `FormData` to the endpoint.

### React, Next.js, and Vue patterns

In React, the submit handler usually just stops the page reload and forwards the data:

```jsx
function ContactForm() {
  const handleSubmit = async (event) => {
    event.preventDefault();
    const formData = new FormData(event.currentTarget);

    await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      body: formData,
    });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
      <input name="name" type="text" required />
      <input name="email" type="email" required />
      <textarea name="message" required />
      <button type="submit">Send</button>
    </form>
  );
}
```

In Next.js, keep the form client-side if you're posting directly from the browser, or send it to a route handler if you want to add your own checks first:

```jsx
'use client';

export default function ContactForm() {
  const handleSubmit = async (event) => {
    event.preventDefault();
    const formData = new FormData(event.currentTarget);

    await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      body: formData,
    });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
      <input name="name" type="text" required />
      <input name="email" type="email" required />
      <textarea name="message" required />
      <button type="submit">Send</button>
    </form>
  );
}
```

A Vue version uses `v-model` for local state, then still posts a `FormData` payload:

```vue
<template>
  <form @submit.prevent="handleSubmit">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
    <input name="name" v-model="name" type="text" required />
    <input name="email" v-model="email" type="email" required />
    <textarea name="message" v-model="message" required></textarea>
    <button type="submit">Send</button>
  </form>
</template>

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

const name = ref('');
const email = ref('');
const message = ref('');

async function handleSubmit(event) {
  const formData = new FormData(event.target);
  await fetch('https://api.staticforms.dev/submit', {
    method: 'POST',
    body: formData,
  });
}
</script>
```

A good first implementation usually keeps the network path explicit. The endpoint receives the form, processes it, and returns a success or error state you can reflect back in the UI.

## Adding Production Essentials to Your Form Pipeline

A form that posts successfully still isn't production-ready. Real sites need **spam protection**, **file handling**, **success and error redirects**, and a sensible email workflow so the inbox doesn't become the only source of truth. The production choice is usually less about “can it send?” and more about “can it survive spam, retries, and real users?”

![An infographic titled Adding Production Essentials to Your Form Pipeline outlining six key steps for form management.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/7105fd27-2951-4384-b13d-e9672c761206/javascript-form-submit-to-email-production-pipeline.jpg)

### Spam protection and file uploads

For spam, the common options are **reCAPTCHA v2/v3**, **hCaptcha**, **Cloudflare Turnstile**, **ALTCHA**, and a simple **honeypot** field. A honeypot is easy to ship and has low UX cost, but it's not enough by itself on exposed public forms. CAPTCHA-style checks add friction, so I usually start with the lightest option that meaningfully cuts bot traffic for the site in question.

A honeypot is just a field humans never see:

```html
<input type="text" name="honeypot" tabindex="-1" autocomplete="off" class="hidden" />
```

On the server or service side, reject submissions when that field isn't empty. Static Forms does this automatically for any field whose name contains `honeypot`, and strips it from the stored submission — see the [honeypot docs](https://www.staticforms.dev/docs/forms/security/honeypot). For reCAPTCHA or Turnstile, verify the token after submit and before any mail is sent. That server-side check matters more than the widget itself.

File uploads belong in the same pipeline, but they need more care. Static Forms supports uploads on Starter and up, **up to 4.5MB per submission** counting every file plus the other fields, which is the kind of limit you want surfaced in the UI before the user hits send. If you accept attachments, keep the payload multipart and make sure your endpoint and email flow can carry the file through instead of dropping it.

### Redirects, confirmations, and deliverability

Hidden fields are the cleanest way to control redirect behavior after submit:

```html
<input type="hidden" name="redirectTo" value="https://yoursite.com/thanks" />
```

`redirectTo` is the field the submit endpoint reads. Error-page routing is configured per form in the builder rather than posted from the markup, which keeps the form itself simple and avoids baking routing logic into the front end. For confirmation emails, autoresponders help users know their message arrived. If you need richer follow-ups, some teams use AI draft assistance for auto-replies, but the logic still needs to be reviewed before it reaches real customers.

Delivery quality also depends on authenticated sending. If the mail comes from your own domain, **SPF, DKIM, and DMARC** belong in the setup conversation from day one. Static Forms documents custom-domain sending, and that's the right direction for production forms because inbox providers care about authentication, not just whether the request completed. A helpful companion read is [email deliverability best practices](https://www.staticforms.dev/blog/email-deliverability-best-practices), especially if your contact form feeds sales or support.

## Comparing Alternative Approaches for Form-to-Email Delivery

There isn't one right answer for every site. The trade-off is usually between control, maintenance, and how much delivery infrastructure you want to own. For some projects, a hosted backend is enough. For others, a serverless function or a vendor SDK makes more sense.

| Approach | Setup Effort | Spam Protection | Maintenance | Best For |
| --- | --- | --- | --- | --- |
| Serverless function | Higher | DIY | Higher | Teams that want full control |
| EmailJS | Moderate | Service-dependent | Lower | Front-end teams that want client-side initiation |
| `mailto:` | Very low | None | Low, but unreliable | Quick internal prototypes |
| Hosted form backend | Low | Built-in or configurable | Low | Static sites and JAMstack projects |

### What each option buys you

A **serverless function** on AWS Lambda, Vercel, or Netlify gives you control over validation, routing, and custom logic, but you own the moving parts. That's fine when the form has business rules, attachments, or deeper integrations, and it becomes annoying when the form is just a contact box.

**EmailJS** sits in a useful middle ground. Its flow uses a public key and a `sendForm(...)` call, so JavaScript can initiate delivery without you running your own backend. The catch is that it still relies on an intermediary service, and the public key sits in your client bundle — worth understanding before you adopt it.

`mailto:` is only good as a quick hack. It opens the user's mail client, depends on local configuration, and doesn't give you reliable submission handling. If the goal is actual form processing, it's the wrong tool.

For hosted backends, the practical question is whether you want a dashboard, retries, webhooks, and exported submissions without building them yourself. **Static Forms** is one option in that category, with webhooks from its Starter plan up. Whichever you compare, weigh the things that break in production: spam controls, file limits, redirect handling, whether webhooks retry, and how much operational work you're willing to own.

## Security and GDPR Compliance for Static Site Forms

Static sites don't get a pass on compliance just because there's no database in your repo. A contact form still collects personal data, and once that data lands in email, a dashboard, or a webhook, you need a clear policy for consent, retention, and deletion. The safest forms make those rules visible in the UI and enforce them on the back end.

### Consent, retention, and user rights

For GDPR-sensitive forms, add a required consent checkbox only when you need consent for the purpose being collected. Don't bundle marketing consent with transactional contact intent. Keep the wording separate, and store a timestamp or submission log on the service side so you can show when consent was granted.

A minimal checkbox pattern looks like this:

```html
<label>
  <input type="checkbox" name="consent" required />
  I agree to the processing of my data for this request.
</label>
```

If the submission is for newsletter signup, that checkbox should be different from a general contact request. Data export and deletion workflows matter too, which is why a dashboard with search, export, and removal tools saves a lot of manual work when someone asks what you've stored.

### Protect the endpoint, not just the form

API keys should never be treated as secret when they're placed in client-side code. If the service expects a public key, restrict what that key can do and validate anything sensitive server-side. The anti-bot token must be checked after submit, not just rendered in the browser.

> A form that only works when everything is trusted is a demo, not a production system.

Spam bots will hit any visible form that looks useful. If you expose a webhook or email endpoint, rate limiting, server-side validation, and abuse monitoring should sit behind it. That's true whether the front end is vanilla HTML, React, Next.js, or Vue.

A final point that gets ignored too often, consent for marketing mail is not the same as consent to reply to a support request. Keep those workflows separate, store only what you need, and don't let a convenient form shortcut turn into a compliance problem later.

## Testing Your Form and Connecting Integrations

Before you ship, test the full path, not just the button click. Submit valid data, submit invalid data, check the inbox, confirm the redirect, and inspect the server logs or dashboard record. If the form has attachments, test the boundary cases too, especially when the submission is near the **4.5MB** submission cap supported by Static Forms, which counts every file plus the other fields.

![A five-step flowchart illustrating the process for testing a web form pipeline from submission to logging.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/8b9ad7bb-118b-481e-a9c4-f3af2d8f05ca/javascript-form-submit-to-email-testing-process.jpg)

### A test checklist that catches real failures

A good form test run usually includes these checks:

- **Valid submission:** send a clean payload and confirm the email arrives with formatting intact.
- **Invalid submission:** remove required fields or use a bad email address and verify the front-end and back-end both reject it.
- **Spam trigger:** submit with the honeypot filled or the CAPTCHA token missing and confirm the request is blocked.
- **Redirect behavior:** confirm both success and error redirects land on the right page.
- **Attachment handling:** upload a file near the service's supported limit and verify it still arrives.

Those checks matter because the most common failure is an inconsistent handoff between browser state and backend state. If the UI says “sent” before the mail service accepts the payload, users will trust a broken flow.

### Webhooks and downstream tools

Once the form is stable, webhooks are the cleanest way to feed other systems. A JSON POST webhook can power Zapier, Make, or n8n, and a good endpoint should retry on failure instead of dropping the event. That same pattern can also append rows to Google Sheets, post to Slack, Discord, or Telegram, create Notion pages, add Airtable records, or subscribe a user to a Mailchimp audience — the [integrations docs](https://www.staticforms.dev/docs/integrations) list what each destination expects.

One caveat once automation touches submissions: if a form triggers AI-drafted triage or replies, the privacy story has to stay as clear as the submission flow. Say what the data is used for on the form itself, not only in a policy page nobody opens.

If you're exporting CSVs, double-check the field mapping before you build any downstream automations. A clean webhook payload beats manual copy-paste every time, and it keeps the form as the single source of truth for the fields you captured.

## Choosing the Right Form Architecture for Your Project

A personal portfolio can usually get by with a hosted backend and basic spam protection. An agency site often wants redirects, webhooks, and a dashboard, while a SaaS landing page may need stronger deliverability, consent controls, and integrations from day one. Enterprise forms usually need the most restraint, because compliance, routing, and retention policies matter as much as the inbox notification.

The decision usually comes back to one principle, **JavaScript handles the browser side, and a service handles delivery**. Once you accept that split, the rest of the architecture becomes straightforward. You decide where validation lives, how abuse is blocked, where submissions are stored, and what downstream systems receive the data.

For most static and JAMstack projects, I'd start with a hosted form backend, then add webhooks or additional destinations only when the workflow proves it needs them. If the form is tied to regulated data or complex routing, move sooner to a backend you control. The right setup is the one you can operate without babysitting every week.

---

If you want to ship a contact form without wiring up your own backend, [Static Forms](https://www.staticforms.dev) gives you an email-backed submission endpoint for static sites, plus a dashboard, redirects, spam controls, and integration paths when you need them. It's a practical fit when you want JavaScript to handle the form experience while a service handles delivery.

---

## EU Data Residency for Submissions and File Uploads

Source: https://www.staticforms.dev/blog/eu-data-residency-form-submissions-file-uploads  
Date: 2026-07-26  
Author: Static Forms Team

Every form backend makes a quiet decision on your behalf: where the data lands. For most of them the answer is "somewhere in the United States", and you only find out when a customer sends you a DPA questionnaire asking which country their applicants' CVs are stored in.

Static Forms now lets you make that decision yourself. Pick **European Union** when you sign up and your form data — submissions, file attachments, webhook delivery logs and AI reply logs — is stored in AWS `eu-central-1` (Frankfurt) instead of `us-east-1`. Not replicated to the US, not cached in the US, not written to a US table first and copied over. The row and the uploaded file are created in Frankfurt and read back from Frankfurt.

This post is the engineering detail behind that sentence: how a submission is routed, where an attachment physically sits, how the download link is signed, and — the part most residency announcements skip — the things that deliberately stay in the United States for every account. The exact legal scope is in our [DPA](https://www.staticforms.dev/dpa); this is the same scope, written for developers.

---

## The split: control plane vs data plane

The architecture has one rule, and everything else follows from it. **Account state is global. Form data is regional.**

| Stays global (US) | Regional (follows your pick) |
|---|---|
| Your user record, login, billing | Form submissions |
| Form/workspace configuration and API keys | File attachments (S3 objects + file records) |
| Rate-limit counters, storage quota counters | Webhook delivery logs |
| Email delivery (SES) | AI reply logs |
| Operational request logs | Submission retention and cleanup |

Why keep the control plane global? Because it is what lets there be **one product**. There is no `eu.staticforms.dev`, no second dashboard, no separate login, no parallel release train, and no second API key to manage. You log in at [staticforms.dev](https://www.staticforms.dev), and your API key resolves the same way regardless of region. Only the tables and buckets your submissions live in change.

> Your account record — owner email and anonymized consent IP — stays in the US `users` table for every account, including EU ones. We state that plainly in the DPA rather than engineering around it, because pretending otherwise would be the interesting kind of lie.

---

## What happens to a submission

There is a single ingest endpoint for everyone: `https://api.staticforms.dev/submit`. You do not swap it for a regional URL, and your HTML does not change.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>Contact Us</title>
</head>
<body>
  <!-- Identical markup for a US-region and an EU-region account -->
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

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

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

    <label for="message">Message</label>
    <textarea id="message" name="message" required></textarea>

    <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you" />
    <button type="submit">Send</button>
  </form>
</body>
</html>
```

Behind that request:

1. **The API key is resolved in the global control plane.** One lookup tells us which account owns the form, what plan it is on, and which region it is pinned to.
2. **Validation runs before anything is stored** — spam checks, CAPTCHA, rate limits, plan limits. Nothing region-specific here.
3. **The submission row is written to the owning account's region.** For an EU account that is the Frankfurt `form_submissions` table. Not a US table with a region flag on it — a different table, in a different AWS region.
4. **Every later write follows the same route.** Delivery status, read/unread, spam and not-spam, timeline entries, webhook attempt logs, AI reply logs. They are all keyed to the region resolved in step 1, including the ones written asynchronously by queue consumers, because the region travels inside the queue payload.

The consequence worth internalizing: **an EU account's submission never exists as a row in `us-east-1`.** We verified that the hard way before shipping — after a full end-to-end pass (signup, submission, attachment, inbox, mutations, export, webhook, AI reply, deletion) the US tables held **zero** rows for that account across submissions, file uploads, webhook logs and AI reply logs.

---

## What happens to a file attachment

File uploads are the part where residency usually leaks, because a file has two lives: the bytes in object storage, and the metadata row that makes them findable. Both are regional.

Adding uploads to the form above is one attribute and one input — again, identical for both regions:

```html
<form
  action="https://api.staticforms.dev/submit"
  method="POST"
  enctype="multipart/form-data"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="text" name="name" required />
  <input type="email" name="email" required />

  <label for="document">Attach your CV (PDF, max 4MB)</label>
  <input type="file" id="document" name="document" accept=".pdf,.doc,.docx" />

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

What the platform does with `document`:

- ✅ **The bytes are uploaded to your region's private bucket.** Each region has its own S3 bucket — bucket names are globally unique, so this is a genuinely separate bucket in a separate AWS region, with Block Public Access on and `AES256` server-side encryption.
- ✅ **The file record is written to your region's `file_uploads` table**, alongside the submission it belongs to. The record — original filename, MIME type, size, object key — is data-subject content, so it lives where the submission lives.
- ✅ **Downloads are signed against the regional bucket.** Clicking a download in your [Inbox](https://www.staticforms.dev/app/inbox) mints a fresh presigned `GET` URL that expires in **5 minutes**, signed for the bucket the object is actually in. For an EU account the bytes travel from Frankfurt to your browser — there is no US proxy hop and no US copy to serve from.
- ✅ **Storage quota accounting stays global.** The counter is a number of bytes on your account record, not form data, so it lives in the control plane with the rest of your account state. The bytes it counts never leave your region.
- ✅ **Expiry and deletion happen in region.** Delete a submission and its file records and S3 objects are removed from your region's table and bucket. The retention sweep visits **every** region rather than assuming US, so an EU account's expired attachments are actually collected instead of lingering forever.

One deliberate failure mode, since it affects what you see: if persistent storage is unavailable for a file, the submission is still accepted and the file is still delivered by email, but no download button appears for it in the inbox. A storage problem never costs you a lead — and it never quietly falls back to storing the file in another region either.

File uploads are available from the Starter plan up, and the whole submission, every file plus the other fields, has to stay under 4.5MB. See [file uploads in the docs](https://www.staticforms.dev/docs/forms/file-uploads) for limits and framework snippets, or the walkthrough in [Next.js contact form with document upload](/blog/nextjs-contact-form-document-upload). For the HTML side (accessible inputs, size checks and previews), see the [HTML file upload guide](/blog/file-upload-html).

---

## Teams that span regions

An agency owner pinned to the EU can invite a teammate whose own account is US-region — or who signed up before regions existed at all. Routing that teammate's reads by *their* region would query an empty Frankfurt-less table and render the workspace as if it had no data.

So routing follows **the account that owns the data**, never the person looking at it. A US-based teammate opening an EU workspace reads from Frankfurt, and when they mark a submission read, reply, or unmark spam, the write lands in Frankfurt too. Nothing about cross-region team access pulls a copy into the US.

---

## What EU residency does not move

This is the section we would rather you read twice than discover later. Selecting the EU region relocates **storage of form data**. It does not relocate everything, and we will not market it as "your data stays in the EU".

- **Email delivery is US, for every account.** Notification and auto-responder emails are sent through AWS SES in `us-east-1`, with Singapore (`ap-southeast-1`) as delivery failover. The email carries the submission, so this is a transmission out of the region — disclosed in our [DPA](https://www.staticforms.dev/dpa) §8 and in the [Transfer Impact Assessment](https://www.staticforms.dev/dpa/transfer-impact-assessment), and covered by SCCs / the EU-U.S. Data Privacy Framework. SES does not retain message content, but it does keep a per-region suppression list of recipient addresses.
- **Operational request logs are US, for every account.** Request metadata — IP, user agent, referer, delivery status, and form field **names** — is logged in the US for 365 days. **Field values are never logged**, by design and enforced in code: the submit path logs the keys of your payload, never the contents. Keeping this pipeline single-region is what keeps our abuse tooling working; an attacker should not be able to buy log immunity by picking a region at signup.
- **Account and billing data are US, for every account** (see the table above).

The supportable claim is precise: *form data stored in the EU, email delivered from the US, operational logs in the US.* That is what the DPA, the sub-processor table, Annex III and the TIA all say, and it is what the product actually does.

---

## Choosing and changing your region

- **At signup.** The region picker sits above both signup paths — email and Google — and defaults to United States. It applies to the account on its **first** write, so an OAuth signup gets the region you picked, not a US default it has to be rescued from later.
- **After signup, while you are empty.** You can change the region from your [account page](https://www.staticforms.dev/app/account) for as long as the account holds **no** stored form data. The check runs server-side across every region — submissions and file uploads, not just the pinned region — and fails closed: if the check itself errors, the change is refused. Refusing a change is recoverable; splitting an inbox across two continents is not.
- **Once your first submission arrives, the pin is final.** Not a policy choice, a physical one: the rows and objects are in that region, and there is no migration that keeps a live inbox coherent while it runs. The account page shows the pin as locked with the reason.

Pick deliberately, then. If you are collecting personal data from EU residents — job applications, patient intake, member records — the EU region is the one that removes the third-country transfer for that data at rest.

---

## Adding regions from here

The region registry is config, not code: a region is an entry with an AWS region, a label, an uploads-bucket environment variable and an email-send region. Every submission, file, log and cleanup path resolves through that registry, so adding a third region (APAC is the obvious next one) means provisioning infrastructure and adding a registry entry — not auditing hundreds of call sites again.

If you need residency in a geography we do not serve yet, [tell us which one](https://www.staticforms.dev/contact). That request is now a provisioning ticket rather than a rewrite.

---

## Get started

1. **New account?** Choose your region on the [signup page](https://www.staticforms.dev/register) — United States (default) or European Union (Frankfurt).
2. **Existing account with no submissions yet?** Set it from your [account page](https://www.staticforms.dev/app/account) before your first submission lands.
3. **Need the exact wording for a customer questionnaire?** The [DPA](https://www.staticforms.dev/dpa), the [sub-processor list](https://www.staticforms.dev/dpa/sub-processors) and the [Transfer Impact Assessment](https://www.staticforms.dev/dpa/transfer-impact-assessment) all name the regions, the sub-processors and the transfer mechanisms line by line.
4. **Just getting started with forms?** Begin with [Getting started with Static Forms](/blog/getting-started-with-static-forms), then, on the Starter plan or above, add [privacy-first spam protection with Altcha](/blog/implementing-altcha-captcha-html-website) — no third-party tracking, which pairs well with an EU-resident inbox.

That's it. Same endpoint, same API key, same dashboard — your form data just lives where you need it to.

---

## 10 Best Free Form Processing Services for 2026

Source: https://www.staticforms.dev/blog/free-form-processing-service  
Date: 2026-07-24T09:45:00.596Z  
Author: Static Forms Team

Your static site is live, but the contact form still goes nowhere. You don't need a backend project just to catch leads, route support requests, or let a client upload a file. A **free form processing service** solves that by taking a plain HTML form, posting it to a hosted endpoint, and handling delivery, spam filtering, storage, and sometimes webhooks for you, which is the basic pattern described in the Static Forms guide to [free HTML form processing](https://www.staticforms.dev/blog/free-html-form-processing).

## 1. Static Forms

A contact form that just works is usually the difference between a site that looks finished and one that ships. Static Forms fits that job well, because you point the form at `https://api.staticforms.dev/submit`, add an API key, and let the service handle delivery instead of standing up a backend or database. For the broader pattern behind this setup, the [Static Forms HTML form processing guide](https://www.staticforms.dev/blog/free-html-form-processing) lays out the basic flow for static and JAMstack sites.

![Static Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/3dd260a5-5238-45d3-904e-fd39120a8fe8/free-form-processing-service-html-form-backend.jpg)

What stands out in practice is the handoff. A form backend only earns its place if it gives you a reliable destination for submissions and stays out of the way when the workflow grows. Static Forms supports email delivery, dashboard storage, CSV export, redirects, and paid-plan routing to webhooks (Starter and up) and downstream tools, so it behaves like infrastructure instead of a one-off inbox.

> **Practical rule:** start with plain HTML first, then add integrations only when the form earns them.

### Copy-paste HTML

```html
<form action="https://api.staticforms.dev/submit" method="POST" enctype="multipart/form-data">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you" />
  <label>Name <input type="text" name="name" required /></label>
  <label>Email <input type="email" name="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
</form>
```

### Copy-paste React

```jsx
export default function ContactForm() {
  return (
    <form action="https://api.staticforms.dev/submit" method="POST" encType="multipart/form-data">
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
      <input type="text" name="name" placeholder="Name" required />
      <input type="email" name="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <button type="submit">Send</button>
    </form>
  );
}
```

Full setup, including the redirect and autoresponder options, is in the [quick start guide](https://www.staticforms.dev/docs/quick-start).

The trade-offs are straightforward. The free tier works for small sites, but file persistence, integrations, and richer automation push you toward paid plans. That is still a good trade if you want GDPR-ready controls, spam protection options, and a path from a simple contact form to workflows that feed Slack, Sheets, Notion, Airtable, or Mailchimp without reworking the frontend.

## 2. Formspree

Formspree fits the case where you need a hosted form endpoint that a teammate can read, maintain, and hand off without extra explanation. Add the form action, post to their endpoint, and keep the frontend focused on the page itself. That is why agencies and frontend teams still use it on static sites that need a reliable “make the form work” answer.

![Formspree](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/5e836f3c-9f3e-42f7-81d6-5b1aa0fc6bb6/free-form-processing-service-html-code.jpg)

The main strengths are stability and familiarity. Formspree has been a common choice for static site forms for a long time, so it is easy to fit into client projects that span different stacks. The trade-off is a tighter free tier than some newer tools, so if you need more storage, more branding control, or team features, you will probably pay sooner. If you are comparing hosted endpoints, the practical difference is what happens after the email: how much of the inbox, export, and routing layer you get before you hit a paid tier. The [Static Forms feature docs](https://www.staticforms.dev/docs/forms/overview) are the reference point for that side of the comparison.

### Where it fits best

- **Client work:** Good when you need something widely understood and easy to hand off.
- **Static sites:** Works with almost any builder because the workflow is just a form post.
- **Simple lead capture:** Fine when email notification and basic filtering are enough.

If your priority is predictable behavior, Formspree makes sense. It does feel conservative, though, and that matters if you want more routing logic or heavier workflow automation without adding more tooling around the form. I would choose it for projects where reducing risk matters more than getting fancy with integrations.

## 3. Basin

Basin makes sense when you want a developer-first form backend without turning the form layer into an app platform. It supports HTML forms and AJAX, which gives you a clean path from a plain contact page to client-side submission handling later. The tone of the product is practical, not flashy, and that's usually a good sign for this category.

The best thing about Basin is how it treats abuse handling and overages. Instead of pretending every form can stay inside a tiny free plan forever, it leans into transparent usage behavior. That's useful when you'd rather keep submissions flowing than discover the hard way that a form stopped accepting leads.

### What I'd watch for

> If a form is tied to sales or support, a silent stop is worse than an obvious overage.

Basin's spam controls include honeypots, filters, Turnstile, and reCAPTCHA, so it's better suited to real traffic than toy endpoints. It also supports webhooks, Zapier, and CSV export, which makes it fit nicely in the “send it somewhere useful” category instead of “collect it and hope someone checks email.”

For teams that care about deliverability, Basin is a credible option. The free plan is small, though, so I'd treat it as a test bed or a low-volume starting point rather than a forever tier.

## 4. Getform

A form that feeds both submissions and basic email workflows can save a lot of glue code. Getform is built for that middle ground. It handles hosted forms and embedded forms, so a developer can keep the front end simple while still giving a teammate a dashboard they can use without touching the repo.

That convenience has a trade-off. Once you start mixing contact capture with broadcasts, automations, and segments, the product starts to look like a small marketing stack instead of a plain submission endpoint. If your only job is to move form data into an inbox, webhook, or spreadsheet, the extra surface area can feel heavy.

![Getform](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/e3ada914-e5f5-4b18-bdd8-23a523c6f61a/free-form-processing-service-getform-homepage.jpg)

### Where it helps

- **Hosted mini-pages:** Handy when you need a public form live quickly and do not want to build a separate front-end page first.
- **Basic automation:** Webhooks, Zapier, Sheets, and CRM hooks cover the usual ways to hand submissions off to other tools.
- **Marketing-light setups:** If the form sits inside a simple lead-capture flow, the email features can remove a few manual steps.

The plan limits matter because forms stop when you hit them. That makes Getform a better fit for a workflow you can monitor than for something you expect to forget about after launch. If your team wants form capture plus lightweight marketing logic in one UI, it does the job without making you build the plumbing yourself.

## 5. Web3Forms

Web3Forms is the right kind of minimal if you want a fast static-site workflow and don't need an entire operations stack around the form. It gives you a direct form API, email delivery, and anti-spam controls (webhooks need a paid plan) without forcing a heavy dashboard into your day. For brochure sites and portfolio pages, that's often enough.

The product also stands out because it doesn't hide its free limits behind vague marketing language. That helps when you're deciding whether a side project is staying tiny or might grow into a real lead source.

### Good fit and bad fit

> Good fit, small public sites that need email delivery and simple routing.
>
> Bad fit, teams that know they'll need a broad integrations layer immediately.

I'd reach for Web3Forms when I care more about getting to a working endpoint than building a polished workflow system. If the project later needs richer routing or stronger operational controls, that's the point where I'd reevaluate. The tool is light by design, and that restraint is exactly why some developers like it.

## 6. Formcarry

Formcarry is a straightforward form API for developers who want endpoints, email notifications, file uploads, and integrations without much ceremony. The appeal is the low friction. You point a form at the service, and it behaves the way a hosted backend should.

The free plan is minimal, though, so I wouldn't choose it for anything that needs breathing room. It's better when you want a simple path into AJAX submissions, or when you're handing a build to someone who just needs a sensible default. Domain restriction controls and the option to use your own email server are nice extras at lower tiers.

![Formcarry](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/a0f67304-3116-4a50-93d4-abeb0277711a/free-form-processing-service-formcarry-landing-page.jpg)

### My take

Formcarry works best when the form is important enough to deserve a real backend, but not so complex that you need a full workflow platform. That middle ground is valuable. The moment you need serious branching logic or a broader integration map, you'll want to compare it against heavier tools instead of stretching the free tier.

## 7. Formspark

Formspark fits projects where form volume is uneven and a monthly bill feels out of proportion to the actual usage. A launch page, a hiring page, or a seasonal campaign can sit idle for long stretches, then spike for a short window. That bundle-based setup gives you a way to pay for the workload you expect instead of carrying recurring overhead on a form that only matters sometimes.

For developers, the practical appeal is that it stays focused on the submission path. You still get form endpoints, email notifications, spam filtering, CSV export, webhooks, and team workspaces, so the basics are covered without turning the service into a larger workflow platform. That makes it a clean fit for static sites where the job is to catch data, route it, and let the team handle the rest in their own tools.

### Use it when

- **Traffic is sporadic:** Launch pages and campaign sites can sit dormant for weeks, then need to handle a sudden burst of submissions.
- **You want a trial runway:** A free starter quota lets you test the service on a real project before committing to paid usage.
- **You prefer simple ops:** The feature set stays narrow, so there is less to configure and fewer moving parts to maintain.

For teams that want a hosted endpoint without dragging in a heavier system, Formspark is easy to justify. It is less attractive if your form needs branching logic, complex routing, or a broader automation map, because those requirements push you toward a different class of tool. If you are weighing hosted convenience against portability, the question to ask is whether the form survives a hosting change. A provider-agnostic endpoint does; a platform-native one does not.

## 8. Netlify Forms

Netlify Forms is the obvious pick if the site already lives on Netlify. You don't need to wire up an external provider, because Netlify captures the submission natively from the deployed site. That simplicity is the whole point, and for many static sites it's enough.

The lock-in is real, though. If your hosting moves later, your form handling moves with it. That's fine when you value fewer vendors and less setup, but it's a poor fit if portability matters more than convenience.

![Netlify Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/76e989c5-92b3-4133-b131-5dc1109e78f0/free-form-processing-service-netlify-homepage.jpg)

Netlify Forms is boring in the best way when your stack already centers on Netlify. If you're building on a different host, I'd rather use a dedicated form backend than drag hosting assumptions into the form layer. Static Forms works the same way on Netlify as anywhere else — the [Netlify deployment guide](https://www.staticforms.dev/docs/netlify) covers the setup if you want the host and the form layer decoupled.

## 9. FormSubmit

A developer usually reaches for FormSubmit after one decision has already been made, the form only needs to email a message somewhere. That constraint makes the setup fast: point the HTML form at the endpoint, submit, and move on without creating an account or wiring a backend.

That speed is the whole appeal, and it also defines the limits. Once you need structured storage, routing rules, audit-friendly records, or a place to attach real workflow logic, FormSubmit stops being enough. It handles the send step cleanly, but it does not try to manage the rest of the process.

For a quick implementation, this is hard to beat. The pattern is simple enough for static sites, landing pages, and one-off contact forms, and the optional file input gives you a little more flexibility without changing the integration model.

### Where FormSubmit fits

FormSubmit works well when you want the shortest path from HTML to inbox.

- **Ultra-simple contact pages:** No dashboard to learn, no extra configuration to maintain.
- **Temporary sites:** Useful when the form only needs to run for a short-lived project.
- **Proof of concept builds:** Good for validating the user flow before you commit to a fuller backend.

The trade-off is control. If the form may need moderation, retention policies, or integration hooks later, start planning for a more capable backend sooner rather than later. FormSubmit is practical for the first pass, but it is intentionally light on operational features.

## 10. HeroTofu

HeroTofu feels aimed at freelancers and small teams that want a polished dashboard without having to build one. It gives you email routing, optional encrypted submission archives, Slack and Zapier integrations, and clear submission caps. That combination makes it easy to match the plan to the client's traffic shape.

The important trade-off is that submissions pause when caps are hit. That's acceptable for some projects and risky for others, so you need to know which side you're on before launch. I like tools that make that boundary explicit, because hidden overages are worse than visible limits.

![HeroTofu](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/dab07457-9526-44a1-97ec-299f275faf28/free-form-processing-service-landing-page.jpg)

HeroTofu is a sensible fit when you want the choice between email-only handling and stored submissions. That flexibility helps agencies, because different clients want different amounts of visibility into the inbox. For a clean, bounded workflow, it's a practical option.

## Top 10 Free Form Processing Services Comparison

| Service | Key features | Integrations & delivery | Spam & compliance | Pricing & limits | Best for |
|---|---|---|---|---:|---|
| **Static Forms (Recommended)** | One-attribute setup, dashboard inbox, file uploads, AI Reply (Starter and up), redirect URLs | Email; webhooks (retries), Slack, Discord, Telegram (Starter and up); Google Sheets, Notion, Airtable, Mailchimp, Zapier, Make, n8n (Pro and up) | reCAPTCHA v2, honeypot; reCAPTCHA v3, hCaptcha, Turnstile, ALTCHA, domain restriction (Starter and up); GDPR tools, DPA, IP anonymization | Free 250 submissions every 30 days (no file uploads); Starter $6/mo or $48/yr; Pro $9/mo or $90/yr; Agency $19/mo or $192/yr; uploads 4.5MB per submission, storage 1–10GB | Frontend devs, agencies, freelancers, JAMstack sites |
| Formspree | HTML endpoints, autoresponders, team projects | Email, webhooks, optional uploads | reCAPTCHA support, spam filtering | Limited free tier; paid for branding/storage/team features | Mature choice for client work |
| Basin | HTML/AJAX endpoints, analytics, add‑ons (AI lead agent on high tiers) | Webhooks, Zapier, CSV export | Honeypot, filters, Turnstile, reCAPTCHA | Small free plan; transparent overage billing (submissions continue) | Developers needing analytics and predictable overages |
| Getform | Visual form editor, hosted mini‑pages, basic email marketing | Email, webhooks, Zapier, Sheets, CRMs | reCAPTCHA and basic filtering | Clear tiered caps; forms pause at limit | Teams wanting built‑in email tools without separate ESP |
| Web3Forms | Form API with email delivery; file uploads and autoresponders on Pro and up; CC on paid plans | Email; webhooks, Google Sheets, Slack, Discord, Telegram on paid plans | hCaptcha, honeypot; reCAPTCHA v3, Turnstile, domain restriction on paid plans | Free 250 submissions/mo; paid Starter (by application, for students, startups and non-profits), Pro and Agency & Team plans; [current pricing](https://web3forms.com/pricing) | Simple static sites that mostly need email delivery |
| Formcarry | HTML endpoints, file uploads, own SMTP option, white‑label | Webhooks, Mailchimp, Airtable, Slack, Notion | Domain restriction and basic spam controls | Minimal free plan (1 form/50 submissions); affordable starter tiers | Developers wanting SMTP/white‑label options |
| Formspark | Form endpoints, CSV export, team workspaces, one‑time bundles | Email, webhooks, CSV export | Basic spam filtering | One‑time submission bundles (no expiry); free starter quota | Low‑volume sites preferring pay‑once bundles |
| Netlify Forms | Native capture for Netlify sites (data‑netlify attribute) | Email notifications, Netlify UI, webhooks via Netlify | Built‑in spam filtering | Usage metered to Netlify plan; only available on Netlify hosting | Sites already hosted on Netlify (zero extra infra) |
| FormSubmit | Email‑first endpoint, no account required, AJAX & uploads | Direct email delivery, optional short‑term archive API | Basic anti‑spam; short archive retention | Minimal free service; archive retention limited | Ultra‑simple contact forms with no dashboard |
| HeroTofu | Polished dashboard, encrypted archives, routing controls | Email routing, Slack, Zapier integrations | Spam protection, optional encrypted storage | Generous Pro tier; free plan minimal, caps pause submissions | Freelancers and client projects needing dashboards |

## Your Next Step Ship That Form

You've got the short list, and the decision is less about “best” and more about what kind of failure you can tolerate. A **free form processing service** is only useful if it fits your deployment model, your spam exposure, and the way your team reviews submissions. For a static or JAMstack site, the right answer is often the tool that keeps the form ordinary, keeps the delivery reliable, and keeps you out of backend maintenance.

If you need a simple pattern to follow, start with the form action first, then layer in spam protection, redirects, and integrations only if the workflow demands them. That keeps you from overbuilding a contact form that just needed to exist. It also makes testing easier, because you can verify the basic POST path before you add any client-side complexity.

The comparison I'd make in practice is simple. Pick Static Forms if you want a hosted backend that starts lean but still gives you room for webhooks and small file uploads (Starter and up), storage, and GDPR controls later. Pick Formspree or Basin if maturity and predictable developer experience matter more than dashboard depth. Pick Getform, Formspark, or HeroTofu if your workflow needs a more opinionated UI or a pricing model that matches your traffic pattern. Pick Netlify Forms only when you're already committed to Netlify. Pick FormSubmit or Web3Forms when you want the lightest possible setup and can live with fewer workflow features.

The bigger point is operational. Once a form starts feeding leads, support requests, or client intake, the cost of a bad backend is usually hidden in manual cleanup, missed emails, or awkward privacy requests. That's why the best choice is rarely the one with the shortest marketing page. It's the one that still looks sensible after the first month of real traffic.

If you're trying to get a static-site form live this week, pick the backend that matches your workflow and ship it instead of parking it for later. A real contact path beats a perfect backlog item every time.

---

To start with the option at the top of this list: create a form on [Static Forms](https://www.staticforms.dev), copy the API key, and paste the endpoint into your existing markup. The [quick start](https://www.staticforms.dev/docs/quick-start) takes about two minutes, the free tier covers 250 submissions every 30 days, and you can add spam protection, webhooks (Starter and up), and [integrations](https://www.staticforms.dev/docs/integrations) later without touching the frontend again.

Need the form itself too? The free HTML form generator writes the markup, already pointed at a form backend. [Open the HTML form generator](/tools/form-generator)

---

## Connect HTML Form Google Sheets: 5 Methods for 2026

Source: https://www.staticforms.dev/blog/form-google-sheets  
Date: 2026-07-23T09:44:20.247Z  
Author: Static Forms Team

You've got a static site, a contact form, and no appetite for standing up a full backend just to catch a few submissions. The quickest path is usually a **form Google Sheets** workflow, but the right implementation depends on how much control you need over markup, spam filtering, attribution, and downstream automation.

A common mistake is choosing the first method that works, then discovering later that it's hard to customize, hard to scale, or hard to trust. A better approach is to pick from five real options, from Google's native Form-to-Sheets flow to Apps Script, the Google Sheets API, automation platforms, and managed form backends.

## Choosing Your Path to Google Sheets

A static site form doesn't need a traditional server just to get data into a spreadsheet. For many contact forms, signup forms, and internal intake flows, Google Sheets is enough of a storage layer because submissions become structured rows that your team can inspect, sort, and analyze right away through the workflow shown in Google's own Forms-to-Sheets materials, where a linked spreadsheet is created directly from the **Responses** tab and each submission lands as a row in Sheets ([Google Forms to Sheets workflow](https://www.youtube.com/watch?v=507H7UGBsaU)).

That simplicity is why the space keeps splitting into distinct paths. One team wants a no-code form that lives inside Google's ecosystem. Another wants to keep a custom frontend but avoid owning a server. A third needs programmatic control for validation, routing, and enrichment before the data ever touches the sheet.

The actual decision isn't “how do I send a form to Google Sheets.” It's “where do I want control to live.” If you want the least setup, native Google Forms is hard to beat. If you want custom HTML and lightweight backend behavior, Apps Script is the middle ground. If you already have a backend or serverless function, the Sheets API gives you direct control. If you prefer visual automation, Zapier or Make can bridge the gap. And if you want to avoid stitching together spam protection, uploads, and integrations by hand, a managed endpoint can be the cleaner operational choice.

> **Practical rule:** choose the method that matches your maintenance budget, not just your launch speed. A fast setup that becomes brittle after a few client revisions usually costs more later.

For frontend teams, the useful question is whether the form is a one-off lead capture widget or part of a real workflow. The answer changes everything.

## Method 1 The Native Google Forms Approach

![A person using a laptop to create a customer feedback form using Google Forms software.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/7309863f-4d1a-4b08-9d09-483292b0e4d0/form-google-sheets-google-forms.jpg)

A team that needs data in Sheets fast, and does not care about owning the frontend, can start with Google Forms. Build the form in Google's interface, define the fields, then open the **Responses** tab and connect a spreadsheet, either new or existing. Google's workflow supports creating that linked spreadsheet directly, so each submission lands as a structured row you can inspect in Sheets right away ([Google Forms to Sheets workflow](https://www.youtube.com/watch?v=507H7UGBsaU)).

### What this gets right

For internal surveys, simple intake forms, and team-only workflows, the setup is hard to beat. There is no hosting to manage, no backend code to maintain, and no request handler to debug. The sheet becomes the source of truth, and the form writes into it directly.

That matters because Sheets already handles the kind of quick analysis people do on form data. The Forms and Sheets workflow supports charts, pivot tables, and formula-based summaries, along with common statistical operations such as **MIN**, **MAX**, range, frequency counts, and standard deviation for distribution and spread analysis.

### Where it breaks down for developers

Control is the trade-off. Google Forms gives you limited HTML structure, limited styling, and very little room for custom behavior. If you need the form on your own domain, you usually have to embed it in an iframe, which makes branding and UX harder to control. Redirects to a custom thank-you page are also clumsy compared with a form you own end to end.

That makes Google Forms a good default for non-technical workflows, but a weak fit for static-site projects that need a polished interface, custom validation, or source attribution. If you are building for a client, revision requests tend to arrive quickly, and Google Forms resists those changes instead of fitting them. If you want a cleaner handoff for a custom frontend, the pattern described in this guide to [create an HTML form that posts to Sheets](https://www.staticforms.dev/blog/create-an-html-form) shows why many teams move past the native option.

Google Forms works best when the form itself does not matter much, only the data does.

## Method 2 Custom HTML Form with Google Apps Script

![A three-step workflow diagram showing how to design a custom HTML form with Google Apps Script.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/a6ea5ef4-6f25-4923-8b03-286e3ec89d40/form-google-sheets-apps-script-workflow.jpg)

If you want to keep your own HTML and still avoid running a server, Apps Script is the most practical middle ground. The pattern is straightforward. Your site posts to a deployed Apps Script web app, the script parses the request, and then appends a row to the target sheet.

A common source of friction is matching the sheet structure to the payload. The backend implementation works best when you create the destination sheet first, lock the header row, and make sure each form field name maps exactly to a column title. The reference implementation also expects a `doPost` web app with authorization in place before production traffic, and it recommends a smoke test from multiple devices with rows appearing in under 60 seconds ([Apps Script form backend README](https://github.com/jamiewilson/form-to-google-sheets/blob/master/README.md)).

### Copy-pasteable HTML form

```html
<form
  action="https://script.google.com/macros/s/YOUR_DEPLOYMENT_ID/exec"
  method="POST"
>
  <label>
    Name
    <input type="text" name="name" required />
  </label>

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

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

### Apps Script `doPost` example

```javascript
const SHEET_NAME = 'Responses';

function doPost(e) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(SHEET_NAME);
  const data = e.parameter;

  sheet.appendRow([
    new Date(),
    data.name || '',
    data.email || '',
    data.message || ''
  ]);

  return ContentService
    .createTextOutput(JSON.stringify({ ok: true }))
    .setMimeType(ContentService.MimeType.JSON);
}
```

### Deployment steps that actually matter

1. **Create the sheet first.** Put your column headers in row one and keep them stable.
2. **Open Extensions > Apps Script.** Paste the script and save it.
3. **Deploy as a web app.** Use the web app deployment flow, authorize it, and copy the URL.
4. **Point the form action at the deployed URL.** Don't use a placeholder in production.
5. **Test submissions from different devices.** If rows don't appear quickly, fix the deployment before launch.

> **Practical rule:** treat the sheet like a database table, not like a loose note pad. Once you start mixing headers, manual edits, and ad hoc columns, your form payloads get messy fast.

This is also the point where a custom frontend becomes valuable. If you're already using React, Next.js, or Vue, the form can look native to the site while still posting to a Sheet through Apps Script. For a plain HTML foundation, the structure is simple, and if you want a broader front-end walkthrough, this [guide to building an HTML form](https://www.staticforms.dev/blog/create-an-html-form) is a useful reference point.

The trade-off is that Apps Script still asks you to own more than people expect. You're responsible for deployment, permissions, field mapping, and any future schema changes. If your form is going to evolve often, that maintenance can become the hidden cost.

## Method 3 Programmatic Control with the Google Sheets API

When the form submit path already runs through your own backend or serverless function, the Google Sheets API is the most direct option. It's more work upfront, but it gives you explicit control over authentication, data shaping, retries, and validation before anything reaches the spreadsheet. The surface you'll be calling is `spreadsheets.values.append`, documented in the [Sheets API reference](https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values/append).

### What the setup looks like

The usual flow is to create a Google Cloud project, enable the Sheets API, and generate a service account with JSON credentials. Then you share the target spreadsheet with that service account's email address so it can write rows as an editor. From there, a backend function can authenticate and append rows programmatically.

That setup is better than Apps Script when the form lives in a broader system. You can validate input, enrich it, and decide what gets written to Sheets at all. It also solves a recurring gap in the simpler workflows: attribution metadata. Native [Google Forms](https://support.google.com/docs/answer/6281888) can only carry campaign or referrer data through prefilled link tricks, whereas a programmatic handler can read `document.referrer` and UTM parameters from your own page and write them as real columns.

### Node.js example for appending a row

```javascript
import { google } from 'googleapis';

const auth = new google.auth.GoogleAuth({
  credentials: JSON.parse(process.env.GOOGLE_SERVICE_ACCOUNT_JSON),
  scopes: ['https://www.googleapis.com/auth/spreadsheets']
});

async function appendFormRow({ name, email, message, source }) {
  const client = await auth.getClient();
  const sheets = google.sheets({ version: 'v4', auth: client });

  await sheets.spreadsheets.values.append({
    spreadsheetId: process.env.SHEET_ID,
    range: 'Responses!A:D',
    valueInputOption: 'RAW',
    requestBody: {
      values: [[new Date().toISOString(), name, email, message, source]]
    }
  });
}
```

### When this is the right call

Use the API when the spreadsheet is one destination among several. A single submission might need validation, tagging, deduplication, and then writes to Sheets plus another system. The Sheets API fits that model better than trying to force everything through a form endpoint.

It's also the cleanest choice when your team already has a backend service. In that case, Sheets is just another integration target, and the form is only the first step in a broader workflow. The cost is complexity, not just in setup but in long-term maintenance of credentials and request handling.

For a more opinionated implementation path, the [Static Forms Google Sheets integration docs](https://www.staticforms.dev/docs/integrations/google-sheets) (a Pro plan feature) are useful if you're comparing backend-first patterns with managed form endpoints — same destination, no service-account credentials to rotate.

## Method 4 No-Code Automation with Zapier or Make

![A hand using a laptop to create an automated workflow connecting an HTML form to Google Sheets.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/f7b08962-884b-4cb9-8410-68f28b171642/form-google-sheets-automation-workflow.jpg)

Zapier and Make sit between code and pure no-code. You keep a custom HTML form, while the backend flow stays visual. The form posts to a webhook URL, the automation tool receives the payload, and a spreadsheet action writes the row into Google Sheets. That setup fits teams that want a fast path to a working form without deploying Apps Script or managing API credentials directly.

The trade-off is control. You gain speed and a clearer setup path, but you also accept another service in the middle of the submission flow. For small lead forms, that is usually fine. For stricter systems, the extra hop can matter.

Google Sheets becomes more useful once the data lands there. Pivot tables with date grouping let you summarize submission timestamps by day, so the sheet works as an operational reporting layer instead of a dead-end inbox.

### How the workflow is usually wired

- **Create the webhook trigger:** Build a Zap or Scenario that listens for POST requests at a unique URL.
- **Point the form action there:** Your HTML form posts directly to that webhook endpoint.
- **Map fields to columns:** Match names like `name`, `email`, and `message` to the target sheet.
- **Add follow-up steps if needed:** Slack alerts, CRM updates, and email notifications can happen after the row is created.

That flexibility is why teams pick these tools. They can do more than write a row, and they are easier to adjust than custom code when a client asks for one extra step in the workflow.

### Where the compromise shows up

Cost and latency are the main downsides. You depend on a third-party workflow engine, so the result is not as immediate or deterministic as posting straight to the Sheets API. For many lead forms, that is acceptable. For a time-sensitive internal workflow, it can be a poor fit.

A managed integration can be simpler than spreading the logic across separate tools. Static Forms, for example, can send submissions to Google Sheets as one of its destinations on Pro and up, which matters if you want a managed endpoint rather than a custom webhook stack. If you are already using Zapier, the [Zapier integration overview](https://www.staticforms.dev/integrations/zapier) helps compare how those pieces fit together.

## Comparing Methods and Handling Advanced Features

The cleanest way to choose is by control, maintenance, and how much of the workflow you want to own. Native Google Forms is the quickest path, but it gives you the least front-end control. Apps Script gives you a free serverless bridge with enough flexibility for many static sites. The Sheets API gives you full programmatic control, which matters when the form is only one part of a larger system. Zapier or Make reduce coding, but they add a recurring dependency and another place for failures. Managed endpoints like Static Forms sit in the middle when you want one place to handle submission routing, Google Sheets delivery (Pro and up on Static Forms), and other integrations without building the plumbing yourself.

| Method | Setup Complexity | Cost | Frontend Control | Key Feature |
| --- | --- | --- | --- | --- |
| Native Google Forms | Low | Low | Low | Fastest path to a linked sheet |
| Google Apps Script | Medium | Low | High | Custom HTML form with a script backend |
| No-Code Automation | Medium | Recurring | High | Visual workflow with extra actions |
| Google Sheets API | High | Low to variable | High | Full programmatic control |
| Managed form backend | Low | Low to recurring | High | One endpoint, Sheets plus other destinations |

The production problems usually show up after the first row lands in Sheets. Reliability, duplicate handling, and column consistency matter once the sheet starts acting like a lightweight CRM or lead pipeline. A lot of setup guides stop at append logic and leave out the parts that keep data usable over time: what happens when a submission arrives while someone has the sheet open in edit mode, what happens when a column gets reordered, and what happens when the write fails and nobody retries it.

### Advanced features that change the architecture

**Spam protection** should be planned before launch, not bolted on later. An Apps Script `doPost` endpoint or a raw webhook URL has none, so a scraped form action becomes a spam firehose straight into your spreadsheet. reCAPTCHA and Turnstile are the common challenge options, and [honeypot fields](https://www.staticforms.dev/docs/forms/security/honeypot) work well when you want a low-friction signal without forcing every visitor through a challenge.

**File uploads** should usually not go straight into the sheet. A safer pattern is to upload the file to Google Drive or S3 first, then store the file URL in Sheets. That keeps the spreadsheet from turning into file storage and makes the workflow easier to audit.

**Privacy and compliance** matter too. If you're collecting personal data, you need to handle consent, retention, export, and deletion. A form backend should support those needs without turning them into a spreadsheet cleanup job.

### Practical trade-offs by use case

- **Simple contact form:** Native Google Forms works if branding does not matter.
- **Custom marketing site:** Apps Script or a managed backend fits better because you control the markup.
- **Lead routing and enrichment:** The Sheets API or automation tools are better when submissions need to branch.
- **Client handoff:** Managed endpoints reduce maintenance when a site owner does not want to touch code.

For teams that want a single endpoint with spam filtering, file uploads up to **4.5MB per submission** (every file plus the other fields), Google Sheets delivery, and other routing options, a managed form backend is often easier to maintain than stitching together scripts and webhooks. On Static Forms, uploads need Starter or above and Google Sheets delivery needs Pro or above. That helps when the same form has to send data to multiple destinations without changing the frontend each time.

> **Practical rule:** if your form needs uploads, attribution, and retry behavior, stop thinking of it as “just a form” and start treating it like a small ingestion system.

If you want to move faster on a static site without building and maintaining the full submission stack yourself, [Static Forms](https://www.staticforms.dev) posts plain HTML to a single endpoint and emails each submission; paid plans also forward it to Slack or a webhook (Starter and up) or Google Sheets (Pro and up). The [quick start](https://www.staticforms.dev/docs/quick-start) is one `action` attribute and a hidden API key — no Apps Script deployment, no service account, no spreadsheet permissions to babysit.

---

## Web3Forms vs Static Forms (2026): Limits, Prices, Trade-offs

Source: https://www.staticforms.dev/blog/web3forms-vs-static-forms-comparison  
Date: 2026-07-05  
Author: Static Forms Team

Web3Forms and Static Forms do the same job. You point an HTML form at an endpoint, add a key, and submissions arrive in your inbox without a server of your own. Both free plans give you 250 submissions: a month on Web3Forms, every 30 days on Static Forms. The real differences are how many forms you get for free, what the first paid plan includes, and what happens to your data afterwards.

We make Static Forms, so read this as our side of the comparison. Web3Forms plan limits and features below come from its pricing page (web3forms.com/pricing), checked on 26 October 2026; the security and privacy answers come from its documentation FAQ (docs.web3forms.com). We don't quote Web3Forms prices, because its pricing page and its llms.txt summary listed different prices that day. Check web3forms.com/pricing for the current figure. Static Forms prices are in US dollars.

> **Looking for a Web3Forms alternative instead?** The [Web3Forms alternative page](/alternatives/web3forms) is the short version, with the plans side by side. This post is the detailed head-to-head.

## Quick Comparison Overview

Checked 26 October 2026. Web3Forms facts come from web3forms.com/pricing; Static Forms facts from our [pricing page](/pricing) and docs.

| | Web3Forms | Static Forms |
|---|---|---|
| **Free submissions** | 250/month | 250 every 30 days |
| **Forms on Free** | Unlimited forms and domains | 1 form |
| **Cheapest paid plan** | Starter, yearly only, by application (students, early startups, non-profits): 5,000/month | Starter, $6/month or $48/year: 3,000/month, unlimited forms |
| **Cheapest plan open to anyone** | Pro: 10,000/month | Starter, $6/month or $48/year: 3,000/month |
| **Next plan up** | Agency: 20,000/month | Pro, $9/month or $90/year: 25,000/month |
| **File uploads** | Pro and above (5 GB on Pro) | Starter and up (1 GB on Starter, 5 GB on Pro) |
| **Autoresponder** | Pro and above | Starter and up |
| **Spam protection on Free** | hCaptcha and honeypot | reCAPTCHA v2, honeypot and spam filter |
| **reCAPTCHA v3 and Turnstile** | Paid plans only | Starter and up (with hCaptcha and ALTCHA) |
| **Webhooks** | Paid plans only | Starter and up |
| **Submission history** | 30 days Free, 3 months Starter, 1 year Pro and Agency | Last 30 days visible on Free, unlimited on paid plans |
| **At the plan limit** | Stops accepting submissions until the next month | Free and Starter stop accepting; Pro and Agency can opt in to overage at $1 per 1,000 |

![Table comparing Web3Forms and Static Forms: both free plans allow 250 submissions, per month on Web3Forms and every 30 days on Static Forms, Web3Forms allows unlimited free forms against one on Static Forms, and file uploads start on Web3Forms Pro and Static Forms Starter](/blog/web3forms-vs-static-forms-comparison-infographic.png)

## Pick Web3Forms if, pick Static Forms if

**Pick Web3Forms if:**
- You run several small sites and want each one on a free plan. Web3Forms Free allows unlimited forms and domains; Static Forms Free allows one form.
- You qualify for its Starter plan. It allows 5,000 submissions a month, more than our Starter's 3,000, as long as you don't need file uploads or autoresponders.
- You want hCaptcha on a free plan. On Static Forms, hCaptcha is Starter and up.

**Pick Static Forms if:**
- You need file uploads or autoresponders and don't want to move up to Web3Forms Pro. Both start on our Starter plan ($48/year).
- You send more than 20,000 submissions a month. Web3Forms' largest listed plan, Agency, stops at 20,000; our Pro covers 25,000 for $90/year and our Agency 30,000.
- You want submissions kept in a searchable inbox for as long as you're on a paid plan, not 3 months or a year.
- You want a CAPTCHA that doesn't call a third party. [ALTCHA](/blog/implementing-altcha-captcha-html-website) runs without one (Starter and up; no tracking, no cookies).

## When Web3Forms is the better choice

Switching only makes sense if you're running into one of the limits above. Stay where you are if:

- **Your free setup already works.** If a handful of sites send fewer than 250 submissions a month between them, Web3Forms Free covers you, and Static Forms Free (250 every 30 days) would cover only one of those forms.
- **You're on the Starter discount.** Its Starter gives 5,000 submissions a month at a discounted yearly price. Moving to us would get you 3,000 a month on Starter, or 25,000 on Pro for $90/year.
- **You only need email.** If nobody on your team needs uploads, an autoresponder or an integration, the paid features we'd point to don't matter to you.
- **Changing forms has a cost.** Every form you move needs its action URL and key changed and a test submission. On a large client portfolio, that's real work for no gain if the current setup isn't hurting.

## Pricing Breakdown

### Web3Forms plans (from web3forms.com/pricing, 26 Oct 2026)

We've left out Web3Forms prices: its pricing page and its llms.txt listed different figures that day. Check web3forms.com/pricing for the current price.

- **Free:** 250 submissions a month, unlimited forms and domains, hCaptcha, honeypot, custom redirect, 30-day submission history.
- **Starter (yearly only, by application):** for students, early startups and non-profits. 5,000 submissions a month, 3-month history. No file uploads and no autoresponders.
- **Pro:** 10,000 submissions a month, file uploads with 5 GB of storage, autoresponders, the Submissions API, up to 5 active integrations, 1-year history, 3 team seats.
- **Agency:** 20,000 submissions a month, 10 GB of storage, 10 seats, 20 linked email addresses, dedicated support.

### Static Forms pricing

- **Free, $0:** 250 submissions every 30 days, 1 form, reCAPTCHA v2, honeypot, spam filter. The Inbox shows the last 30 days.
- **Starter plan, $6/month or $48/year:** 3,000 submissions a month, unlimited forms, file uploads (1 GB stored), webhooks, Slack, Telegram and Discord, autoresponders, AI Reply, every CAPTCHA option, domain restriction. Stops at 3,000 a month; no overage charges.
- **Pro plan, $9/month or $90/year:** 25,000 submissions a month, 5 GB of storage, Google Sheets, Notion, Airtable and Mailchimp, form rules, a custom sending domain, CC recipients, branding removal, up to 3 team members. Overage is optional and off by default: $1 per 1,000 extra submissions.
- **Agency, $19/month or $192/year:** 30,000 submissions a month, 10 GB of storage, unlimited team members, same opt-in overage.

Full details are on the [pricing page](/pricing).

### Which plan covers your volume

Plan limits as listed on each product's pricing page on 26 October 2026. Static Forms prices are yearly; for Web3Forms prices, see its pricing page.

| Submissions per month | Web3Forms plan | Static Forms plan |
|---|---|---|
| Up to 250 | Free | Free (1 form, 250 every 30 days) |
| 251 to 3,000 | Starter (if eligible), otherwise Pro | Starter, $48/year |
| 3,001 to 5,000 | Starter (if eligible), otherwise Pro | Pro, $90/year |
| 5,001 to 10,000 | Pro | Pro, $90/year |
| 10,001 to 20,000 | Agency | Pro, $90/year |
| 20,001 to 25,000 | Above Agency; not listed | Pro, $90/year |
| 25,001 to 30,000 | Above Agency; not listed | Agency, $192/year |

If you need uploads or autoresponders, ignore the Web3Forms Starter rows: those features start on its Pro plan.

## Setup and Implementation

Both use the same model: a public key in a hidden field, posted to one endpoint.

### Web3Forms

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Contact</title>
</head>
<body>
  <form action="https://api.web3forms.com/submit" method="POST">
    <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
    <label>Email <input type="email" name="email" required></label>
    <label>Message <textarea name="message" required></textarea></label>
    <button type="submit">Send</button>
  </form>
</body>
</html>
```

### Static Forms

Create a free account, copy your `apiKey` from the dashboard, and post to `https://api.staticforms.dev/submit`:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Contact</title>
</head>
<body>
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY">
    <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you">
    <label>Email <input type="email" name="email" required></label>
    <label>Message <textarea name="message" required></textarea></label>
    <button type="submit">Send</button>
  </form>
</body>
</html>
```

To submit with JavaScript instead of a page load, send JSON:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Contact</title>
</head>
<body>
  <form id="contact">
    <label>Email <input type="email" name="email" required></label>
    <label>Message <textarea name="message" required></textarea></label>
    <button type="submit">Send</button>
    <p id="status" role="status"></p>
  </form>
  <script>
    const form = document.getElementById('contact');
    const status = document.getElementById('status');

    form.addEventListener('submit', async (event) => {
      event.preventDefault();
      const data = Object.fromEntries(new FormData(form));
      try {
        const res = await fetch('https://api.staticforms.dev/submit', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ ...data, apiKey: 'YOUR_API_KEY' }),
        });
        status.textContent = res.ok ? 'Thanks, message sent.' : 'Something went wrong. Please try again.';
        if (res.ok) form.reset();
      } catch {
        status.textContent = 'Network error. Please try again.';
      }
    });
  </script>
</body>
</html>
```

Every parameter is listed in the [API reference](/docs/api-reference). If you'd rather not write markup, the [HTML form generator](/tools/form-generator) builds a form in plain HTML, React or Next.js.

## Is Web3Forms safe?

Web3Forms' FAQ answers the two questions you're probably asking.

**Is the public access key a risk?** Web3Forms says the key is public, stores no sensitive data, and that someone who copies it "can only send you emails". The practical risk is spam. Its FAQ points to CAPTCHAs and its domain restriction, which is a paid feature.

Static Forms works the same way: the `apiKey` sits in your HTML. Domain restriction is Starter and up, and reCAPTCHA v2 and the honeypot work on Free.

**Where does the data go?** The FAQ says its servers are in the US-East region. On GDPR, it says the company is confident it complies but "cannot make any legal statements".

## Data retention: what Web3Forms says, and where it disagrees with itself

This is the part of the comparison that took the longest to pin down, because Web3Forms' pages don't agree with each other:

- Its **pricing page** lists submission *history* by plan: 30 days on Free, 3 months on Starter, 1 year on Pro and Agency.
- The same page lists a *data retention policy* of up to 3 years on Free and Starter, and unlimited on Pro and Agency.
- Its **documentation FAQ** says: "We do not store any form submissions of our users."

We read the FAQ line as out of date, but that's our reading, not theirs. If retention matters for compliance, ask Web3Forms which statement applies to your plan.

Static Forms separates the two ideas in the product. *History* is how far back the Inbox shows: the last 30 days on Free, everything on paid plans. *Retention* is how long a submission is stored: up to one year on Free, and unlimited by default on paid plans, with an optional shorter period per form (from 30 days to 5 years).

## Spam Protection

**Web3Forms:** Free includes hCaptcha and a honeypot. reCAPTCHA v3 and Cloudflare Turnstile are on paid plans only.

**Static Forms:** every plan gets the honeypot, reCAPTCHA v2 and a [spam filter](/docs/forms/spam-filter) that moves flagged submissions to a Spam tab instead of deleting them. Each form chooses the AI filter or a classic reputation filter. Turnstile, hCaptcha, ALTCHA and reCAPTCHA v3 are Starter and up. The [security docs](/docs/forms/security) cover each option.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Contact</title>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>
<body>
  <!-- reCAPTCHA v2 works on the Static Forms Free plan -->
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY">
    <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">
    <label>Email <input type="email" name="email" required></label>
    <label>Message <textarea name="message" required></textarea></label>
    <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>
    <button type="submit">Send</button>
  </form>
</body>
</html>
```

## Feature Comparison

### File Uploads

Web3Forms uploads start on Pro, with 5 GB of file storage (10 GB on Agency).

Static Forms uploads are Starter and up. The limit is 4.5 MB per submission in total, across all files and fields, as the [file upload docs](/docs/forms/file-uploads) explain.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Send a file</title>
</head>
<body>
  <form action="https://api.staticforms.dev/submit" method="POST" enctype="multipart/form-data">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY">
    <label>Email <input type="email" name="email" required></label>
    <label>File <input type="file" name="attachment" accept=".pdf,.doc,.docx,.jpg,.png"></label>
    <button type="submit">Upload</button>
  </form>
</body>
</html>
```

### Webhooks and Integrations

Web3Forms lists Google Sheets, Slack, Discord, Telegram and webhooks, on paid plans only; the number of active integrations rises with the plan.

Static Forms webhooks are Starter and up, along with Slack, Telegram and Discord. Google Sheets is Pro and up, and so are Notion, Airtable and Mailchimp. Zapier, Make and n8n are Pro and up.

### Notifications and Replies

Both send each submission to your inbox. Web3Forms autoresponders start on Pro; CC and multiple recipients are on paid plans only.

On Static Forms, autoresponders are Starter and up, CC recipients are Pro and up, and a custom sending domain lets you send from your own domain (Pro and up). [AI Reply](/docs/forms/ai-reply) drafts a reply from a knowledge base you upload and runs on prepaid credits (Starter and up). Web3Forms' pages don't list an AI reply feature.

### Redirects

Web3Forms uses a `redirect` field. Static Forms uses `redirectTo`.

## Migrating From Web3Forms to Static Forms

If you're already on Web3Forms, your HTML structure stays the same:

**1. Update the form action:**
```html
<!-- Before --> <form action="https://api.web3forms.com/submit">
<!-- After -->  <form action="https://api.staticforms.dev/submit">
```

**2. Swap the key field:**
```html
<!-- Before --> <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
<!-- After -->  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
```

**3. Rename fields if needed:** `redirect` becomes `redirectTo`.

**4. Check spam protection:** rename Web3Forms' `botcheck` honeypot field to `honeypot`. hCaptcha needs Static Forms Starter or above; on Free, use reCAPTCHA v2.

## Which Should You Choose?

The two lists near the top have the detail. In short, Web3Forms is the better fit for many small free forms, or for 5,000 email-only submissions a month on its discounted Starter. Static Forms is the better fit when you need uploads or autoresponders on the $48/year Starter plan, more than 20,000 submissions a month, or submission history that doesn't expire on a paid plan.

To try it, [create a free Static Forms account](https://www.staticforms.dev) and send a test submission to your one free form. The [pricing page](/pricing) has every plan limit.

Comparing services with similar names? [Static Forms vs StaticForm](/alternatives/staticform) covers StaticForm (staticform.app), a separate form backend that's easy to confuse with us.

More guides:
- [HTML form to email without a server](/blog/html-form-send-email-without-server)
- [React contact form tutorial](/blog/react-contact-form-email-tutorial)
- [Next.js tutorial](/blog/using-staticforms-with-nextjs)

---

## Create WordPress Form Without Plugin: Native PHP & External

Source: https://www.staticforms.dev/blog/wordpress-form-without-plugin  
Date: 2026-06-26T09:59:13.753Z  
Author: Static Forms Team

You need a form on a WordPress site, but you don't want another plugin adding its own UI, CSS, database tables, and update cycle. That's a reasonable instinct. A **WordPress form without plugin** is possible, but it usually means choosing between two very different architectures instead of avoiding installation.

One path keeps everything inside WordPress with PHP and core hooks. The other sends submissions to an external form endpoint, which is closer to how JAMstack teams already handle forms on static sites. Both work. The wrong choice is assuming “no plugin” means “just paste HTML and you're done.”

## Why Build a WordPress Form Without a Plugin

Most developers who search for a WordPress form without plugin are trying to avoid one of three things. Extra plugin overhead, plugin lock-in, or a visual builder that fights the rest of the stack.

There's also a real privacy and architecture concern behind the search. Many guides skip the native implementation entirely and jump straight to embedded third-party builders. That leaves a gap for developers who want a **self-contained HTML form with server-side handling**, especially when data ownership matters.

### The two real no-plugin options

The practical choices are:

- **Native WordPress PHP handling:** Your form posts to WordPress, usually through `admin-post.php`, and your own PHP callback sanitizes, validates, stores, emails, and redirects.
- **External endpoint handling:** Your form still lives in WordPress, but submissions go to a hosted backend endpoint instead of your theme or plugin code.

Those options solve different problems.

The native route gives you full control over every field, every handler, and every side effect. It also gives you responsibility for validation, spam controls, mail delivery, redirects, storage, and long-term maintenance.

The external endpoint route keeps your frontend simple. If you're already comfortable with HTML, React, Next.js, or Vue, it feels natural because the form becomes just another POST request.

> **Practical rule:** “Without a plugin” doesn't mean “without backend logic.” It means you're choosing where that logic lives.

If you're still deciding whether avoiding plugins is worth the effort, it helps to compare plugin-based tradeoffs too. This roundup of the [best contact form options for WordPress](https://www.staticforms.dev/blog/best-contact-form-for-wordpress) is useful because it frames the decision from a maintenance angle rather than pretending one pattern fits every project.

## Method 1 The Native PHP Way Using admin-post.php

The native approach is the closest thing to a “pure” WordPress form without plugin. It's also the one people underestimate most. You're not just writing HTML. You're wiring a submission flow into WordPress itself.

Creating a WordPress form without a plugin via the native method requires using `admin-post.php` as the endpoint, registering custom action hooks like `admin_post_nopriv_contact_form`, and writing a handler function to sanitize data and interact with the database using the `$wpdb` class. As described in [this walkthrough of native WordPress form submission](https://dev.to/readymadecode/submit-a-form-in-wordpress-without-plugin-33mb), it's a **multi-file PHP process** and not a simple HTML task.

![A step-by-step infographic illustrating how to handle WordPress forms natively using admin-post.php for custom development.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/c2f42712-052f-4b6b-9179-0716b2346f20/wordpress-form-without-plugin-form-handling.jpg)

### Build the page template

Create a custom page template in your theme, for example `page-contact-native.php`.

```php
<?php
/*
Template Name: Native Contact Form
*/
get_header();
?>

<main class="contact-page">
  <h1>Contact</h1>

  <?php if (isset($_GET['status']) && $_GET['status'] === 'success') : ?>
    <p class="form-success">Thanks. Your message has been sent.</p>
  <?php endif; ?>

  <?php if (isset($_GET['status']) && $_GET['status'] === 'error') : ?>
    <p class="form-error">There was a problem with your submission.</p>
  <?php endif; ?>

  <form action="<?php echo esc_url(admin_url('admin-post.php')); ?>" method="post">
    <input type="hidden" name="action" value="contact_form">
    <?php wp_nonce_field('contact_form_nonce_action', 'contact_form_nonce'); ?>

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

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

    <p>
      <label for="website">Website</label>
      <input id="website" name="website" type="url">
    </p>

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

    <p class="hidden-field" style="display:none;">
      <label for="company">Company</label>
      <input id="company" name="company" type="text" autocomplete="off">
    </p>

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

<?php get_footer(); ?>
```

This form does four important things:

1. Posts to `admin-post.php`
2. Sets an `action` value WordPress can route
3. Includes a nonce for CSRF protection
4. Adds a honeypot field for basic bot filtering

### Add the handler in functions.php

Now wire the submission handler into WordPress.

```php
<?php
add_action('admin_post_nopriv_contact_form', 'mytheme_handle_contact_form');
add_action('admin_post_contact_form', 'mytheme_handle_contact_form');

function mytheme_handle_contact_form() {
    if (
        !isset($_POST['contact_form_nonce']) ||
        !wp_verify_nonce($_POST['contact_form_nonce'], 'contact_form_nonce_action')
    ) {
        wp_die('Invalid form submission.');
    }

    if (!empty($_POST['company'])) {
        wp_redirect(home_url('/contact/?status=success'));
        exit;
    }

    $name = isset($_POST['name']) ? sanitize_text_field($_POST['name']) : '';
    $email = isset($_POST['email']) ? sanitize_email($_POST['email']) : '';
    $website = isset($_POST['website']) ? esc_url_raw($_POST['website']) : '';
    $message = isset($_POST['message']) ? sanitize_textarea_field($_POST['message']) : '';

    $errors = [];

    if (empty($name)) {
        $errors[] = 'Name is required.';
    }

    if (empty($email) || !is_email($email)) {
        $errors[] = 'A valid email is required.';
    }

    if (empty($message)) {
        $errors[] = 'Message is required.';
    }

    if (!empty($errors)) {
        wp_redirect(home_url('/contact/?status=error'));
        exit;
    }

    $admin_email = get_option('admin_email');
    $subject = 'New contact form message from ' . $name;

    $body = "Name: {$name}\n";
    $body .= "Email: {$email}\n";
    $body .= "Website: {$website}\n\n";
    $body .= "Message:\n{$message}\n";

    $headers = [
        'Reply-To: ' . $name . ' <' . $email . '>',
        'Content-Type: text/plain; charset=UTF-8',
    ];

    wp_mail($admin_email, $subject, $body, $headers);

    wp_redirect(home_url('/contact/?status=success'));
    exit;
}
```

That's enough for a working contact form. It handles logged-in and logged-out users, sanitizes fields, validates required input, sends mail with `wp_mail()`, and redirects on completion.

> Keep the form handler small. Once validation, spam checks, file uploads, persistence, and integrations all land in one callback, `functions.php` turns into an unreviewable mess.

### Store submissions in a custom table

If email isn't enough, add database persistence. The native pattern commonly uses `$wpdb` with a custom table such as `(table_prefix)custom_contact_form`.

```php
global $wpdb;

$table_name = $wpdb->prefix . 'custom_contact_form';

$wpdb->insert(
    $table_name,
    [
        'name' => $name,
        'email' => $email,
        'website' => $website,
        'message' => $message,
        'submitted_at' => current_time('mysql'),
    ],
    [
        '%s',
        '%s',
        '%s',
        '%s',
        '%s',
    ]
);
```

The “no plugin” story reveals its true complexity. You'll also need table creation, schema updates, export logic, retention rules, admin views if you want a dashboard, and cleanup if the theme changes.

### When the native method is the right fit

Use it when these conditions are true:

- **You want no external dependency:** Everything stays inside WordPress and your hosting environment.
- **You're comfortable in PHP:** Not just template editing, but request handling and sanitization.
- **Your form rules are custom:** Conditional business logic, custom post creation, internal workflows, or nonstandard persistence.

If you're a frontend-heavy team, this approach often feels heavier than expected. It works best when WordPress is already the application runtime, not just the CMS.

## Method 2 The Modern Way Using an External Endpoint

The other no-plugin pattern is simpler to reason about. Keep the form markup in WordPress, but post submissions to a dedicated form backend endpoint instead of processing them through WordPress PHP.

For developers used to static sites, this is the familiar model. HTML submits to an API. React, Next.js, and Vue call the same endpoint with `fetch`. WordPress becomes the place where the form is rendered, not the place where submission logic lives.

![Screenshot from https://www.staticforms.dev](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/9e9d2257-792c-4d14-8603-1658443aea54/wordpress-form-without-plugin-static-forms.jpg)

### Plain HTML example

You can place this in a Custom HTML block or a theme template:

```html
<form action="https://api.staticforms.dev/submit" method="post">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <input type="hidden" name="redirectTo" value="https://example.com/thanks">

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

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

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

  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">

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

This removes all WordPress-side handling. No `admin-post.php`, no hooks, no custom table, no `wp_mail()`.

### React and Next.js example

```jsx
import { useState } from "react";

export default function ContactForm() {
  const [status, setStatus] = useState("idle");

  async function handleSubmit(e) {
    e.preventDefault();
    setStatus("submitting");

    const formData = new FormData(e.currentTarget);

    const response = await fetch("https://api.staticforms.dev/submit", {
      method: "POST",
      body: formData,
    });

    if (response.ok) {
      setStatus("success");
      e.currentTarget.reset();
    } else {
      setStatus("error");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
      <input type="text" name="name" placeholder="Name" required />
      <input type="email" name="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <input type="text" name="honeypot" style={{ display: "none" }} />
      <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.</p>}
    </form>
  );
}
```

### Vue example

```vue
<template>
  <form @submit.prevent="handleSubmit">
    <input type="hidden" name="apiKey" :value="apiKey" />
    <input v-model="form.name" name="name" type="text" placeholder="Name" required />
    <input v-model="form.email" name="email" type="email" placeholder="Email" required />
    <textarea v-model="form.message" name="message" placeholder="Message" required></textarea>
    <input v-model="form.honeypot" name="honeypot" type="text" style="display:none" />
    <button type="submit">{{ status === 'submitting' ? 'Sending...' : 'Send' }}</button>
    <p v-if="status === 'success'">Thanks. Your message was sent.</p>
    <p v-if="status === 'error'">Something went wrong.</p>
  </form>
</template>

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

const apiKey = 'YOUR_API_KEY'
const status = ref('idle')

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

async function handleSubmit() {
  status.value = 'submitting'

  const formData = new FormData()
  formData.append('apiKey', apiKey)
  formData.append('name', form.name)
  formData.append('email', form.email)
  formData.append('message', form.message)
  formData.append('honeypot', form.honeypot)

  const response = await fetch('https://api.staticforms.dev/submit', {
    method: 'POST',
    body: formData
  })

  status.value = response.ok ? 'success' : 'error'
}
</script>
```

For teams that need to route submissions into other systems, webhook support matters more than WordPress integration. This overview of [form webhook integrations](https://www.staticforms.dev/integrations/webhooks) shows the shape of that pattern well: form in the frontend, backend endpoint receives the submission, then forwards JSON to whatever automation stack you already use.

## Comparing the Native vs External Endpoint Approaches

The decision usually comes down to who owns backend complexity. If you choose native PHP, your code owns it. If you choose an external endpoint, the service owns more of it.

Developers often default back to plugins like Contact Form 7 because hand-rolled HTML and PHP requires custom validation, security work, and operational features such as exports, all of which must be built manually. That trade-off is described clearly in [this developer discussion about simple free WordPress forms](https://www.reddit.com/r/Wordpress/comments/q3v5ak/free_way_to_create_a_very_simple_contact_form/).

### Native PHP vs. External Endpoint Form Handling

| Criterion | Native PHP (admin-post.php) | External Endpoint (e.g., Static Forms) |
|---|---|---|
| Setup complexity | Higher. You write templates, hooks, handlers, and redirects | Lower. Point the form at an endpoint and submit |
| Runtime dependency | WordPress and your theme code | Third-party service plus frontend form |
| Control | Maximum control over request flow and storage | Less low-level control, more configuration-driven |
| Maintenance | You maintain validation, mail flow, storage, and updates | The service handles more backend behavior |
| Security burden | Mostly yours | Shared, but still requires safe frontend implementation |
| JAMstack fit | Awkward for frontend-heavy teams | Natural fit for static and decoupled builds |
| Integrations | Custom code required | Often available via webhooks or built-in connectors |
| Portability | Coupled to WordPress | Easier to reuse across WordPress and non-WordPress projects |

### What usually works best

Native PHP works well when the form is part of a larger WordPress application. Think internal tools, custom post creation, or logic that already depends on WordPress users, capabilities, or post data.

External endpoints work well when WordPress is mostly a content layer and your team thinks in components, APIs, and hosted infrastructure.

> If your first instinct is to ask where CSV export, spam filtering, redirect logic, and webhook retries live, you're already thinking like someone who should compare maintenance burden before writing code.

### A blunt decision rule

Pick the native route if you want **full ownership** and are willing to carry the operational work.

Pick the external route if you want **frontend simplicity** and you're fine depending on a service for submission handling.

## Securing Forms and Ensuring Email Delivery

A form that accepts submissions but lets bots through or drops mail into spam folders isn't finished. Most custom implementations break down at this point, especially when developers stop at “the POST request works.”

![An infographic checklist for essential WordPress form security and improved email deliverability using best practices.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/c9e7c2d1-9bec-47be-8ce2-be224747cc52/wordpress-form-without-plugin-form-security.jpg)

### Stop spam before it becomes an inbox problem

Start with simple controls, then add stronger checks where the form attracts abuse.

- **Use a honeypot field:** A hidden field catches simple bots that fill every input.
- **Verify on the server:** Client-side required fields help UX, but bots ignore them.
- **Add a challenge when needed:** reCAPTCHA v2, reCAPTCHA v3, or Cloudflare Turnstile are common choices.
- **Check nonce values in WordPress:** If you stay native, nonce verification is not optional.

A minimal WordPress nonce check looks like this:

```php
if (
    !isset($_POST['contact_form_nonce']) ||
    !wp_verify_nonce($_POST['contact_form_nonce'], 'contact_form_nonce_action')
) {
    wp_die('Invalid form submission.');
}
```

And a basic honeypot in HTML looks like this:

```html
<p style="display:none;">
  <label for="company">Company</label>
  <input id="company" name="company" type="text" autocomplete="off" tabindex="-1">
</p>
```

> **Field note:** Spam prevention works best in layers. Honeypot for low-effort bots, server-side validation for all requests, and CAPTCHA only when the form actually needs it.

### Handle file uploads carefully

Uploads change the threat model. They also change the form markup.

To enable file uploads, the form must include `enctype="multipart/form-data"`, and hosted form environments commonly enforce a size limit, such as Static Forms' **4.5MB** for the whole submission (every file plus the other fields; uploads need its Starter plan or above), as documented in [this file upload guidance](https://www.staticforms.dev/docs/forms/file-uploads). Client-side JavaScript checks are recommended to prevent failed requests before the user submits.

That requirement applies even if your product copy quotes a per-file ceiling. In practice, validate on the client and enforce the server or service limit you operate under.

```html
<form
  action="https://api.staticforms.dev/submit"
  method="post"
  enctype="multipart/form-data"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <input type="file" name="attachment" accept=".pdf,.doc,.docx,.png,.jpg,.jpeg">
  <button type="submit">Upload</button>
</form>
```

Client-side validation:

```html
<script>
  document.addEventListener('DOMContentLoaded', function () {
    const fileInput = document.querySelector('input[name="attachment"]');

    if (!fileInput) return;

    fileInput.addEventListener('change', function () {
      const file = this.files[0];
      if (!file) return;

      // The whole submission must stay under 4.5MB; 4MB leaves room for the other fields.
      const maxAllowedSize = 4 * 1024 * 1024;

      if (file.size > maxAllowedSize) {
        alert('Please choose a file under 4MB.');
        this.value = '';
      }
    });
  });
</script>
```

Also validate file type server-side. Never trust the browser's `accept` attribute as a security control.

### Improve email delivery

A lot of custom WordPress forms “work” but still fail operationally because `wp_mail()` alone doesn't guarantee inbox placement. If your site sends messages from your domain, the domain's mail authentication matters.

Use a sending setup that aligns with your domain and make sure **SPF, DKIM, and DMARC** are configured correctly. If the form is native, route mail through authenticated SMTP or a transactional email provider instead of relying purely on default server mail behavior.

This is also where the `From` address matters. Sending from an address on your own authenticated domain is safer than pretending the submitter's address is the sender. Use `Reply-To` for the user's email instead.

For a practical deliverability checklist, this guide to [email deliverability best practices](https://www.staticforms.dev/blog/email-deliverability-best-practices) covers the operational side well.

### Cover GDPR and data handling

If the form collects personal data, document what you collect, why you collect it, and how long you keep it. The implementation details vary, but the principles stay the same:

- **Add consent text where needed:** Especially for marketing or follow-up beyond the immediate request.
- **Minimize collection:** Don't ask for fields you won't use.
- **Support deletion and export:** If you store submissions, you need a way to remove or provide them.
- **Be careful with webhooks:** Once a submission fans out to Slack, Sheets, Notion, or a CRM, your data map gets wider.

A form is part UI, part backend, and part compliance surface. Developers usually get the UI right first and discover the other two later.

## Conclusion Which Path Is Right for You

The best WordPress form without plugin depends less on ideology and more on what you're maintaining six months from now.

If you want total control, already work comfortably in PHP, and need WordPress-aware business logic, the native `admin-post.php` route is a solid fit. It keeps everything in your stack, but it also makes you responsible for validation, storage, spam filtering, delivery, and future changes.

If you care more about speed of implementation, frontend ergonomics, and decoupling submission handling from WordPress, an external endpoint is usually the more practical choice. That's especially true for teams already building across WordPress, static sites, and JavaScript frameworks.

The mistake isn't choosing one over the other. The mistake is treating forms like a small feature. They touch security, email infrastructure, privacy, storage, and support workflows. Pick the version you can maintain well, not just the one you can ship fast.

---

If the external-endpoint approach matches how your team already builds, [Static Forms](https://www.staticforms.dev) is a straightforward way to add a production-ready form backend to WordPress, React, Next.js, Vue, and static sites without maintaining your own form processing code.

---

## Mastering Form Encryption Beyond TLS in 2026

Source: https://www.staticforms.dev/blog/form-encryption  
Date: 2026-06-20T09:46:24.270Z  
Author: Static Forms Team

You've got a contact or intake form on a static site, HTTPS is green in the browser, and someone on the team says, “We're encrypted.” That's only partly true.

TLS protects the trip from the browser to your endpoint. It doesn't answer the harder questions: who can read submissions after they land, what ends up in logs or exports, how integrations handle sensitive fields, and what happens when the one person holding the decryption key leaves.

## Your First Line of Defense and Its Limits

HTTPS is the baseline. If your form posts over plain HTTP, fix that first and don't debate anything else until it's done.

But **TLS only covers data in transit**. It protects the connection between the browser and the server. Once the server receives the payload, the protection model changes completely. Your app, your database, your backups, your admin dashboard, and any integration that touches the submission can all become exposure points.

For frontend teams, that distinction matters because “secure form” can mean very different things:

- **Transport security:** The browser sends data over TLS.
- **Storage security:** The backend encrypts stored submissions.
- **Access security:** Only authorized people can view submissions.
- **End-to-end confidentiality:** Data is encrypted before it leaves the browser, so the backend can store it without being able to read it.

If you're collecting basic contact messages, TLS plus sane backend controls may be enough. If the form collects identity documents, tax details, health information, API keys, or anything users would reasonably expect staff not to casually browse, you need a stricter model.

A good rule is simple. Ask where the plaintext exists after submit. If the answer includes your app server, logs, support inbox, webhook payloads, CSV exports, or third-party integrations, then TLS isn't the whole story.

> **Practical rule:** Treat form encryption as a data lifecycle problem, not a checkbox on the transport layer.

If you want a concise baseline for form transport and submission security on static sites, [Static Forms' security documentation](https://www.staticforms.dev/docs/forms/security) is a useful reference for the minimum controls you should expect from a hosted form backend.

## Understanding Form Encryption Threat Models

When developers say “the form is secure,” they often mean the POST request is protected on the wire. That's the armored truck model. TLS keeps other people from reading the payload while it moves across the network.

The truck arrives, unloads the data, and leaves. After that, different threats matter.

![A diagram illustrating stages of form encryption, potential threat models, and security risks during data transit.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/8e875aea-1361-44f4-8087-61c2348898fa/form-encryption-threat-models.jpg)

### What form encryption is actually defending against

**Form encryption** transforms readable data into ciphertext. The two common architectures are **symmetric encryption** and **asymmetric encryption**. In symmetric encryption, the same secret key encrypts and decrypts the data. In asymmetric encryption, a public key encrypts and a private key decrypts it. IBM notes that the global encryption software market is projected to reach **USD 20.1 billion by 2025**, growing at a **15.1% CAGR from 2020 to 2025**, which is a useful signal that encryption has become standard infrastructure rather than a niche feature for specialized systems ([IBM on encryption](https://www.ibm.com/think/topics/encryption)).

For forms, the threat model usually looks like this:

- **A compromised application server:** An attacker gets code execution or shell access and reads request bodies or decrypted submissions.
- **A breached database or backup:** Stored form responses leak in bulk.
- **An over-permissioned admin:** Someone with dashboard or database access reads data they don't need.
- **A noisy integration chain:** Webhooks, email notifications, analytics tools, and support systems receive more plaintext than necessary.
- **Client-side exposure before submit:** Browser extensions, malicious scripts, or your own frontend logging can capture values before encryption ever happens.

### Why browser-side encryption changes the trust boundary

If the browser encrypts sensitive values before POST, your backend stores ciphertext, not plaintext. That reduces the blast radius of a server-side compromise. It also changes who you trust.

Without client-side form encryption, you trust:
1. the browser-to-server connection,
2. the application server,
3. the database,
4. the dashboard,
5. every export path.

With client-side encryption, you still need TLS, but you can stop trusting several downstream systems with readable data.

> The main benefit of client-side encryption isn't “more crypto.” It's a smaller trusted surface area.

That doesn't make it universally correct. It just makes the tradeoff explicit. If your backend needs to inspect or route content, full client-side encryption will get in the way. If confidentiality matters more than workflow convenience, that friction is the point.

## Comparing Encryption Approaches

There are three patterns frequently chosen. They solve different problems, and they break in different ways.

### TLS only

This is the default for most web forms. The browser submits plaintext over an encrypted connection, and the server receives readable fields.

It's appropriate when:
- the data isn't highly sensitive,
- the backend must inspect every field,
- staff need easy access in dashboards, emails, or automations.

It does nothing to limit visibility inside your own stack. If your server, admin UI, export process, or notification pipeline is overexposed, TLS won't save you.

### Field-level encryption

This is the practical middle ground. You encrypt only the fields that would cause real harm if exposed, while leaving operational fields readable.

Common examples:
- encrypting `ssn`, `api_key`, `notes`, or `tax_id`
- leaving `name`, `email`, `subject`, or `route` plaintext for triage and automation

This model works well when you still need:
- email routing
- webhook filtering
- dashboard search
- basic analytics by category or source

The downside is design complexity. You need discipline around which fields stay readable, and teams often underestimate how quickly “just one more plaintext field” turns into a lot of plaintext.

### End-to-end or full-form encryption

This model encrypts the whole submission payload in the browser. The backend stores ciphertext and can't read the contents unless it also holds the decryption secret, which defeats much of the point.

A meaningful milestone in this space was the move from simple protected access to actual browser-based end-to-end handling. Jotform's Encrypted Forms 2.0, for example, uses **end-to-end data encryption** and the **Web Crypto API**, so only users with the unique password or access code can read submissions.

This is the strongest option for confidentiality. It's also the most disruptive to downstream workflows.

### Encryption approach comparison

| Approach | Where Data is Encrypted | Protects Against | Integration Impact |
|---|---|---|---|
| TLS only | In transit between browser and server | Network interception during transport | Low impact. Backend can read and route everything |
| Field-level encryption | Selected fields in the browser or app before storage | Exposure of the most sensitive fields in storage, backups, exports, and some internal access paths | Moderate impact. Plaintext fields can still drive webhooks, email, and dashboards |
| End-to-end or full-form encryption | Entire payload in the browser before submission | Server-side and storage-side exposure of submission contents, assuming keys are kept separate | High impact. Most automations can't inspect content without a decryption step |

### What tends to work in practice

For JAMstack sites, the decision usually comes down to one question: **does the backend need to read the sensitive fields to do useful work?**

If the answer is no, full-form encryption is clean and defensible.

If the answer is yes, field-level encryption is usually the better engineering choice. It preserves enough plaintext for routing while sharply reducing what leaks if an inbox, dashboard export, or integration gets messy.

## Implementing Client-Side Encryption in JavaScript

The browser already gives you the main tool you need: the **Web Crypto API**. You don't need a large crypto library to encrypt a form payload before submit.

For a static site, the usual pattern is:

1. Intercept submit.
2. Serialize the fields you want to protect.
3. Encrypt in the browser with a public key.
4. POST the ciphertext to your form endpoint.
5. Decrypt later with the private key in a controlled environment.

### Plain HTML and JavaScript example

This example encrypts the sensitive fields in the browser and sends only ciphertext plus a couple of routing fields in plaintext. RSA-OAEP on its own can only encrypt a couple of hundred bytes, so it uses hybrid encryption: the fields are encrypted with a fresh AES-GCM key, and only that key is encrypted with your RSA public key. To decrypt, unwrap the AES key with the private key, then decrypt the payload with it and the `iv`.

```html
<form id="secure-contact-form" action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_STATIC_FORMS_API_KEY" />

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

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

  <label>
    Category
    <select name="category">
      <option value="sales">Sales</option>
      <option value="support">Support</option>
      <option value="security">Security</option>
    </select>
  </label>

  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />
  <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_V2_SITE_KEY"></div>

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

<script>
const publicKeyPem = `-----BEGIN PUBLIC KEY-----
YOUR_PUBLIC_KEY_HERE
-----END PUBLIC KEY-----`;

function pemToArrayBuffer(pem) {
  const base64 = pem
    .replace('-----BEGIN PUBLIC KEY-----', '')
    .replace('-----END PUBLIC KEY-----', '')
    .replace(/\s+/g, '');
  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i);
  }
  return bytes.buffer;
}

async function importPublicKey(pem) {
  return crypto.subtle.importKey(
    'spki',
    pemToArrayBuffer(pem),
    { name: 'RSA-OAEP', hash: 'SHA-256' },
    false,
    ['encrypt']
  );
}

function arrayBufferToBase64(buffer) {
  const bytes = new Uint8Array(buffer);
  let binary = '';
  for (const byte of bytes) binary += String.fromCharCode(byte);
  return btoa(binary);
}

// RSA-OAEP with a 2048-bit key can only encrypt about 190 bytes, so encrypt the data
// with a fresh AES-GCM key and use RSA-OAEP only to encrypt that key.
async function hybridEncrypt(publicKey, data) {
  const aesKey = await crypto.subtle.generateKey({ name: 'AES-GCM', length: 256 }, true, ['encrypt']);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    aesKey,
    new TextEncoder().encode(JSON.stringify(data))
  );
  const wrappedKey = await crypto.subtle.encrypt(
    { name: 'RSA-OAEP' },
    publicKey,
    await crypto.subtle.exportKey('raw', aesKey)
  );
  return {
    encryptedPayload: arrayBufferToBase64(ciphertext),
    encryptedKey: arrayBufferToBase64(wrappedKey),
    iv: arrayBufferToBase64(iv)
  };
}

document.getElementById('secure-contact-form').addEventListener('submit', async (event) => {
  event.preventDefault();

  const form = event.currentTarget;
  const fd = new FormData(form);

  const plaintextPayload = {
    name: fd.get('name'),
    email: fd.get('email'),
    message: fd.get('message')
  };

  const routingFields = {
    apiKey: fd.get('apiKey'),
    category: fd.get('category'),
    honeypot: fd.get('honeypot'),
    'g-recaptcha-response': fd.get('g-recaptcha-response') || ''
  };

  try {
    const publicKey = await importPublicKey(publicKeyPem);
    const encrypted = await hybridEncrypt(publicKey, plaintextPayload);

    const response = await fetch(form.action, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ ...routingFields, ...encrypted })
    });

    window.location.href = response.ok ? '/thanks' : '/error';
  } catch (error) {
    console.error('Encryption or submission failed', error);
    window.location.href = '/error';
  }
});
</script>
```

### Why this pattern is useful

A few implementation choices matter here:

- **Plaintext routing fields:** `category` remains readable so your backend or webhook can still route the submission.
- **Honeypot support:** the hidden `honeypot` field helps catch simple bots. Static Forms treats any field whose name contains `honeypot` as a trap and silently discards submissions that fill it.
- **Spam protection:** reCAPTCHA v2 or v3, Cloudflare Turnstile, or Altcha still work because bot checks happen around the submission flow, not inside the encrypted payload.
- **Server compatibility:** your form backend doesn't need to understand the encrypted fields. It just stores or forwards the ciphertext.

> Keep the encrypted payload separate from operational metadata. Mixing both into one opaque blob makes support and routing harder than it needs to be.

### React and Next.js example

In React, wrap the encryption logic in a submit handler or custom hook so the component stays readable.

```jsx
import { useState } from 'react';

const publicKeyPem = `-----BEGIN PUBLIC KEY-----
YOUR_PUBLIC_KEY_HERE
-----END PUBLIC KEY-----`;

function pemToArrayBuffer(pem) {
  const base64 = pem
    .replace('-----BEGIN PUBLIC KEY-----', '')
    .replace('-----END PUBLIC KEY-----', '')
    .replace(/\s+/g, '');
  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i);
  }
  return bytes.buffer;
}

async function importPublicKey(pem) {
  return crypto.subtle.importKey(
    'spki',
    pemToArrayBuffer(pem),
    { name: 'RSA-OAEP', hash: 'SHA-256' },
    false,
    ['encrypt']
  );
}

function arrayBufferToBase64(buffer) {
  const bytes = new Uint8Array(buffer);
  let binary = '';
  for (const byte of bytes) binary += String.fromCharCode(byte);
  return btoa(binary);
}

// RSA-OAEP with a 2048-bit key can only encrypt about 190 bytes, so encrypt the data
// with a fresh AES-GCM key and use RSA-OAEP only to encrypt that key.
async function hybridEncrypt(publicKey, data) {
  const aesKey = await crypto.subtle.generateKey({ name: 'AES-GCM', length: 256 }, true, ['encrypt']);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv },
    aesKey,
    new TextEncoder().encode(JSON.stringify(data))
  );
  const wrappedKey = await crypto.subtle.encrypt(
    { name: 'RSA-OAEP' },
    publicKey,
    await crypto.subtle.exportKey('raw', aesKey)
  );
  return {
    encryptedPayload: arrayBufferToBase64(ciphertext),
    encryptedKey: arrayBufferToBase64(wrappedKey),
    iv: arrayBufferToBase64(iv)
  };
}

export default function SecureForm() {
  const [status, setStatus] = useState('idle');

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

    const form = new FormData(event.currentTarget);

    const sensitive = {
      name: form.get('name'),
      email: form.get('email'),
      message: form.get('message')
    };

    try {
      const publicKey = await importPublicKey(publicKeyPem);
      const encrypted = await hybridEncrypt(publicKey, sensitive);

      const body = {
        apiKey: form.get('apiKey'),
        category: form.get('category'),
        ...encrypted
      };

      const res = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(body)
      });

      setStatus(res.ok ? 'success' : 'error');
    } catch (error) {
      console.error('Encryption or submission failed', error);
      setStatus('error');
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="apiKey" value="YOUR_STATIC_FORMS_API_KEY" />

      <input name="name" type="text" placeholder="Name" required />
      <input name="email" type="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <select name="category" defaultValue="support">
        <option value="support">Support</option>
        <option value="security">Security</option>
      </select>

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

      {status === 'success' && <p>Sent.</p>}
      {status === 'error' && <p>Something went wrong.</p>}
    </form>
  );
}
```

### What about file uploads and email delivery

Files change the design. If your form backend supports **file uploads up to 4.5MB per submission**, counting every file plus the other fields (Static Forms offers uploads on Starter and up), think carefully before treating uploaded files like normal text fields. Browser-side encryption for files is possible, but it affects previews, malware scanning, and downstream processing. In many setups, it's cleaner to encrypt metadata and handle files in a separate protected flow.

Custom-domain email also needs realism. If submissions trigger emails from your domain, make sure the backend supports **SPF, DKIM, and DMARC** alignment, otherwise you're adding deliverability problems while trying to solve security problems.

## The Hard Part Key Management and Usability

Writing the encryption code is the easy part. Keeping encrypted data usable for the next person on your team is where most setups fall apart.

![A cybersecurity expert working on multiple screens displaying key management systems and encryption security protocols.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/aa31d83b-917e-4f50-bab8-d7958a49b9f7/form-encryption-cybersecurity-expert.jpg)

A recurring problem in form encryption docs is that they stop at “generate a key pair” and move on. But key loss is often catastrophic. In some tools, like MachForm, the private key is shown only once and cannot be reset, while others require users to generate and manage their own key pairs, which makes the private key a real single point of failure.

### The questions teams avoid until it hurts

If you're using asymmetric encryption, decide these before launch:

- **Where does the private key live**
  Keep it out of frontend code, repos, shared chat threads, and ad hoc password notes.

- **Who can decrypt**
  A named group beats “whoever has the file.”

- **How do you recover**
  If one laptop dies or one employee leaves, old submissions still need a path to decryption.

- **When do you rotate**
  Rotation without a decryptability plan creates a split archive where some data needs old keys and some needs new ones.

A concise primer on the human side of this problem is [The Coin Course's guide](https://thecoincourse.com/educational-guides/learn/security/understanding-private-key-management), which is about private key handling more broadly but maps well to form data workflows.

### Operational models that usually work better

Teams should prefer one of these patterns:

1. **A team-managed secure vault**
   Store the private key in a controlled secrets system, with audited access and a documented recovery process.

2. **Envelope-style handling through a trusted backend**
   The browser encrypts data, a controlled service decrypts only when necessary, and access is logged and limited.

3. **Per-form or per-environment separation**
   Don't reuse one long-lived key across every site, environment, and client project.

> If your decryption process depends on one person's laptop and memory, you don't have a security design. You have a future outage.

If you're using a hosted form backend keyed by account credentials, [the Static Forms API key docs](https://www.staticforms.dev/docs/account/api-key) are a reminder that API keys and encryption keys solve different problems. An API key identifies and authorizes form submissions. It is not a substitute for a decryption strategy.

## Balancing Encryption and Backend Integrations

Pure security advice often collides with the realities of how teams run forms.

A fully encrypted submission is opaque. That's great for confidentiality. It's bad for workflows that depend on reading fields to trigger a webhook, send a useful Slack message, populate a spreadsheet, or classify a support request.

![A comparison chart showing the pros and cons of balancing data encryption with backend system integrations.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/a3b822ac-dad4-42b6-a266-168e3523e874/form-encryption-data-security.jpg)

Some platforms keep certain fields publishable for cloud workflows, and distinguish encrypted storage from authorized decryption and decrypted CSV export. This presents a core tradeoff: stronger end-to-end protection can reduce interoperability unless you deliberately choose which fields stay plaintext.

### Two workable patterns

#### Field-level encryption for mixed workflows

This is the pattern I recommend most often for frontend teams.

Keep these plaintext:
- **Routing fields:** category, region, product, severity
- **Contact handles:** email or ticket reference if automation needs them
- **Anti-spam fields:** honeypots, bot signals, consent flags

Encrypt these:
- **High-risk identifiers:** government IDs, account numbers, tax details
- **Free-text disclosures:** messages where users may overshare
- **Secrets:** API keys, access tokens, internal URLs

This lets your webhook pipeline remain useful. If you need a refresher on webhook mechanics in static site workflows, [this explanation of how webhooks work](https://www.staticforms.dev/blog/what-is-a-webhook-and-how-does-it-work) gives the right mental model.

#### Trusted decryption service

The other option is to decrypt on a controlled backend before forwarding data elsewhere. That gives you richer integrations, but it widens the trusted boundary again.

It can still be the right choice when:
- support agents need readable notifications,
- downstream systems can't handle ciphertext,
- you need validation against private business rules.

### A realistic tool choice

For JAMstack projects, it's reasonable to use a hosted backend as the submission transport and workflow layer while keeping the sensitive fields encrypted client-side. **Static Forms** is one example because it accepts form submissions at a hosted endpoint, supports spam protection options like reCAPTCHA v2 and honeypots on every plan, plus reCAPTCHA v3, Cloudflare Turnstile, and Altcha from the Starter plan up, and can route submissions to downstream tools. In that setup, the service handles submission plumbing while your encrypted fields remain opaque unless you decrypt them elsewhere.

That's often a better compromise than pretending every field needs end-to-end secrecy, or worse, giving up and leaving everything plaintext for convenience.

## Form Encryption and Compliance Considerations

Compliance conversations get easier when you frame form encryption as risk reduction tied to specific data handling duties.

For GDPR, browser-side encryption can support data protection by design because it limits who can read personal data across the submission path. It's not the whole answer. You still need lawful basis, retention rules, deletion workflows, and access control. But reducing plaintext exposure is a concrete technical measure, not a vague policy statement.

For healthcare and similar sensitive workflows, encryption also has to fit the surrounding system. Access control, auditability, backup handling, and vendor responsibilities still matter. A secure form isn't compliant just because the browser runs crypto.

For regulated workloads, the bar is often more explicit. The IRS Publication 1075 requires a **strong 256-bit encryption key string** for encrypted files and says systems protecting confidentiality of data in transit or at rest must use software or hardware meeting the latest **FIPS 140** standards ([IRS Publication 1075 encryption requirements](https://www.irs.gov/privacy-disclosure/encryption-requirements-of-publication-1075)). That's a useful reality check for teams handling tax, identity, or financial data. “Encrypted” is not specific enough. You need to know what standard, where it applies, and how keys are controlled.

If you're building forms that collect low-risk contact info, that level of rigor may be unnecessary. If you're collecting regulated data, it's table stakes.

---

If you want a hosted endpoint for static-site forms and plan to keep sensitive fields encrypted on the client, [Static Forms](https://www.staticforms.dev) is one option to evaluate alongside Formspree, Getform, Basin, Web3Forms, or a self-hosted serverless function. The useful question isn't which brand wins. It's whether the service lets you combine spam protection, file handling, email or webhook delivery, and your chosen form encryption model without forcing sensitive data back into plaintext.

---

## Implement Form Autofill: Boost UX & Conversions

Source: https://www.staticforms.dev/blog/form-autofill  
Date: 2026-06-16T08:32:57.912Z  
Author: Static Forms Team

Chrome's 2024 analysis of **millions of page loads** found that forms were abandoned **75% less frequently** when autofill was used, and users spent about **35% less time** filling them out [in Chrome's autofill analysis](https://developer.chrome.com/blog/autofill-insights-2024). That should change how you think about form autofill.

This isn't a polish task for later. If your signup, checkout, lead form, or contact form fights the browser, you're putting friction directly into a conversion path.

## Why Form Autofill Is a Critical UX Feature

Autofill changes form economics. On signup, checkout, lead capture, and support flows, it cuts keystrokes out of the part of the UI that directly affects completion rate.

That matters because form friction rarely shows up as a single obvious bug. It shows up as slower completions, more input mistakes, more drop-off on mobile, and lower conversion from traffic you already paid for. Chrome's 2024 autofill analysis found materially better outcomes when users filled forms with autofill, including lower abandonment, faster completion, and a separate dataset with a **12 percentage point** increase in form completion for autofill users [in Chrome's 2024 autofill analysis](https://developer.chrome.com/blog/autofill-insights-2024).

![An infographic showing the benefits of form autofill, including reduced time, increased conversion, and higher user satisfaction.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/05897219-3013-41af-8d74-c1d68cd6a16b/form-autofill-ux-benefits.jpg)

### It affects business metrics, not just convenience

A form can look short in a mockup and still feel expensive to complete. Typing a full address on a phone, correcting capitalization, switching keyboard layouts for email and phone fields, and re-entering billing details all add small delays. Those delays stack up fastest in flows users already consider tedious.

Teams that work on conversion usually focus on labels, validation timing, error recovery, input modes, and submit performance. Autofill belongs in that same implementation checklist. If you are already tightening those fundamentals, [these form UX best practices for developers](https://www.staticforms.dev/blog/form-ux-best-practices) fit naturally alongside autofill work.

A practical default works well here. If a field stores information users commonly save in the browser or a profile service, configure it so autofill can identify it unless you have a specific security reason not to.

### Where teams usually get this wrong

The common failure is not lack of browser support. It is markup that gives autofill engines weak or conflicting signals.

Typical problems include:

- **Ambiguous field purpose:** A label says “Name,” but the form never indicates whether that field is a full name, given name, or family name.
- **Component abstraction issues:** A React, Vue, or design-system input drops `name`, `id`, or `autocomplete` before the underlying `<input>` reaches the DOM.
- **Custom field splitting:** Phone, date, address, or payment inputs are broken into unusual subfields that browsers and password managers do not map cleanly.
- **Blanket suppression:** `autocomplete="off"` gets applied everywhere, often to hide noisy suggestions during testing, and then ships to production.

These are implementation details, but they have product impact. Good autofill support makes a form feel shorter without removing fields, lowers typo rates, and reduces the amount of manual entry users have to do on every device. It also sets up the next layer of work: understanding which autofill system is interacting with your form, because browser autofill and password manager autofill do not follow the exact same rules.

## Understanding Browser vs Password Manager Autofill

When a form behaves differently across machines, the first thing to check is **which autofill system is filling it**. Developers often say “the browser autofill is broken” when the user is really interacting with 1Password, Bitwarden, iCloud Keychain, or another password manager.

Those systems overlap, but they're not the same.

![A comparative infographic explaining the differences between web browser autofill and password manager autofill features.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/8f5dcc5c-89d8-48e7-8e0f-97e30fe37d8c/form-autofill-comparison.jpg)

### Browser autofill uses browser and platform data

Browser-native autofill usually handles things like:

- saved names
- email addresses
- shipping and billing addresses
- phone numbers
- payment details
- sometimes saved usernames and passwords

The browser mostly relies on standard HTML signals, especially `autocomplete`, plus other field metadata. If your markup is clean, browsers tend to be predictable.

On mobile, though, the same page can behave differently because the autofill source changes with user settings. Chrome's Android support documentation notes that autofill behavior depends on signed-in status, saved profile data, and the selected autofill service, so reliability can vary across devices and setups in Chrome's Android autofill documentation.

### Password managers use their own matching logic

Password managers are closer to smart overlays than built-in browser heuristics. They often inspect:

- field names and labels
- nearby text
- form structure
- login patterns they recognize
- domain and subdomain context
- previously saved credentials for that site

That's why a password manager may fill a login form correctly even when the browser doesn't, or vice versa.

A useful mental model is this:

| System | Best at | Main input signal |
|---|---|---|
| Browser autofill | Personal profile and payment fields | Standards-based field meaning |
| Password manager autofill | Credentials and saved identities | Heuristics plus vault matching |

### Why this matters when debugging

If Chrome profile autofill works but 1Password doesn't, your HTML might still be fine. If 1Password works but browser address autofill doesn't, your field semantics may be weak.

> Browser autofill wants clear meaning. Password managers tolerate more ambiguity, but they also guess more.

That's why visible labels, stable names, and standard input types still matter even when a password manager appears to “save” a rough form. You're supporting multiple fill engines at once, and each one reads the page a little differently.

## The Definitive Guide to HTML Autocomplete Tokens

If you only remember one thing, remember this: `autocomplete="on"` is not enough. Browsers work better when you tell them the exact purpose of each field.

The HTML standard is explicit that browsers use the `autocomplete` attribute, but may also use a field's `name` and sometimes `id` to store and match saved values. Inconsistent naming can degrade fill accuracy [in the HTML specification's form control infrastructure section](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html).

### The tokens that matter most

Here's the practical subset commonly used.

| Field purpose | Recommended markup |
|---|---|
| Full name | `autocomplete="name"` |
| First name | `autocomplete="given-name"` |
| Last name | `autocomplete="family-name"` |
| Email | `autocomplete="email"` |
| Phone | `autocomplete="tel"` |
| Organization | `autocomplete="organization"` |
| Street address line 1 | `autocomplete="address-line1"` |
| Street address line 2 | `autocomplete="address-line2"` |
| City | `autocomplete="address-level2"` |
| State or region | `autocomplete="address-level1"` |
| Postal code | `autocomplete="postal-code"` |
| Country | `autocomplete="country"` |
| Username | `autocomplete="username"` |
| New password | `autocomplete="new-password"` |
| Current password | `autocomplete="current-password"` |
| One-time code | `autocomplete="one-time-code"` |
| Credit card holder | `autocomplete="cc-name"` |
| Credit card number | `autocomplete="cc-number"` |

Use the token that matches the field's actual meaning, not the text you happen to show in the UI.

### Tokens and names should agree

This breaks more forms than people expect:

- `autocomplete="email"` with `name="user"`
- `autocomplete="given-name"` on a field visually labeled “Full name”
- `autocomplete="tel"` spread across several custom masked inputs
- duplicate `id` values across repeated components

Browsers can recover from some of that, but you're making them guess. Good autofill markup reduces guessing.

> **Field rule:** The label, `name`, `id`, `type`, and `autocomplete` value should all point to the same meaning.

For input semantics in general, including when to use the right control before layering on autofill hints, this guide to [all HTML form input types for developers](https://www.staticforms.dev/blog/form-input-types) is a useful companion.

### A copy-pasteable autofill-ready contact form

```html
<form
  action="https://api.example.com/contact"
  method="post"
>
  <div>
    <label for="name">Full name</label>
    <input
      type="text"
      id="name"
      name="name"
      autocomplete="name"
      required
    />
  </div>

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

  <div>
    <label for="organization">Company</label>
    <input
      type="text"
      id="organization"
      name="organization"
      autocomplete="organization"
    />
  </div>

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

  <div>
    <label for="street-address">Street address</label>
    <input
      type="text"
      id="street-address"
      name="street_address"
      autocomplete="street-address"
    />
  </div>

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

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

### What not to do

A few patterns consistently make form autofill worse:

- **Placeholder-only forms:** placeholders disappear as soon as users type, and they're weak signals compared with real labels.
- **Random internal names:** `field_1`, `inputA`, `customerValue` don't communicate meaning.
- **Custom div-based controls:** if it isn't a real form control, browser autofill may ignore it entirely.
- **JavaScript rewriting attributes after render:** if your framework mutates `name` or `autocomplete` late, some autofill engines won't track the field properly.

If a field maps to real user identity data, annotate it directly and keep the markup boring. Boring wins here.

## Building Autofill-Friendly Forms in JS Frameworks

A small omission in a form component can cost real submissions. In production, I've seen teams ship polished React and Vue forms that looked correct, passed visual QA, and still lost autofill because the component layer dropped `name`, failed to forward `autocomplete`, or changed IDs during hydration.

Framework code does not stop autofill on its own. Component abstractions, client-side rendering decisions, and custom form handling do.

The practical rule is simple. Keep the HTML that browsers and password managers expect. Your framework should wrap native controls, not hide them behind abstractions that rewrite semantics.

![Screenshot from https://www.staticforms.dev](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/e870d136-ddc2-4a92-9332-01e064f19651/form-autofill-static-forms.jpg)

### React example that preserves the real HTML

A reusable input component is fine if it forwards the attributes autofill relies on. The failures usually come from design-system components that treat `name` and `autoComplete` as optional presentation props instead of field identity.

```jsx
function Input({
  label,
  id,
  name,
  type = "text",
  autoComplete,
  required = false
}) {
  return (
    <div className="field">
      <label htmlFor={id}>{label}</label>
      <input
        id={id}
        name={name}
        type={type}
        autoComplete={autoComplete}
        required={required}
      />
    </div>
  );
}

export default function ContactForm() {
  return (
    <form
      action="https://api.example.com/contact"
      method="post"
    >
      <Input
        label="Full name"
        id="name"
        name="name"
        autoComplete="name"
        required
      />
      <Input
        label="Email"
        id="email"
        name="email"
        type="email"
        autoComplete="email"
        required
      />
      <Input
        label="Phone"
        id="tel"
        name="tel"
        type="tel"
        autoComplete="tel"
      />

      <div className="field">
        <label htmlFor="message">Message</label>
        <textarea
          id="message"
          name="message"
          autoComplete="off"
          rows="6"
          required
        />
      </div>

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

That example stays close to plain HTML on purpose. Browsers fill standard controls more reliably than heavily abstracted inputs with masking, delayed prop binding, or client-only state stitched in after first render.

### Next.js example with a serverless-friendly post target

Next.js adds another operational detail. If the server-rendered markup and hydrated client markup differ, autofill can get inconsistent, especially on saved profiles and login flows. Stable field names and IDs matter more than clever component APIs.

```jsx
export default function LeadForm() {
  return (
    <form
      action="https://api.example.com/leads"
      method="post"
    >
      <label htmlFor="given-name">First name</label>
      <input
        id="given-name"
        name="given_name"
        type="text"
        autoComplete="given-name"
        required
      />

      <label htmlFor="family-name">Last name</label>
      <input
        id="family-name"
        name="family_name"
        type="text"
        autoComplete="family-name"
        required
      />

      <label htmlFor="work-email">Work email</label>
      <input
        id="work-email"
        name="email"
        type="email"
        autoComplete="email"
        required
      />

      <label htmlFor="organization">Company</label>
      <input
        id="organization"
        name="organization"
        type="text"
        autoComplete="organization"
      />

      <button type="submit">Request demo</button>
    </form>
  );
}
```

If you are posting from a static or hybrid frontend, a normal HTML form submission is often the safer choice. It keeps browser behavior intact, works without custom fetch logic, and reduces the chances of breaking autofill while wiring up backend delivery. This walkthrough on [HTML forms with JavaScript](https://www.staticforms.dev/blog/html-forms-with-javascript) is a useful reference for that setup.

### Vue example with prop forwarding done right

Vue has the same failure modes. The main difference is that teams often split a base input into multiple layers, then forget to pass through one attribute that matters to autofill.

```vue
<template>
  <div class="field">
    <label :for="id">{{ label }}</label>
    <input
      :id="id"
      :name="name"
      :type="type"
      :autocomplete="autocomplete"
      :required="required"
    />
  </div>
</template>

<script setup>
defineProps({
  label: String,
  id: String,
  name: String,
  type: { type: String, default: "text" },
  autocomplete: String,
  required: { type: Boolean, default: false }
});
</script>
```

Then use it like this:

```vue
<template>
  <form action="https://api.staticforms.dev/submit" method="post">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
    <BaseInput
      label="Email"
      id="email"
      name="email"
      type="email"
      autocomplete="email"
      :required="true"
    />
    <BaseInput
      label="Company"
      id="organization"
      name="organization"
      type="text"
      autocomplete="organization"
      :required="true"
    />
    <button type="submit">Send</button>
  </form>
</template>

<script setup>
import BaseInput from "./BaseInput.vue";
</script>
```

A good test for any framework component is blunt. View the rendered HTML in DevTools and ask whether a plain browser, a password manager extension, and a mobile autofill service can all identify each field without running your app logic.

### Framework-specific gotchas

A few implementation details cause repeated autofill bugs in production:

- **Unstable IDs across renders:** generated IDs that change between SSR and hydration can weaken label association and autofill matching.
- **Controlled inputs that mount empty, then re-render from state:** some autofill engines fill before your app state settles, and your next render wipes the value.
- **Masked or segmented inputs for known values:** splitting phone numbers, dates of birth, or card data into multiple custom fields makes recognition harder.
- **Submit handlers that replace native form submission:** intercepting submit is sometimes necessary, but it also means you own validation timing, pending state, retries, and value serialization.
- **Security filters that mutate input values on every keystroke:** sanitize on output and validate on submit. If you need a refresher, [learn about cross site scripting](https://www.vulnsy.com/glossary/cross-site-scripting).

The trade-off is straightforward. Rich component systems improve consistency, but every layer between the user and a native `<input>` is another place to break autofill. Keep the contract boring: stable `id`, meaningful `name`, correct `autocomplete`, real labels, native controls, standard form submission unless there is a clear reason not to.

## Advanced Autofill Patterns and Security

Teams usually notice autofill only after it breaks. By then, the cost is real. Failed address fills slow checkout, password managers miss login fields, and support gets tickets that sound random until you inspect the markup.

Correct tokens help, but advanced autofill work is mostly about giving browsers and password managers a clean, predictable form to interpret. That means clear labels, field grouping, sane defaults, and careful decisions about which values should never be stored or reused.

![An infographic illustrating best practices for form autofill, emphasizing accessibility labels and robust security measures.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/7c5b3eba-d7b8-48a8-9e31-76f93b780bc5/form-autofill-security-practices.jpg)

### Visible labels still matter

A real `<label>` improves three things at once. It helps screen readers, gives autofill engines another reliable signal, and keeps the form understandable when autofill guesses wrong or does nothing.

Placeholder-only forms fail in common edge cases. Users lose context once they start typing, translation can make placeholders less useful, and password managers often rely more heavily on stable labels and nearby text than many teams expect.

Use placeholders for examples. Keep labels for meaning.

### Group related fields with real structure

`<fieldset>` and `<legend>` become more important once the form has repeated patterns. Billing and shipping blocks, account and profile details, and multi-step onboarding flows all create ambiguity if every text input looks the same to the parser.

```html
<fieldset>
  <legend>Billing address</legend>

  <label for="billing-name">Full name</label>
  <input id="billing-name" name="billing_name" autocomplete="name" />

  <label for="billing-address-line1">Address line 1</label>
  <input
    id="billing-address-line1"
    name="billing_address_line1"
    autocomplete="address-line1"
  />

  <label for="billing-postal-code">Postal code</label>
  <input
    id="billing-postal-code"
    name="billing_postal_code"
    autocomplete="postal-code"
  />
</fieldset>
```

This also helps with a problem basic token guides skip. Password managers do not always follow the same rules as the browser. A browser may infer an address block from autocomplete tokens alone. A password manager extension might also inspect headings, labels, button text, or the order of nearby fields. Grouping fields with semantic HTML gives both systems better context.

### Know when to turn autofill off

Some fields should not be remembered, suggested, or reused. One-time codes are the obvious example, but they are not the only one.

Use `autocomplete="off"` selectively for cases where prior values create friction or risk:

- **One-time codes:** temporary by design and unsafe to reuse
- **CAPTCHA or challenge responses:** these should expire with the session
- **Freeform message bodies:** previous support requests are rarely useful suggestions
- **Short-lived internal operation fields:** values that can cause mistakes if an old entry reappears

Be careful with login forms. Setting `autocomplete="off"` on username or password fields often does not stop password managers, and fighting them usually makes sign-in worse. If the goal is account security, stronger protections come from MFA, session controls, and server-side checks, not from trying to block saved credentials.

### Security goes beyond the input element

Autofill values are still user input. Treat them exactly like typed values. Validate on the server, escape on output, and assume a malicious payload can arrive through any field, including one the browser or a password manager filled.

This matters in real products because filled values often get reused outside the form itself. Teams render address previews, account summaries, receipt pages, and admin dashboards with the same submitted data. If any of those views inject user-controlled HTML, the bug is still exploitable. If you need a concise refresher on that class of bug, [learn about cross site scripting](https://www.vulnsy.com/glossary/cross-site-scripting) before wiring custom form previews, confirmation screens, or dashboard views.

A few security and implementation rules hold up well in production:

- **Do not rely on hidden fields for trusted decisions:** users and extensions can modify them
- **Do not infer identity from autofilled data:** verify with the server and the authenticated session
- **Avoid disabling paste on security-sensitive fields:** it hurts password manager use and pushes users toward weaker habits
- **Store less whenever possible:** the safest autofilled secret is the one your app never persists unnecessarily

Good autofill support is mostly disciplined HTML and conservative handling of user data. The advanced part is resisting clever UI patterns that weaken recognition, accessibility, or security.

## Debugging Autofill Across Browsers and Devices

The hard part of form autofill isn't adding tokens. It's understanding why the same form works on your laptop, fails on Safari, and behaves differently again on Android.

A useful debugging pass starts with the plain HTML, not your framework code.

### A practical checklist

- **Confirm the field is a native control:** start with real `<input>`, `<select>`, and `<textarea>` elements.
- **Check `name`, `id`, and `autocomplete` together:** if they conflict, browsers may ignore your intent.
- **Verify labels are visible and associated:** use `for` and matching `id`.
- **Avoid weird field splitting:** one phone field is easier to fill than multiple micro-inputs.
- **Test on HTTPS:** browser features often behave better in secure contexts.
- **Inspect actual rendered markup:** not the JSX, Vue template, or component API.
- **Test with saved profile data:** a browser can't autofill what the user hasn't stored.
- **Try multiple fill sources:** native browser profile data and a password manager can behave differently.

### Mobile and Safari are where reality shows up

Android is especially variable because the autofill service may differ by user choice. If one tester uses Google Autofill and another uses a password manager as the default service, they may see different suggestions and fill behavior.

Safari also tends to reward strict, semantic markup. If a form only works after adding clearer labels, simpler controls, and more accurate field names, that usually means the original markup was too ambiguous.

When debugging, strip the form back to the smallest native version that should work. If the simple version autofills and the production component doesn't, the bug is in your abstraction, not in autofill itself.

---

If you're building static or JAMstack sites and need a backend for the forms you've already marked up correctly, [Static Forms](https://www.staticforms.dev) is one practical option. You can point a standard HTML form at its hosted endpoint, keep your native form behavior intact, and add spam protection and GDPR tooling, plus webhooks and file uploads up to 4.5MB per submission on Starter and up, and custom-domain email with SPF, DKIM, and DMARC on Pro and up, without maintaining your own form infrastructure.

---

## Short Form vs Long Form: A Developer's Guide to Conversion

Source: https://www.staticforms.dev/blog/short-form-vs-long-form  
Date: 2026-06-15T07:52:43.523Z  
Author: Static Forms Team

You're probably in the same argument that frequently arises at some point. Someone wants six more fields so sales can qualify better, and someone else wants name plus email because every extra input feels like a chance to lose the submission.

That argument usually gets flattened into “short forms convert, long forms qualify.” That's directionally true, but it's not enough to build with. Form length affects frontend complexity, validation strategy, accessibility, spam handling, privacy exposure, and what your backend has to do after submit.

## The Form Length Debate in Every Dev Team

The version I see most often is simple. Marketing asks for company size, budget, timeline, phone, role, use case, and “how did you hear about us.” Engineering looks at the mock and sees friction, more validation branches, more edge cases on mobile, and a bigger pile of inaccessible markup if nobody is careful.

Both sides are usually right.

A short form helps when the user's intent is still soft. A newsletter signup, quick contact form, or “request early access” flow should feel lightweight. If the page asks for too much before trust exists, users leave. You get fewer submissions and still don't know why, because the drop-off is spread across multiple fields.

A long form makes sense when the action behind the submission is expensive. If a team is requesting a custom quote, applying for a role, or uploading project requirements, low-detail submissions create work for humans downstream. You either chase missing data over email or qualify by hand.

> **Practical rule:** If your team can't act on the submission without follow-up for basic facts, the form may be too short. If your team rarely uses half the collected fields, the form is probably too long.

The useful framing isn't “which side wins.” It's this:

- **Short forms optimize for throughput.**
- **Long forms optimize for decision-ready context.**
- **Structured forms beat sloppy forms at either length.**

That last point matters most for developers. A cleanly grouped long form with conditional sections and good defaults often performs better than a cramped short form with poor labels, unclear errors, and no input hints. The debate is less about field count than about whether the interface matches user intent.

## Core Trade-Offs Conversion UX and Data Quality

The shortest honest answer in the short form vs long form debate is that each format shifts cost. Short forms push cost onto your team after submission. Long forms push cost onto the user before submission.

A good decision matrix makes that visible early.

| Criterion | Short Form Impact | Long Form Impact |
| --- | --- | --- |
| Initial friction | Low. Fewer decisions and less typing | Higher. More fields increase effort |
| Submission volume | Usually better for lightweight intent | Usually lower unless motivation is strong |
| Lead qualification | Limited context at submit time | Better context before handoff |
| Mobile usability | Easier to complete quickly | Needs stronger spacing, grouping, and step logic |
| Validation complexity | Simpler client-side rules | More edge cases and dependencies |
| Accessibility overhead | Lower, but still needs proper labeling | Higher because grouping and navigation matter more |
| Privacy exposure | Less collected data to store and protect | More personal data means more responsibility |
| Follow-up workload | More manual clarification later | Less clarification if the fields are well chosen |

![A comparison chart showing the trade-offs between short and long forms for user conversion and data quality.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/a80347bd-4808-4a4e-a1c7-4c7db48ff78b/short-form-vs-long-form-trade-offs.jpg)

### Where short forms usually win

Short forms are hard to beat when the visitor wants a quick interaction. Contact pages, waitlists, basic support requests, and newsletter subscriptions benefit from low friction. You're not trying to learn everything. You're trying to get a reliable first signal.

That maps well to a broader platform pattern. A [2024 YouTube study](https://arxiv.org/html/2402.18208v2) found that short-form content generally achieved higher view counts and engagement than long-form content after it became widely available. Different medium, same top-of-funnel lesson. Short interactions often win on initial participation.

### Where long forms earn their keep

Long forms work when the submission itself needs to be useful on arrival. For quote requests, onboarding questionnaires, project scoping, and hiring, richer detail can save time because the receiving team can route or respond without another round trip.

That doesn't mean “make it longer.” It means ask only for fields that change what happens next.

Use this filter before adding a field:

- **Routing value:** Does this answer determine who handles the request?
- **Response value:** Does it change the reply, estimate, or next step?
- **Compliance value:** Do you need it for consent, invoicing, or legal processing?
- **Noise check:** If the field were blank, would anyone care?

If you're tightening validation rules, it also helps to [ensure data accuracy in documents](https://www.digiparser.com/blog/what-is-data-validation) with the same mindset you use for forms. Validate what matters. Don't collect extra data just because the UI has room for it.

### Structure matters more than raw length

Many teams often miss the mark. Recent guidance increasingly shows that **structure and search intent matter more than word count**. Devenup notes that AI search favors **“well-structured long-form content with short, extractable answer blocks,”** and that **“content depth and structure carry more weight than length alone”** in [its analysis of long-form vs short-form content](https://devenup.com/blog/long-form-vs-short-form-content).

That advice applies cleanly to forms. A long form with sections, progress cues, and conditional reveals can feel easier than a short form dumped into one dense card.

A few implementation patterns help immediately:

- **Group related fields:** Contact info, project details, consent, and attachments shouldn't live in one undifferentiated stack.
- **Use conditional logic carefully:** Show “Company size” only if “I'm contacting you for business” is selected.
- **Write answer-first helper text:** Explain format before users fail validation.
- **Keep the button label specific:** “Request quote” is better than “Submit.”

For more field-level interface details, this guide on [form UX best practices](https://www.staticforms.dev/blog/form-ux-best-practices) covers the mechanics that matter once you've chosen the right length.

## When to Use Short Forms with Code Examples

Short forms are for speed. If the page is trying to start a conversation rather than complete a process, shorter is usually the safer default.

That matches the broader pattern of short content doing well at the top of the funnel. As noted earlier, short-form formats tend to perform well for first-touch engagement. Forms behave the same way when trust is still forming.

![A modern laptop on a desk showing web development code for a user signup form interface.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/fef01c6a-ecac-4723-a96f-56c463c5e82f/short-form-vs-long-form-web-development.jpg)

### Plain HTML contact form

This is enough for a brochure site, portfolio, or startup landing page.

```html
<form
  action="https://api.staticforms.dev/submit"
  method="post"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

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

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

  <div>
    <label for="message">Message</label>
    <textarea id="message" name="message" rows="5" required></textarea>
  </div>

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

This works because every field earns its place. Name identifies the sender, email gives you a reply path, and message captures intent.

### React signup form

For React, keep local state minimal unless you need custom validation or optimistic UI.

```jsx
import { useState } from "react";

export default function SignupForm() {
  const [email, setEmail] = useState("");

  return (
    <form action="https://api.staticforms.dev/submit" method="post">
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
      <input type="hidden" name="subject" value="New newsletter signup" />

      <label htmlFor="email">Work email</label>
      <input
        id="email"
        name="email"
        type="email"
        autoComplete="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        required
      />

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

For a short form, native form submission is often enough. You don't need a fetch wrapper just because you're in React.

### Vue quick inquiry form

Vue works well for adding just enough interactivity without turning the form into an app.

```vue
<template>
  <form action="https://api.staticforms.dev/submit" method="post">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

    <label for="name">Name</label>
    <input id="name" name="name" type="text" v-model="name" required />

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

    <button type="submit" :disabled="!name || !email">
      Get in touch
    </button>
  </form>
</template>

<script setup>
import { ref } from "vue";

const name = ref("");
const email = ref("");
</script>
```

> Keep short forms narrow in purpose. A contact form that also tries to qualify budget, company size, and project scope usually belongs on a different page.

Use short forms when the page promise is simple and the next step can happen after the first reply.

## When to Use Long Forms with Code Examples

Long forms belong in workflows where incomplete submissions create real work. Quote requests, onboarding questionnaires, applications, and detailed support tickets all fit. The user already expects effort, so the job is to make that effort legible and manageable.

![A professional working at a desk with a computer displaying data while taking notes in a notebook.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/4f5b5fe2-9d10-4b0b-adfc-67d0a69ff165/short-form-vs-long-form-workspace-setup.jpg)

### A long form is a reliability problem

This is the part teams underestimate. Long forms aren't just short forms with extra fields. They have more validation branches, more opportunities for ambiguous labels, more state to preserve, and more chances to lose users during correction.

There's a useful analogy from AI systems. [LongGenBench](https://arxiv.org/html/2409.02076v6), a benchmark for long-form generation up to **16K and 32K tokens** across **four scenarios** and **three instruction types**, shows that even advanced models with **32K–128K** context windows still degrade on long-form tasks, with failures like premature termination, incomplete responses, instruction disregard, and repetitive output. That same principle shows up in forms. As state grows, reliability gets harder.

### Multi-step quote request in HTML

Break the form into meaningful groups even if you don't fully split it into separate routes.

```html
<form action="https://api.staticforms.dev/submit" method="post">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://example.com/quote/thanks" />

  <fieldset>
    <legend>Contact details</legend>

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

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

    <label for="company">Company</label>
    <input id="company" name="company" type="text" autocomplete="organization" />
  </fieldset>

  <fieldset>
    <legend>Project details</legend>

    <label for="projectType">Project type</label>
    <select id="projectType" name="projectType" required>
      <option value="">Select one</option>
      <option>Website redesign</option>
      <option>New build</option>
      <option>Migration</option>
      <option>Maintenance</option>
    </select>

    <label for="timeline">Timeline</label>
    <select id="timeline" name="timeline" required>
      <option value="">Select one</option>
      <option>ASAP</option>
      <option>Within a month</option>
      <option>This quarter</option>
      <option>Just researching</option>
    </select>

    <label for="details">Requirements</label>
    <textarea id="details" name="details" rows="6" required></textarea>
  </fieldset>

  <button type="submit">Request quote</button>
</form>
```

### Next.js with conditional fields

Conditional fields let you keep the form detailed without making every user answer every question.

```jsx
"use client";

import { useState } from "react";

export default function ProjectForm() {
  const [isBusiness, setIsBusiness] = useState("yes");

  return (
    <form action="https://api.staticforms.dev/submit" method="post">
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

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

      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" required />

      <label htmlFor="isBusiness">Business inquiry?</label>
      <select
        id="isBusiness"
        name="isBusiness"
        value={isBusiness}
        onChange={(e) => setIsBusiness(e.target.value)}
      >
        <option value="yes">Yes</option>
        <option value="no">No</option>
      </select>

      {isBusiness === "yes" && (
        <>
          <label htmlFor="company">Company</label>
          <input id="company" name="company" type="text" />

          <label htmlFor="role">Role</label>
          <input id="role" name="role" type="text" />
        </>
      )}

      <label htmlFor="details">Project details</label>
      <textarea id="details" name="details" rows="6" required />

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

If you're building a wizard instead of a single long page, this article on [multi-step forms](https://www.staticforms.dev/blog/multi-step-forms) is a practical reference for field grouping, progress states, and step transitions.

> If a long form feels hard to finish, reduce visible complexity before you reduce field count. Grouping and sequencing usually fix more than deletion alone.

## Implementation Spam Protection and File Uploads

Once a form reaches production, the debate shifts from UX to operational details. Short or long doesn't matter if bots flood it, attachments fail imperceptibly, or your backend can't parse multipart requests.

![Screenshot from https://www.staticforms.dev](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/75ad0516-d14b-4148-96e2-3c1de1fcd8f0/short-form-vs-long-form-static-forms.jpg)

### Spam protection options that fit static sites

The baseline is a honeypot field. It won't stop everything, but it catches simple bots with almost no UX cost.

```html
<form action="https://api.staticforms.dev/submit" method="post">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

  <div style="display:none;">
    <label for="website">Leave this field empty</label>
    <input id="website" type="text" name="honeypot" tabindex="-1" autocomplete="off" />
  </div>

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

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

When bots get more aggressive, use a challenge layer. Common choices are **reCAPTCHA v2**, **reCAPTCHA v3**, **Cloudflare Turnstile**, and **Altcha**. The right choice depends on how much friction you'll tolerate and how much privacy sensitivity your audience has. If you want a background read on how human verification flows work, this breakdown of [AI Image Detector on human tests](https://www.aiimagedetector.com/blog/are-you-human-test) is useful context.

### File uploads need the right encoding

This is the part that gets missed in quick prototypes. If your form includes a file input, the form needs `enctype="multipart/form-data"` or the browser won't send the file properly.

```html
<form
  action="https://api.staticforms.dev/submit"
  method="post"
  enctype="multipart/form-data"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

  <label for="resume">Upload resume</label>
  <input
    id="resume"
    name="resume"
    type="file"
    accept=".pdf,.doc,.docx"
  />

  <button type="submit">Apply</button>
</form>
```

For JAMstack projects, a hosted backend can remove a lot of plumbing here. One option is **Static Forms**, which accepts submissions at a hosted endpoint, supports spam controls like honeypot and reCAPTCHA v2, and, on Starter and up, adds reCAPTCHA v3, Cloudflare Turnstile, and Altcha and handles file uploads up to **4.5MB per submission**, counting every file plus the other fields. If you're implementing uploads, its guide on [HTML file upload handling](https://www.staticforms.dev/blog/file-upload-html) shows the required form attributes and payload shape.

### A few implementation checks

- **Accept only expected file types:** Use the `accept` attribute, then still validate server-side.
- **Handle error states visibly:** Network failure, invalid file type, and oversized uploads need distinct messages.
- **Test without JavaScript:** Native form fallback still matters on static sites.
- **Log webhook failures:** If you relay submissions to another system, retries and monitoring matter.

## Accessibility and Privacy Implications

Every new field adds responsibility. That's true for usability, and it's even more true for privacy.

A useful analogy comes from content. In one dataset, long-form articles of **3,000+ words** generated **75% more backlinks** than average-length articles of **901–1,200 words** in research cited by ImpactPlus, based on Semrush's *State of Content Marketing 2020* dataset ([reference](https://www.impactplus.com/blog/long-form-content-vs.-short-form-content)). For forms, the parallel is straightforward. If you ask for more, users expect more value and more care in return.

### Accessibility requirements rise with complexity

A short form can still be inaccessible, but long forms create more ways to fail. Field relationships, error recovery, keyboard order, and screen reader grouping all matter more once the page has sections and optional branches.

Use the basic HTML semantics first:

```html
<fieldset>
  <legend>Billing details</legend>

  <label for="billingName">Name on invoice</label>
  <input id="billingName" name="billingName" type="text" required />

  <label for="billingEmail">Billing email</label>
  <input id="billingEmail" name="billingEmail" type="email" required />
</fieldset>
```

That gives screen readers real structure instead of a flat list of controls.

A few essential points:

- **Every input needs a label:** Placeholder text is not a label.
- **Errors need text, not just color:** Red borders alone won't help many users.
- **Focus order must stay logical:** Especially after conditional fields appear.
- **Progress indicators need semantics:** “Step 2 of 4” is useful only if assistive tech can perceive it.

> More fields mean more opportunities to create inaccessible states. Test long forms with keyboard only before you ship them.

### Privacy should shape form length

Developers sometimes treat data collection like a product requirement handed down from somewhere else. It isn't. If your form asks for phone number, address, budget, file attachments, or free-text personal details, your system now owns that risk.

For GDPR and similar privacy regimes, the practical questions are simple:

- Why are you collecting each field?
- Where is it stored?
- Who can access it?
- How will you delete it if asked?
- Did the user clearly consent where consent is required?

If a field doesn't have a clear operational reason, remove it. Minimal collection is easier to defend and easier to maintain.

### Deliverability matters too

If the form sends auto-responses or forwards via your domain, email authentication matters. **SPF, DKIM, and DMARC** help receiving mail servers trust those messages. That's not just infrastructure hygiene. It affects whether a user ever sees the confirmation you promised.

## How to AB Test Your Forms for Optimal Performance

The fastest way to end a form-length argument is to test both versions against the same traffic source and measure what happens after submit, not just at submit.

### Test one meaningful difference

Keep the page, offer, and traffic source stable. Change the form only.

Variant A can be a short form:

```html
<input type="hidden" name="variant" value="A" />
```

Variant B can be a longer version:

```html
<input type="hidden" name="variant" value="B" />
```

Point both to the same backend endpoint so the submission handling stays consistent. That removes one major source of noise.

### Measure more than raw submissions

Raw completion count is useful, but it's not enough. Review the quality of what arrives.

Look at:

- **Completion quality:** Did the team get enough information to act?
- **Reply efficiency:** Did you need follow-up email to collect missing basics?
- **Spam rate:** Did one version attract more junk submissions?
- **Privacy sensitivity:** Did users hesitate more when asked for phone numbers or extra identifiers?

### Keep the routing boring

Don't make the test architecture clever. A split route, hidden variant field, and one submission pipeline are enough. What you want is a clean comparison, not a frontend experiment framework nobody wants to maintain three months later.

If your short version wins on volume but creates bad handoffs, you didn't really win. If your long version filters better but depresses valid submissions too much, that's not a win either. The right answer is the variant that improves the full workflow from visitor to useful submission.

---

If you want a no-backend way to run these experiments on a static site, [Static Forms](https://www.staticforms.dev) is one option. You point your form at a hosted endpoint, keep native HTML submission, and route entries to email, a dashboard, or downstream tools without maintaining your own form handler.

---

## 7 Top Backend as a Service Examples for 2026

Source: https://www.staticforms.dev/blog/backend-as-a-service-examples  
Date: 2026-06-14T07:18:57.820Z  
Author: Static Forms Team

You've already got the frontend working. The React components are clean, the Vue state is under control, and the site deploys fine on a static host. Then the backend questions show up all at once: where do form submissions go, how do users sign in, where do uploaded files live, and who's handling spam and compliance?

That's where backend as a service examples become useful in a very practical way. Instead of building auth, storage, APIs, and form handling from scratch, you can rent those pieces and ship faster. The category isn't small anymore either. Allied Market Research valued the BaaS market at USD 3.1 billion in 2022 and projected USD 28.7 billion by 2032, with a 25.3% CAGR from 2023 to 2032, which helps explain why hosted auth, database, storage, and form backends now show up in so many web stacks ([Allied Market Research BaaS market report](https://www.alliedmarketresearch.com/backend-as-a-service-market)).

For JAMstack teams, the decision usually isn't “BaaS or no BaaS.” It's which kind. Some tools give you a full application backend. Others solve one boring but critical problem, like forms, very well. Here are seven options worth considering.

## 1. Firebase

![Firebase (Google)](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/535126a7-9d14-43c1-afe6-36355b25c03a/backend-as-a-service-examples-web-interface.jpg)

[Firebase](https://firebase.google.com/) is still one of the easiest ways to add a real backend to a frontend-heavy app. If you need auth, client SDKs, hosted data, push messaging, and a path into a larger cloud platform, it's usually on the shortlist for good reason.

What Firebase does well is speed. Firestore, Realtime Database, Authentication, Hosting, and Cloud Messaging fit together cleanly, and the docs are mature enough that most frontend developers can get a prototype running quickly. If your app needs live updates or offline-aware clients, Firebase feels natural.

### Where Firebase fits

Firebase is strongest when your frontend is the product and the backend mostly exists to support it.

- **Realtime-first apps:** Chat, dashboards, collaborative UI, and mobile-heavy products fit Firebase well.
- **Auth without ceremony:** Email/password and social login are straightforward to wire up.
- **Google Cloud runway:** If the app grows beyond the happy path, you can extend into the wider Google Cloud stack.

The trade-off is the data model. Firestore is great when your access patterns are simple and well understood. It gets less pleasant when your domain really wants joins, reporting queries, or relational constraints.

> Firebase is easy to start and easier to overfit. If your data is naturally relational, forcing it into document patterns can become the real complexity cost.

### React example with Firebase Auth and Firestore

> **Why a password field is fine here and nowhere else in this blog:** the value goes straight into the auth provider's own SDK, which is built to receive it and never stores it in plaintext. That is the *only* correct destination for a credential. Never post a password to a form-submission endpoint — it would land in an email notification and a submissions inbox.

```jsx
import { useState } from "react";
import { initializeApp } from "firebase/app";
import { getAuth, signInWithEmailAndPassword } from "firebase/auth";
import { getFirestore, collection, addDoc } from "firebase/firestore";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "your-project.firebaseapp.com",
  projectId: "your-project-id",
};

const app = initializeApp(firebaseConfig);
const auth = getAuth(app);
const db = getFirestore(app);

export default function ContactNote() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState(""); // handed straight to the auth SDK, never to a form endpoint
  const [message, setMessage] = useState("");

  async function handleLoginAndSave(e) {
    e.preventDefault();
    const userCredential = await signInWithEmailAndPassword(auth, email, password);
    await addDoc(collection(db, "messages"), {
      uid: userCredential.user.uid,
      message,
      createdAt: new Date().toISOString()
    });
  }

  return (
    <form onSubmit={handleLoginAndSave}>
      <input value={email} onChange={(e) => setEmail(e.target.value)} type="email" placeholder="Email" />
      <input value={password} onChange={(e) => setPassword(e.target.value)} type="password" placeholder="Password" />
      <textarea value={message} onChange={(e) => setMessage(e.target.value)} placeholder="Message" />
      <button type="submit">Save</button>
    </form>
  );
}
```

For static marketing sites that only need contact forms, this is usually more backend than you need. For apps with users and live data, it still makes sense.

## 2. Supabase

![Supabase](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/e9af8e86-b929-4d46-b1bc-3573ce27995a/backend-as-a-service-examples-firebase-homepage.jpg)

[Supabase](https://supabase.com/) is what many teams wanted when Firebase felt too document-oriented. You get managed Postgres, auth, storage, realtime features, and edge functions, but your data still lives in a relational database you can understand with normal SQL.

That matters more than feature checklists suggest. Postgres gives you joins, constraints, migrations, and query patterns that are easier to reason about once the app stops being a prototype. Supabase also appeals to teams that care about portability, because the open-source posture and self-hosting path are more credible than in most hosted BaaS products.

### The real advantage is data clarity

Supabase works well when you know your app has structured entities and relationships. Products with users, teams, permissions, subscriptions, and audit data usually feel cleaner in SQL than in document storage.

A lot of static-site builders also pick Supabase as the “serious backend later” option. They might start with a form endpoint or a few auth screens, then add tables, policies, and storage as the product grows.

- **SQL and RLS:** Row-Level Security is a big deal when you need tenant-aware access control.
- **Better exit path:** If lock-in worries you, Supabase is easier to justify than many black-box alternatives.
- **More operational thinking required:** You still need to understand schema design, policies, and query behavior.

The lock-in point matters. Encore's discussion of BaaS tradeoffs highlights that an open-source and self-hostable posture reduces lock-in because “the exit is well-trodden” ([Encore on BaaS providers and tradeoffs](https://encore.dev/articles/backend-as-a-service)).

> **Practical rule:** If your first whiteboard sketch includes tables, ownership rules, and reporting queries, start with Postgres instead of pretending a document store will stay simple.

### Vue example with Supabase insert

```vue
<script setup>
import { ref } from 'vue'
import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://YOUR_PROJECT.supabase.co', 'YOUR_ANON_KEY')
const name = ref('')
const email = ref('')
const message = ref('')

async function submitForm() {
  const { error } = await supabase.from('contact_messages').insert({
    name: name.value,
    email: email.value,
    message: message.value
  })

  if (error) {
    console.error(error)
    return
  }

  name.value = ''
  email.value = ''
  message.value = ''
  alert('Submitted')
}
</script>

<template>
  <form @submit.prevent="submitForm">
    <input v-model="name" type="text" placeholder="Name" />
    <input v-model="email" type="email" placeholder="Email" />
    <textarea v-model="message" placeholder="Message"></textarea>
    <button type="submit">Send</button>
  </form>
</template>
```

If spam-heavy public forms are part of the plan, pair the database approach with a proper anti-bot layer. This guide on [spam email bots on forms](https://www.staticforms.dev/blog/spam-email-bot) is worth a read before you expose a write endpoint directly.

## 3. AWS Amplify

![AWS Amplify](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/4c4582ce-f41d-4610-b2ec-fdba1f83fe74/backend-as-a-service-examples-supabase-landing-page.jpg)

[AWS Amplify](https://aws.amazon.com/amplify/) makes sense when you want a frontend-friendly workflow but know you may end up deeper in AWS. Under the hood, you're dealing with Cognito, AppSync, Lambda, API Gateway, S3, and other AWS services. Amplify gives you a structured way to stitch them together without starting from raw infrastructure.

This is the most “full cloud platform in BaaS clothing” option on the list. That's good if your team already speaks AWS. It's less good if you just wanted a contact form and now you're reading IAM docs.

### Good fit for teams that want AWS, not just a backend

The strongest case for Amplify is long-term alignment with AWS. Security, permissions, hosting, APIs, and storage can all evolve without a migration to another ecosystem.

There's also a real example of that speed advantage. In a Neiman Marcus omnichannel app launch, the team initially estimated four months, then reported a 50% increase in speed to market and a 90% reduction in development costs by using AWS Amplify, Amazon Cognito, and AWS AppSync ([Neiman Marcus BaaS case study summary](https://acropolium.com/blog/baas-use-cases/)).

- **Best for AWS-native organizations:** It's easier when your company already uses AWS accounts, policies, and services.
- **Less friendly for casual use:** Pricing and architecture are spread across multiple underlying services.
- **Strong integration story:** Auth, APIs, storage, hosting, and CI/CD can live in one ecosystem.

> With Amplify, you're not really choosing a lightweight utility. You're choosing an opinionated ramp into AWS.

### Next.js example with Amplify Auth

```jsx
"use client";

import { useState } from "react";
import { Amplify } from "aws-amplify";
import { signIn } from "aws-amplify/auth";

Amplify.configure({
  Auth: {
    Cognito: {
      userPoolId: "us-east-1_example",
      userPoolClientId: "exampleclientid",
    },
  },
});

export default function LoginForm() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState(""); // handed straight to the auth SDK, never to a form endpoint

  async function handleSubmit(e) {
    e.preventDefault();
    await signIn({ username: email, password });
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} placeholder="Email" />
      <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} placeholder="Password" />
      <button type="submit">Sign in</button>
    </form>
  );
}
```

If your JAMstack app also pushes events into other systems, understanding webhook behavior matters. This short explainer on [how webhooks work](https://www.staticforms.dev/blog/what-is-a-webhook-and-how-does-it-work) is useful context.

## 4. Appwrite

![Appwrite (Cloud)](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/76ebe651-2d3d-4f8f-9da6-59c0c7ae9e74/backend-as-a-service-examples-aws-amplify.jpg)

[Appwrite](https://appwrite.io/) sits in a useful middle ground. It gives you databases, auth, storage, functions, and webhooks in one consistent API surface, and it keeps the self-hosting door open. That combination matters for teams that want a managed service now but don't want to bet everything on one hosted provider forever.

Compared with Firebase or Amplify, Appwrite feels more unified out of the box. Compared with Supabase, it feels less centered on SQL-first workflows and more centered on a broad backend toolkit.

### Why teams pick it

Appwrite is attractive when you want one backend product that covers common app features without forcing you into a giant cloud ecosystem. The cloud product also adds operational features like observability and spending controls, which can be helpful for agencies or startups trying to avoid billing surprises.

There's a practical trade-off, though. Appwrite is broad, but broad products need careful sizing. Functions, builds, and storage patterns still require design decisions once your traffic stops being trivial.

- **Unified API feel:** Less stitching across separate vendor products.
- **Self-host parity:** You can move to your own infrastructure without rewriting the app around a different backend abstraction.
- **Not the best fit for SQL-heavy modeling:** If deep relational querying is central, Supabase or another Postgres-first option may feel cleaner.

### Plain HTML example posting to an Appwrite function endpoint

```html
<form action="https://cloud.appwrite.io/v1/functions/YOUR_FUNCTION_ID/executions" method="post">
  <input type="text" name="name" placeholder="Name" required />
  <input type="email" name="email" placeholder="Email" required />
  <textarea name="message" placeholder="Message" required></textarea>
  <button type="submit">Send</button>
</form>
```

In practice, development teams typically won't submit directly like this without auth headers or a client SDK. But architecturally, that's the model you're buying: frontend clients talking to hosted backend primitives without your own custom server sitting in the middle.

## 5. Nhost

![Nhost](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/72adb772-6fb9-4aeb-9df1-7917ac050397/backend-as-a-service-examples-appwrite-platform.jpg)

[Nhost](https://nhost.io/) is the choice for teams that want GraphQL front and center. It combines Postgres, Hasura, auth, storage, and functions into a stack that feels very good when your client app expects GraphQL subscriptions, roles, and generated operations from day one.

That's a narrower fit than Firebase or Supabase, but it's a real one. If your frontend already uses GraphQL heavily, Nhost can remove a lot of backend assembly work.

### Strong when GraphQL is a feature, not a preference

Some teams say they want GraphQL when they really just want an API. That's not the same thing. Nhost is worth it when GraphQL shapes how you build, test, and ship the product.

Its role-based approach can be productive, but GraphQL systems need discipline. You still have to think about permission boundaries, query complexity, and how much logic belongs in database actions versus functions.

> Teams that already understand Hasura patterns usually get value from Nhost quickly. Teams that don't may spend the first phase learning the stack instead of shipping.

### React example with a GraphQL mutation

```jsx
import { useState } from "react";

export default function ContactMutation() {
  const [form, setForm] = useState({ name: "", email: "", message: "" });

  async function handleSubmit(e) {
    e.preventDefault();

    await fetch("https://YOUR_NHOST_SUBDOMAIN.nhost.run/v1/graphql", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-hasura-admin-secret": "YOUR_ADMIN_SECRET"
      },
      body: JSON.stringify({
        query: `
          mutation InsertMessage($name: String!, $email: String!, $message: String!) {
            insert_contact_messages_one(object: {
              name: $name,
              email: $email,
              message: $message
            }) {
              id
            }
          }
        `,
        variables: form
      })
    });
  }

  return (
    <form onSubmit={handleSubmit}>
      <input onChange={(e) => setForm({ ...form, name: e.target.value })} placeholder="Name" />
      <input onChange={(e) => setForm({ ...form, email: e.target.value })} type="email" placeholder="Email" />
      <textarea onChange={(e) => setForm({ ...form, message: e.target.value })} placeholder="Message" />
      <button type="submit">Submit</button>
    </form>
  );
}
```

For public browser use, you'd route this through proper auth or a controlled backend layer. The example shows the shape of the workflow, not the final security posture.

## 6. Back4App

![Back4App (Managed Parse)](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/892ac775-86f8-4373-9639-f67b905ca41c/backend-as-a-service-examples-nhost-dashboard.jpg)

[Back4App](https://www.back4app.com/) is managed Parse Server, which means it brings an older BaaS model that still works fine for a lot of CRUD-heavy apps. If you've used Parse before, the appeal is obvious. You get managed hosting, dashboard tooling, backups, scaling help, and the option to keep a path back to self-hosted Parse.

This won't feel as modern as Supabase or as ecosystem-rich as Firebase. But that doesn't make it a bad choice. It makes it a specific one.

### Where Parse still makes sense

Back4App is useful when your team likes a schema-driven backend with classes, ACLs, roles, and cloud code. It's also a reasonable landing spot for legacy Parse apps that don't need a ground-up rewrite.

The limitation is mostly architectural taste and future fit. Parse conventions can feel dated compared with newer SQL or edge-function-first stacks, and you may need other services for analytics or specialized realtime patterns.

- **Good for CRUD-heavy products:** Content apps, simple SaaS dashboards, and internal tools can fit well.
- **Migration flexibility:** Managed hosting plus self-host path reduces hard lock-in.
- **Not the best modern default:** Newer teams often prefer SQL-native or cloud-native workflows.

### JavaScript example with Parse SDK

```html
<script src="https://npmcdn.com/parse/dist/parse.min.js"></script>
<script>
  Parse.initialize("YOUR_APP_ID", "YOUR_JS_KEY");
  Parse.serverURL = "https://parseapi.back4app.com/";

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

    const ContactMessage = Parse.Object.extend("ContactMessage");
    const entry = new ContactMessage();

    entry.set("name", document.getElementById("name").value);
    entry.set("email", document.getElementById("email").value);
    entry.set("message", document.getElementById("message").value);

    await entry.save();
    alert("Saved");
  }
</script>

<form onsubmit="submitContactForm(event)">
  <input id="name" type="text" required placeholder="Name" />
  <input id="email" type="email" required placeholder="Email" />
  <textarea id="message" required placeholder="Message"></textarea>
  <button type="submit">Send</button>
</form>
```

If you inherited a Parse app, Back4App is often the shortest path to getting it under control without rebuilding the backend from scratch.

## 7. Static Forms

You ship a JAMstack marketing site on Friday, then someone asks for a contact form, file upload, spam filtering, and Slack notifications by Monday. In that situation, a full backend is usually the wrong tool. Static Forms fits because it handles a narrow job well: receiving form submissions from static sites without forcing you to stand up a database, auth layer, or server code.

That narrower scope is why it belongs in a BaaS roundup. A lot of backend as a service examples are really application platforms. Static Forms is a specialized service, and that distinction matters if you are building with React, Vue, Astro, Next.js static export, or plain HTML on the JAMstack.

### Best when forms are the backend

For brochure sites, docs sites, portfolios, waitlists, lead-gen pages, and small client projects, the backend requirement is often simple. Accept a POST request, block obvious spam, send notifications, store submissions, and give the team a way to export or forward data. Reaching for Firebase, Supabase, or Amplify for that job adds setup and maintenance you may never use.

Static Forms keeps the integration surface small. You get a submission endpoint that works with plain HTML and frontend frameworks, so it drops cleanly into existing static projects.

The practical parts are covered too:

- **Spam protection:** Supports reCAPTCHA v2/v3, Cloudflare Turnstile, Altcha, and honeypot fields; reCAPTCHA v3, Turnstile, and Altcha need the Starter plan or above.
- **GDPR handling:** Includes export, deletion, and consent-related controls.
- **Email delivery setup:** Custom-domain sending supports SPF, DKIM, and DMARC.
- **Integrations:** You can send submissions to email on any plan, to webhooks, Slack, Discord, and Telegram from the Starter plan up, and to Google Sheets, Notion, Airtable, and Mailchimp from Pro up.
- **File uploads:** From the Starter plan up, supports file uploads up to 4.5 MB per submission, counting every file plus the other fields.

The trade-off is straightforward. You get a fast path for forms, but you are not getting a general-purpose backend. No app database, no auth model, no relational queries, no server-side business logic beyond the form workflow itself.

### Plain HTML example

```html
<form action="https://api.staticforms.dev/submit" method="post">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

  <input type="text" name="name" placeholder="Your name" required />
  <input type="email" name="email" placeholder="Your email" required />
  <textarea name="message" placeholder="How can we help?" required></textarea>

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

This is the main appeal. A static site can submit directly without adding serverless functions just to relay form data.

### React example with AJAX submit

```jsx
import { useState } from "react";

export default function ContactForm() {
  const [status, setStatus] = useState("");

  async function handleSubmit(e) {
    e.preventDefault();
    const formData = new FormData(e.target);

    const response = await fetch("https://api.staticforms.dev/submit", {
      method: "POST",
      body: formData,
    });

    if (response.ok) {
      setStatus("Message sent");
      e.target.reset();
    } else {
      setStatus("Submission failed");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
      <input type="text" name="name" placeholder="Name" required />
      <input type="email" name="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <button type="submit">Send</button>
      <p>{status}</p>
    </form>
  );
}
```

For React teams, this works well when the form is part of a static landing page or content site and you want client-side feedback without introducing a separate API route. If you later need authenticated submissions, custom validation logic, or data joins with user records, this is usually where you outgrow the service and move to a broader backend.

### Vue example with file upload

```vue
<script setup>
import { ref } from 'vue'

const status = ref('')

async function submitForm(event) {
  const formData = new FormData(event.target)

  const response = await fetch('https://api.staticforms.dev/submit', {
    method: 'POST',
    body: formData
  })

  status.value = response.ok ? 'Uploaded and sent' : 'Submission failed'
}
</script>

<template>
  <form @submit.prevent="submitForm" enctype="multipart/form-data">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
    <input type="text" name="name" placeholder="Name" required />
    <input type="email" name="email" placeholder="Email" required />
    <input type="file" name="attachment" />
    <textarea name="message" placeholder="Project details" required></textarea>
    <button type="submit">Send</button>
    <p>{{ status }}</p>
  </form>
</template>
```

The Vue example shows the same pattern. Frontend-first integration, minimal moving parts, and no need to provision backend infrastructure for a basic workflow.

That makes Static Forms a good specialized choice for JAMstack projects, especially if the only dynamic feature is a form. If the site is becoming a product with users, dashboards, permissions, and application data, choose a full-stack BaaS instead. If the project just needs reliable submissions and clean integrations, a focused service is often the better engineering decision.

For a concrete implementation walkthrough, see this guide to [sending form submissions to email](https://www.staticforms.dev/blog/form-submission-to-email).

## Top 7 BaaS Platforms Comparison

| Service | Implementation complexity | Resource requirements | Expected outcomes | Ideal use cases | Key advantages |
|---|---:|---|---|---|---|
| Firebase (Google) | Low–Medium (polished SDKs, minimal setup) | Fully managed Google infrastructure; may increase Cloud billing | Global real-time sync, offline support, analytics & messaging | Real-time mobile/web apps, rapid prototypes, teams extending into Google Cloud | Mature SDKs/docs, global scale, tight Google Cloud integration |
| Supabase | Medium (requires SQL/DB knowledge) | Managed Postgres; moderate compute; self-host option available | SQL-based data modeling with REST/GraphQL APIs and RLS security | Teams needing full SQL, portability, and predictable data models | Open-source core, Postgres + RLS, easy to self-host |
| AWS Amplify | Medium–High (AWS concepts and tooling) | Uses AWS services (Cognito, AppSync, Lambda, S3); requires AWS familiarity | Enterprise-grade backends with fine-grained service control and scaling | Organizations already on AWS or requiring enterprise compliance | Deep AWS ecosystem integration and clear upgrade path to enterprise |
| Appwrite (Cloud) | Low–Medium (unified API surface) | Managed all-in-one backend with hosting/observability; can self-host | Unified backend API, hosting, observability and budget controls | Teams wanting an all-in-one API and option to self-host | Transparent limits/pricing, self-host parity, bundled observability |
| Nhost | Medium (GraphQL/Hasura patterns) | Managed Postgres + Hasura; includes observability; moderate compute | GraphQL-first CRUD/realtime backed by Postgres, optional AI tooling | GraphQL-first teams needing strong Postgres integration and observability | Tight Hasura+Postgres integration, clear pricing, AI/pgvector options |
| Back4App (Managed Parse) | Low (schema-driven Parse model) | Managed Parse Server with autoscaling and backups; migration support | Schema-driven BaaS with dashboard, cloud code and managed ops | Teams familiar with Parse wanting managed operations or migration path | Mature Parse ecosystem, easy free-to-scale path, self-host mobility |
| Static Forms | Very Low (drop-in endpoint) | Hosted single endpoint; minimal ops; file uploads from Starter, limited in size | Instant form handling: email/dashboard storage, CSV export, integrations | Static/JAMstack sites, agencies, freelancers needing simple forms | Zero-backend setup, broad builder support, multi-destination routing |

## Making the Call Which BaaS Is Right for You

A lot of teams overbuy backend infrastructure.

If your product needs auth, permissions, stored application data, background jobs, and room to grow, choose a full-stack BaaS that fits how your team already works. Firebase is still a practical pick for realtime apps and mobile-heavy products. Supabase fits teams that want Postgres, SQL, and fewer portability concerns later. Amplify makes more sense when AWS is already the default for security, deployment, and compliance decisions.

That decision gets simpler if you frame it around ownership. A full-stack BaaS gives you one place to handle data, auth, storage, and server logic, but it also pulls more of your application architecture into that platform's model. Specialized services do less, which is often the point. For JAMstack projects, that trade-off matters. A React or Vue frontend may only need one backend capability, not an entire backend stack.

Form handling is the clearest example. Contact forms, lead capture, quote requests, event signups, and intake flows do not always justify standing up auth rules, database tables, and functions just to receive a POST request and route the result somewhere useful.

That is where a narrower tool earns its keep. Static Forms covers the form backend job directly: submission handling, spam filtering, file uploads and webhook delivery (Starter and up), email notifications, exports, and custom-domain email setup (Pro and up). For a static site, that usually means less code to maintain and fewer failure points than wiring a general BaaS into a feature that only needs reliable form submission.

If your site just needs forms that work, Static Forms is one of the fastest paths I'd consider. You can post to a hosted endpoint from plain HTML or from framework code in React, Next.js, Vue, Astro, Webflow, or WordPress, then add integrations and delivery rules later without rebuilding the rest of the stack.

---

## The Best Form Backends for Hugo and Jekyll in 2026

Source: https://www.staticforms.dev/blog/best-form-backends-hugo-jekyll  
Date: 2026-06-14  
Author: Static Forms Team

Hugo and Jekyll generate static sites with no server behind them. That's exactly why they're fast and cheap to host — and exactly why a plain `<form>` has nowhere to send its data. To make contact forms work, you point them at a *form backend*: a hosted endpoint that receives the submission, blocks spam, and emails it to you (or forwards it onward).

There are a handful of ways to do this, and they're not equal for static sites built with Hugo or Jekyll. This guide walks through the realistic options, what each is good and bad at, and how to pick.

## What a form backend actually has to do

Before comparing options, it helps to be clear about the job. For a Hugo or Jekyll site, a good form backend needs to:

- **Accept a submission from a purely static page** — no server-side code on your side.
- **Filter spam** without forcing a clunky CAPTCHA on every visitor.
- **Deliver reliably to email**, with a usable reply-to address.
- **Optionally route data elsewhere** — a spreadsheet, Slack, a webhook.
- **Not lock you in** — your form is just HTML posting to a URL, so switching should be trivial.

<div style="border:1px solid #e2e8f0;border-radius:12px;padding:24px;margin:28px 0;background:#f8fafc;color:#0f172a;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif"><div style="font-weight:700;font-size:15px;margin-bottom:18px;text-align:center;letter-spacing:-0.01em">Which approach fits your static site?</div><div style="display:flex;flex-direction:column;gap:10px"><div style="display:flex;gap:12px;align-items:flex-start;border:1px solid #cbd5e1;border-radius:10px;padding:12px 14px;background:#ffffff"><div style="font-size:20px">🔌</div><div><div style="font-weight:600;font-size:13px">Hosted form backend (recommended)</div><div style="font-size:12px;color:#64748b;margin-top:3px">Post HTML to an endpoint. Zero server, spam filtering and email built in. Best fit for Hugo &amp; Jekyll.</div></div></div><div style="display:flex;gap:12px;align-items:flex-start;border:1px solid #cbd5e1;border-radius:10px;padding:12px 14px;background:#ffffff"><div style="font-size:20px">🏗️</div><div><div style="font-weight:600;font-size:13px">Host-bundled forms</div><div style="font-size:12px;color:#64748b;margin-top:3px">Convenient if you stay on one host — but ties your form to that platform.</div></div></div><div style="display:flex;gap:12px;align-items:flex-start;border:1px solid #cbd5e1;border-radius:10px;padding:12px 14px;background:#ffffff"><div style="font-size:20px">⚙️</div><div><div style="font-weight:600;font-size:13px">Roll your own serverless function</div><div style="font-size:12px;color:#64748b;margin-top:3px">Maximum control, but you own deliverability, spam, and maintenance.</div></div></div><div style="display:flex;gap:12px;align-items:flex-start;border:1px solid #fca5a5;border-radius:10px;padding:12px 14px;background:#fef2f2"><div style="font-size:20px">📧</div><div><div style="font-weight:600;font-size:13px">mailto: link</div><div style="font-size:12px;color:#64748b;margin-top:3px">No backend at all — but it's not really a form. Avoid for anything real.</div></div></div></div></div>

## Option 1: A hosted form backend (best fit for most sites)

This is the approach built for exactly this problem. You add a normal HTML form to your Hugo partial or Jekyll include, set the `action` to a hosted endpoint, and you're done. The service receives the POST, screens it for spam, and emails you the message.

**Why it suits Hugo and Jekyll:** there's nothing to deploy or maintain on your end, it works identically on every host, and your form stays portable — it's just markup pointing at a URL.

[Static Forms](https://www.staticforms.dev) is built around this model. A working form is a single HTML block:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="text" name="name" required />
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>
  <input type="text" name="honeypot" style="display:none" tabindex="-1" />
  <button type="submit">Send</button>
</form>
```

The `honeypot` field catches the bulk of spam bots without a CAPTCHA, `replyTo="@"` makes the submitter's address your reply-to, and there's a free tier to start. On paid plans you can also forward submissions to [Slack](https://www.staticforms.dev/integrations/slack) or any endpoint via [webhooks](https://www.staticforms.dev/integrations/webhooks) (Starter and up), or to a [Google Sheet](https://www.staticforms.dev/integrations/google-sheets) (Pro and up). Other hosted backends in this category include Formspree, Getform, Basin, and Web3Forms — the model is similar across them, so the differentiators are spam handling, deliverability, integrations, and pricing.

**Best for:** almost any Hugo or Jekyll site. It's the lowest-effort option that still does the job properly.

## Option 2: Forms bundled with your host

Some static hosts bundle a form-handling feature — Netlify Forms is the best-known example, and Cloudflare and others have their own takes. You add an attribute or special markup, and the host intercepts submissions during the build or at the edge.

**The upside:** it's convenient if you're already on that host and never plan to leave. **The catch:** your form is now coupled to the platform. Move your Hugo or Jekyll site to a different host and the form stops working until you rewire it. There are also usually tight limits on submissions before you hit a paid tier.

**Best for:** sites firmly committed to one host, with light form volume.

## Option 3: Your own serverless function

If you want total control, you can write a small serverless function — on Vercel, Cloudflare Workers, AWS Lambda, or similar — that receives the POST, sends an email through a provider, and screens for spam. Your Hugo or Jekyll form posts to that function's URL.

**The upside:** you own the whole pipeline and can do anything. **The cost:** you now own *everything* — email deliverability (and the SPF/DKIM headaches that come with it), spam filtering, error handling, and ongoing maintenance. For a contact form, that's a lot of surface area to babysit.

**Best for:** teams with specific custom logic and the appetite to maintain it.

## Option 4: A plain mailto: link (not really a form)

The zero-backend "solution" is a `mailto:` link or a form with `action="mailto:..."`. It opens the visitor's email client instead of submitting anywhere.

In practice it's a poor experience: it depends on the visitor having a configured desktop mail client, exposes your address to scrapers, and captures nothing structured. It's fine as a fallback link, not as your contact form.

**Best for:** a quick "email me" link — not a real contact form.

## Feature comparison at a glance

Here's how the four approaches stack up on the things that actually matter for a Hugo or Jekyll site:

| | Hosted backend | Host-bundled | Own serverless | mailto: |
|---|---|---|---|---|
| **Server code to maintain** | None | None | Yes — you own it | None |
| **Works on any host** | ✅ | ❌ tied to host | ✅ | ✅ |
| **Built-in spam filtering** | ✅ | Partial | You build it | ❌ |
| **Email delivery handled** | ✅ | ✅ | You configure SPF/DKIM | N/A |
| **Route to Sheets / Slack / webhooks** | ✅ | Limited | You build it | ❌ |
| **Captures structured data** | ✅ | ✅ | ✅ | ❌ |
| **Setup time** | Minutes | Minutes | Hours+ | Minutes |
| **Portable (just HTML)** | ✅ | ❌ | Mostly | ✅ |

The pattern is clear: a hosted backend gives you the least to maintain while still ticking every box that matters. The host-bundled option trades portability for convenience, and rolling your own trades time and maintenance for control.

## What about spam?

Spam is the number-one reason a naive contact form becomes unusable, so it deserves its own look. A static site can't run server-side filtering on its own, which leaves three layers worth understanding:

- **Honeypot fields.** A hidden input that humans never fill but bots do. It's invisible to visitors, requires no extra clicks, and catches the bulk of automated spam. Every example in our Hugo and Jekyll tutorials includes one.
- **Server-side screening.** A good hosted backend scores submissions and drops obvious junk before it ever reaches your inbox — something a `mailto:` link or a bare serverless function won't do unless you build it.
- **CAPTCHA, only when needed.** If sophisticated spam slips through, you can add a challenge like reCAPTCHA, Cloudflare Turnstile, or Altcha. The trick is to treat it as a fallback rather than a default, since every CAPTCHA adds friction for real visitors.

The right order is honeypot first, server-side screening always, and a CAPTCHA only if the first two aren't enough.

## How to choose

For the large majority of Hugo and Jekyll sites, a **hosted form backend (Option 1)** is the right answer: it matches the static-site model exactly, requires no infrastructure, and keeps your form portable across hosts. Reach for a host-bundled option only if you're locked to one platform anyway, or a custom serverless function only when you genuinely need custom logic and will maintain it.

If you want to see the hosted approach end to end, we have step-by-step tutorials for [Jekyll on GitHub Pages](https://www.staticforms.dev/blog/jekyll-contact-form-github-pages) and [Hugo](https://www.staticforms.dev/blog/hugo-contact-form-tutorial), plus a general primer on [sending form data without a server](https://www.staticforms.dev/blog/html-form-send-email-without-server).

## Switching is painless

One underrated advantage of the hosted approach: there's almost nothing to migrate. Your form is just an HTML `<form>` with an `action` URL and a few hidden fields. Moving from one backend to another — or moving your whole Hugo or Jekyll site to a new host — means changing the endpoint URL and the key, and nothing else. Compare that to a host-bundled solution, where leaving the host means rebuilding form handling from scratch, or a custom serverless function, where the whole pipeline moves with you. Keeping the form as portable markup is the safest long-term bet for a static site.

## Frequently asked questions

**Do I need to know any backend programming?**
No. With a hosted backend your only job is to write the HTML form and point it at an endpoint. The server-side work is handled for you.

**Will a form backend slow down my static site?**
No. The form is static HTML that loads with the page. The backend only does work when someone actually submits, and that request goes directly from the visitor's browser to the API — your site stays as fast as ever.

**Can I use the same backend for Hugo and Jekyll?**
Yes. The approach is identical across static site generators — only the templating (a Hugo partial vs. a Jekyll include) differs. The form markup and endpoint are the same.

**Is there a free option?**
Yes — Static Forms has a free plan that's plenty for a typical contact form. You can see the limits and paid tiers on the [pricing page](https://www.staticforms.dev/pricing).

## Wrapping up

A static site doesn't mean a static contact page. The cleanest way to make forms work on Hugo and Jekyll is to keep the form as plain HTML and let a hosted backend do the server-side work — so you keep the speed and simplicity that made you choose a static generator in the first place.

[Start free with Static Forms](https://www.staticforms.dev) and have a working form on your site in a few minutes.

---

## How to Add a Contact Form to a Hugo Site (No Backend Required)

Source: https://www.staticforms.dev/blog/hugo-contact-form-tutorial  
Date: 2026-06-14  
Author: Static Forms Team

Hugo builds blazing-fast static sites in seconds, which is exactly why it's a favorite for blogs, docs, and marketing sites. But that speed comes from generating plain HTML at build time — there's no running server to catch a form submission. So the first time a visitor wants to email you through a contact page, you hit a wall: Hugo has no built-in way to process forms.

The clean solution is to post your form to a form backend that handles validation, spam filtering, and email delivery for you. In this tutorial you'll add a working contact form to a Hugo site using the [Static Forms form backend](/), package it as a reusable partial and shortcode, and wire it up so it works with any theme — including popular ones like PaperMod and Ananke.

## Why Hugo needs a form backend

Hugo's whole model is "render everything ahead of time." When someone hits your site, they're downloading static files from a CDN — fast and secure, but with nothing on the other end to receive a `POST`. A form backend fills that gap by giving you a single endpoint to submit to. Hugo's job is just to render the `<form>`; the backend does the rest.

<div style="border:1px solid #e2e8f0;border-radius:12px;padding:24px;margin:28px 0;background:#f8fafc;color:#0f172a;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif"><div style="font-weight:700;font-size:15px;margin-bottom:20px;text-align:center;letter-spacing:-0.01em">One partial, reused everywhere</div><div style="display:flex;flex-wrap:wrap;align-items:center;justify-content:center;gap:14px"><div style="border:1px dashed #94a3b8;border-radius:10px;padding:14px 16px;background:#ffffff;text-align:center;min-width:150px"><div style="font-weight:600;font-size:13px">layouts/partials/<br/>contact-form.html</div><div style="font-size:12px;color:#64748b;margin-top:6px">Define the form once</div></div><div style="color:#7c3aed;font-weight:700;font-size:22px">→</div><div style="display:flex;flex-direction:column;gap:8px"><div style="border:1px solid #cbd5e1;border-radius:8px;padding:8px 12px;background:#ffffff;font-size:12px;text-align:center">Contact page</div><div style="border:1px solid #cbd5e1;border-radius:8px;padding:8px 12px;background:#ffffff;font-size:12px;text-align:center">Footer</div><div style="border:1px solid #cbd5e1;border-radius:8px;padding:8px 12px;background:#ffffff;font-size:12px;text-align:center">Any blog post (shortcode)</div></div><div style="color:#7c3aed;font-weight:700;font-size:22px">→</div><div style="border:1px solid #cbd5e1;border-radius:10px;padding:14px 16px;background:#ffffff;text-align:center;min-width:140px"><div style="font-size:22px">📬</div><div style="font-weight:600;font-size:13px;margin-top:4px">Static Forms API</div><div style="font-size:12px;color:#64748b;margin-top:4px">→ your inbox</div></div></div></div>

## Prerequisites

You'll need:

- A Hugo site (any theme) that builds locally with `hugo server`
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## Step 1: Store your API key in site config

Keep the key in one place so you never hard-code it across templates. Add it to `hugo.toml` (or `config.toml` on older Hugo versions):

```toml
[params]
  staticFormsKey = "YOUR_API_KEY_HERE"
```

This is a public form key — it ships in your site's HTML like any client-side form field. It only authorizes submissions to your account, so it's safe to commit.

## Step 2: Create a reusable partial

Hugo partials are the equivalent of includes. Create `layouts/partials/contact-form.html`:

```go-html-template
<form action="https://api.staticforms.dev/submit" method="POST" class="contact-form">
  <input type="hidden" name="apiKey" value="{{ .Site.Params.staticFormsKey }}" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="hidden" name="subject" value="New message from {{ .Site.Title }}" />

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

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

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <!-- Honeypot: hidden from people, irresistible to bots -->
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />

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

The key fields:

- **`apiKey`** pulls your key from site config and routes the submission to your account.
- **`replyTo`** set to `@` uses the visitor's email as the reply-to address, so you reply right from your inbox.
- **`honeypot`** silently drops bot submissions — bots fill every field, humans never see this one.

## Step 3: Add a contact page

Create `content/contact.md`. Hugo doesn't render raw HTML inside Markdown by default, so the cleanest approach is to call the partial from a template. If your theme has a single-page layout you can extend, add the partial there; the most portable route is a dedicated layout. Create `layouts/page/contact.html`:

```go-html-template
{{ define "main" }}
  <article>
    <h1>{{ .Title }}</h1>
    {{ .Content }}
    {{ partial "contact-form.html" . }}
  </article>
{{ end }}
```

Then set the layout in the page's front matter:

```yaml
---
title: "Contact"
layout: "contact"
---

Have a question? Drop me a line below.
```

## Step 4: Use it anywhere with a shortcode

To let yourself (or other authors) embed the form inside any Markdown post, wrap the partial in a shortcode. Create `layouts/shortcodes/contact.html`:

```go-html-template
{{ partial "contact-form.html" . }}
```

Now any content file can include the form inline:

```markdown
Want to work together?

{{</* contact */>}}
```

## Step 5: Theme-specific notes

The partial works with any theme, but a couple of popular ones have a natural home for it:

- **PaperMod** — PaperMod ships with a `single.html` layout. The simplest path is the dedicated `layouts/page/contact.html` above, which overrides the theme for just that page. Don't edit files inside `themes/` directly; put your overrides in your project's root `layouts/` so theme updates don't clobber them.
- **Ananke** — Ananke renders page content through `.Content`. The dedicated layout approach works the same way. If you'd rather keep everything in Markdown, enable raw HTML by adding `[markup.goldmark.renderer]` with `unsafe = true` to your config — but the partial-and-shortcode approach keeps your content clean and avoids that flag.

## Step 6: Build, deploy, and test

Run your normal build and deploy — Hugo sites work the same on Netlify, Cloudflare Pages, GitHub Pages, or any static host:

```bash
hugo --minify
```

Open your contact page on the deployed site and send a test message. The first submission triggers a one-time verification email from Static Forms — click the link, and every submission afterward flows straight to your inbox.

By default the API returns a plain success response. To send visitors to a thank-you page instead, add a redirect field to the partial:

```go-html-template
<input type="hidden" name="redirectTo" value="{{ .Site.BaseURL }}thank-you/" />
```

The full field reference lives in the [Static Forms documentation](https://www.staticforms.dev/docs/html).

## Step 7: Style the form to match your theme

The partial inherits your theme's styles, but a contact form usually deserves a bit of intention. Add a stylesheet at `assets/css/contact-form.css` and pull it into your form layout, or drop the rules into your theme's main stylesheet:

```css
.contact-form {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  max-width: 32rem;
}

.contact-form input,
.contact-form textarea {
  width: 100%;
  padding: 0.65rem 0.75rem;
  font: inherit;
  border: 1px solid #cbd5e1;
  border-radius: 6px;
}

.contact-form input:focus,
.contact-form textarea:focus {
  outline: 2px solid #7c3aed;
  outline-offset: 1px;
  border-color: transparent;
}

.contact-form button {
  align-self: flex-start;
  padding: 0.65rem 1.25rem;
  font: inherit;
  font-weight: 600;
  color: #fff;
  background: #7c3aed;
  border: none;
  border-radius: 6px;
  cursor: pointer;
}
```

If you're on a recent Hugo with the asset pipeline, fingerprint and link it from your form layout:

```go-html-template
{{ with resources.Get "css/contact-form.css" | minify | fingerprint }}
  <link rel="stylesheet" href="{{ .RelPermalink }}" integrity="{{ .Data.Integrity }}" />
{{ end }}
```

## Submit without leaving the page (AJAX)

The plain form works with zero JavaScript. If you'd rather keep visitors on the page, submit with `fetch()`. Create a small script — for example `assets/js/contact-form.js` — and include it from your form layout:

```javascript
const form = document.querySelector('.contact-form');

form?.addEventListener('submit', async (event) => {
  event.preventDefault();
  const data = Object.fromEntries(new FormData(form).entries());

  try {
    const response = await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ ...data, replyTo: '@' }),
    });

    const result = await response.json();

    if (result.success) {
      form.outerHTML = '<p role="status">Thanks — your message is on its way!</p>';
    } else {
      throw new Error(result.message);
    }
  } catch {
    form.insertAdjacentHTML(
      'beforeend',
      '<p role="alert">Something went wrong. Please try again.</p>'
    );
  }
});
```

Because the `apiKey` is already a hidden field in the partial, `new FormData(form)` picks it up automatically — no need to repeat it in the script. The honeypot rides along in the payload too, so spam protection still applies.

## Multilingual contact forms

Hugo's first-class multilingual support is one of its biggest draws, and your contact form should follow suit. Move the user-facing strings into your i18n translation files (`i18n/en.toml`, `i18n/fr.toml`, and so on):

```toml
# i18n/en.toml
[contactName]
other = "Name"
[contactMessage]
other = "Message"
[contactSend]
other = "Send message"
```

Then reference them in the partial with the `i18n` function:

```go-html-template
<label for="name">{{ i18n "contactName" }}</label>
<input type="text" id="name" name="name" required />

<textarea name="message" placeholder="{{ i18n "contactMessage" }}" required></textarea>
<button type="submit">{{ i18n "contactSend" }}</button>
```

The same single endpoint handles every language — only the labels change. You can even set a per-language email subject so you know which site version a message came from.

## Going further

- **Spreadsheets and tools.** Forward submissions to a sheet with the [Google Sheets integration](https://www.staticforms.dev/integrations/google-sheets) (Pro plan and up), or send them anywhere via [webhooks](https://www.staticforms.dev/integrations/webhooks) (Starter plan and up).
- **AJAX submission.** Prefer an inline success message over a page navigation? Submit with `fetch()` — the pattern is the same one we use in the [JAMstack contact form guide](https://www.staticforms.dev/blog/jamstack-contact-form).
- **Other generators.** Using more than one static site generator? We have matching tutorials for [Astro](https://www.staticforms.dev/blog/astro-contact-form-tutorial) and other frameworks.

## Troubleshooting

The most common snags on a Hugo setup:

- **`partial "contact-form.html" not found`.** The partial must live at `layouts/partials/contact-form.html` in your project root (not inside `themes/`). Hugo resolves project-level layouts first, which is also how you safely override a theme.
- **Raw HTML in Markdown is being stripped.** Hugo's Goldmark renderer drops raw HTML by default for safety. That's why this guide uses a partial and a shortcode instead of pasting `<form>` into a `.md` file. If you must inline HTML, set `markup.goldmark.renderer.unsafe = true` in your config — but the partial approach is cleaner.
- **The form submits but no email arrives.** Confirm the `action` is exactly `https://api.staticforms.dev/submit` and your key is correct, then check for the one-time verification email (including spam) and click its link.
- **The shortcode prints literally instead of rendering.** Make sure you're using the shortcode syntax with percent or angle brackets — `{{</* contact */>}}` — and that the file is at `layouts/shortcodes/contact.html`.
- **Styles aren't applying.** If you use the asset pipeline snippet, confirm the CSS file is under `assets/` (not `static/`) — `resources.Get` only reads from `assets/`.

## Frequently asked questions

**Does this work with any Hugo theme?**
Yes. The partial and shortcode live in your project root, so they work regardless of theme and survive theme updates.

**Is the API key safe in the HTML?**
Yes — it's a public form key that only authorizes submissions to your account. It ships in the page source like any client-side form field and can't be used to read your data.

**Can I have more than one form on a site?**
Absolutely. Reuse the same partial anywhere, and set a different `subject` value per form so you can tell submissions apart in your inbox.

**What does it cost?**
A free plan covers typical personal and small-business use. For higher volume, file uploads, or advanced spam controls, see the [pricing page](https://www.staticforms.dev/pricing).

## Wrapping up

Hugo doesn't process forms, and it doesn't need to. Define the form once as a partial, expose it as a shortcode, and post to a form backend that handles validation, spam, and email. You keep Hugo's speed and simplicity, and your visitors get a contact form that just works — across every theme.

[Create a free Static Forms account](https://www.staticforms.dev) and add a contact form to your Hugo site today.

---

## How to Add a Contact Form to a Jekyll Site on GitHub Pages

Source: https://www.staticforms.dev/blog/jekyll-contact-form-github-pages  
Date: 2026-06-14  
Author: Static Forms Team

Jekyll is the static site generator that powers GitHub Pages, which is part of why it's so popular: push Markdown to a repo and your site is live. The catch shows up the moment you need a contact form. GitHub Pages serves static files only — there's no server to receive a POST request, no database to store a message, and no way to send an email. And because GitHub Pages runs Jekyll in `safe` mode, you can't install a Jekyll plugin to do it either.

The fix is to hand form submissions off to a form backend. In this tutorial you'll add a fully working contact form to a Jekyll site on GitHub Pages using [Static Forms](https://www.staticforms.dev), wrap it in a reusable Jekyll include, and have submissions land in your inbox — without writing or hosting any server code.

## Why Jekyll on GitHub Pages can't process forms

A traditional contact form posts to a script on your server that validates the data, stores or emails it, and returns a response. Jekyll produces only HTML, CSS, and JavaScript, and GitHub Pages serves those files as-is. There is no request handler at the other end of your `<form>`.

Here's what that submission path actually looks like once you route it through a form backend:

<div style="border:1px solid #e2e8f0;border-radius:12px;padding:24px;margin:28px 0;background:#f8fafc;color:#0f172a;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,sans-serif"><div style="font-weight:700;font-size:15px;margin-bottom:20px;text-align:center;letter-spacing:-0.01em">How a Jekyll form submission reaches your inbox</div><div style="display:flex;flex-wrap:wrap;align-items:stretch;justify-content:center;gap:12px"><div style="flex:1;min-width:130px;border:1px solid #cbd5e1;border-radius:10px;padding:14px;background:#ffffff;text-align:center"><div style="font-size:22px">📝</div><div style="font-weight:600;font-size:13px;margin-top:6px">Jekyll page</div><div style="font-size:12px;color:#64748b;margin-top:4px">Static HTML built by GitHub Pages</div></div><div style="display:flex;align-items:center;color:#7c3aed;font-weight:700;font-size:20px">→</div><div style="flex:1;min-width:130px;border:1px solid #cbd5e1;border-radius:10px;padding:14px;background:#ffffff;text-align:center"><div style="font-size:22px">🔌</div><div style="font-weight:600;font-size:13px;margin-top:6px">Static Forms API</div><div style="font-size:12px;color:#64748b;margin-top:4px">Validates, blocks spam, sends mail</div></div><div style="display:flex;align-items:center;color:#7c3aed;font-weight:700;font-size:20px">→</div><div style="flex:1;min-width:130px;border:1px solid #cbd5e1;border-radius:10px;padding:14px;background:#ffffff;text-align:center"><div style="font-size:22px">📬</div><div style="font-weight:600;font-size:13px;margin-top:6px">Your inbox</div><div style="font-size:12px;color:#64748b;margin-top:4px">Message arrives as email</div></div></div><div style="font-size:12px;color:#64748b;text-align:center;margin-top:18px">The browser POSTs the form directly to the API endpoint — GitHub Pages never has to run any code.</div></div>

## Prerequisites

Before you start, make sure you have:

- A Jekyll site deployed to GitHub Pages (or one you can build locally)
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## Step 1: Build the contact form

Jekyll renders Markdown, but it passes raw HTML straight through. So you can drop a standard form into any page or layout. Create a `contact.html` page at the root of your site:

```html
---
layout: default
title: Contact
permalink: /contact/
---

<h1>Get in touch</h1>

<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="hidden" name="subject" value="New message from my Jekyll site" />

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

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

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <!-- Spam honeypot: bots fill this, humans never see it -->
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />

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

That top block between the `---` lines is Jekyll front matter — it tells Jekyll to wrap the page in your `default` layout and serve it at `/contact/`. Replace `YOUR_API_KEY_HERE` with your real key.

A few fields are doing important work:

- **`apiKey`** routes the submission to your account.
- **`replyTo`** set to `@` tells Static Forms to use the submitter's own email as the reply-to address, so you can reply straight from your inbox.
- **`honeypot`** is a hidden field. Real visitors never see it, but spam bots fill in every field they find — so any submission with a value here is silently rejected.

## Step 2: Make it a reusable include

If you want the same form in your footer, your about page, and a dedicated contact page, copy-pasting the markup gets old fast. Jekyll includes solve this. Create `_includes/contact-form.html`:

```html
<form action="https://api.staticforms.dev/submit" method="POST" class="sf-form">
  <input type="hidden" name="apiKey" value="{{ site.staticforms_key }}" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="hidden" name="subject" value="{{ include.subject | default: 'New website message' }}" />

  <input type="text" name="name" placeholder="Your name" required />
  <input type="email" name="email" placeholder="Your email" required />
  <textarea name="message" placeholder="Your message" rows="5" required></textarea>
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />

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

Store the key once in `_config.yml` so it isn't scattered across files:

```yaml
staticforms_key: YOUR_API_KEY_HERE
```

Now drop the form anywhere with a single Liquid tag, optionally overriding the email subject per page:

```liquid
{% include contact-form.html subject="Contact form — pricing page" %}
```

Because the API key is published in your site's HTML either way (that's true of any client-side form), treat it as a public form key rather than a secret. It only authorizes submissions to your account's endpoint.

## Step 3: Commit, push, and test

GitHub Pages rebuilds automatically on every push to your publishing branch:

```bash
git add contact.html _includes/contact-form.html _config.yml
git commit -m "Add Static Forms contact form"
git push origin main
```

Give the build a minute, then open `/contact/` on your live site and send yourself a test message. The first time you submit, Static Forms emails you a confirmation link to verify the form — click it once and every submission after that flows straight to your inbox.

## Step 4: Send visitors to a thank-you page

By default the API returns a plain success response. For a Jekyll site you almost always want to send visitors to a friendly confirmation page instead. Add a `redirectTo` field pointing at a thank-you page you build in Jekyll:

```html
<input type="hidden" name="redirectTo" value="https://yourusername.github.io/thank-you/" />
```

Then create `thank-you.html` with `permalink: /thank-you/` and whatever message you like. The full list of supported fields is in the [Static Forms documentation](https://www.staticforms.dev/docs/html).

## Step 5: Style the form to match your theme

The default Jekyll theme (Minima) and most others give you sensible base styles, but a contact form usually wants a little polish. Add this to your `assets/css/style.scss` (or a `<style>` block in the include) to get clean, full-width fields:

```scss
.sf-form {
  display: flex;
  flex-direction: column;
  gap: 1rem;
  max-width: 32rem;
}

.sf-form input,
.sf-form textarea {
  width: 100%;
  padding: 0.65rem 0.75rem;
  font: inherit;
  border: 1px solid #cbd5e1;
  border-radius: 6px;
}

.sf-form input:focus,
.sf-form textarea:focus {
  outline: 2px solid #7c3aed;
  outline-offset: 1px;
  border-color: transparent;
}

.sf-form button {
  align-self: flex-start;
  padding: 0.65rem 1.25rem;
  font: inherit;
  font-weight: 600;
  color: #fff;
  background: #7c3aed;
  border: none;
  border-radius: 6px;
  cursor: pointer;
}

.sf-form button:hover {
  background: #6d28d9;
}
```

If you're using Minima, the file at `assets/css/style.scss` should start with the two `---` lines (an empty front matter block) followed by `@import "minima";` — add your rules after that import so they override the theme.

## Step 6: Submit without leaving the page (AJAX)

The plain form works everywhere and needs no JavaScript. But if you'd rather keep visitors on the page and show an inline success message, submit with `fetch()` instead. Static Forms accepts JSON and returns a `{ success: true }` response you can check:

```html
<form id="contact-form" class="sf-form">
  <input type="text" name="name" placeholder="Your name" required />
  <input type="email" name="email" placeholder="Your email" required />
  <textarea name="message" placeholder="Your message" rows="5" required></textarea>
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />
  <button type="submit">Send</button>
</form>

<p id="form-success" style="display:none">Thanks — your message is on its way!</p>
<p id="form-error" style="display:none">Something went wrong. Please try again.</p>

<script>
  const form = document.getElementById('contact-form');
  const successEl = document.getElementById('form-success');
  const errorEl = document.getElementById('form-error');

  form.addEventListener('submit', async (event) => {
    event.preventDefault();
    const data = Object.fromEntries(new FormData(form).entries());

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          ...data,
          apiKey: 'YOUR_API_KEY_HERE',
          replyTo: '@',
        }),
      });

      const result = await response.json();

      if (result.success) {
        form.style.display = 'none';
        successEl.style.display = 'block';
      } else {
        throw new Error(result.message);
      }
    } catch {
      errorEl.style.display = 'block';
    }
  });
</script>
```

Because Jekyll passes raw HTML and `<script>` blocks straight through, you can drop this directly into a page or an include. The honeypot still works in the AJAX version — its value rides along in the JSON payload.

## Make the form accessible

A contact form is often the only interactive element on an otherwise static site, so it's worth getting right for keyboard and screen-reader users:

- **Pair every input with a `<label>`** using `for`/`id`, as in Step 1. Placeholders are not a substitute for labels — they vanish on focus.
- **Keep the visible focus outline.** The CSS above uses a high-contrast outline rather than removing it.
- **Mark required fields** with the `required` attribute so the browser enforces them and announces them.
- **Announce success and errors.** If you use the AJAX version, add `role="status"` to the success message and `role="alert"` to the error message so screen readers read them out when they appear.

## Going further

Once the basics work, a few upgrades are worth knowing about:

- **Stop spam without a CAPTCHA.** The honeypot handles most bots. If you start seeing sophisticated spam, you can layer on a CAPTCHA — see our guide to [adding a contact form to GitHub Pages](https://www.staticforms.dev/blog/github-pages-contact-form-tutorial) for the no-framework version.
- **Route submissions somewhere other than email.** You can forward every submission to a spreadsheet with the [Google Sheets integration](https://www.staticforms.dev/integrations/google-sheets) (Pro plan and up), or pipe it into your other tools through [webhooks](https://www.staticforms.dev/integrations/webhooks) (Starter plan and up).
- **AJAX submit.** If you'd rather not navigate away, submit with `fetch()` and show an inline success message — as shown in Step 6, or in our [JAMstack contact form guide](https://www.staticforms.dev/blog/jamstack-contact-form).

## Troubleshooting

A few things trip people up on a Jekyll + GitHub Pages setup:

- **The form does nothing / the page reloads with no email.** Double-check the `action` URL is exactly `https://api.staticforms.dev/submit` and that you replaced `YOUR_API_KEY_HERE` with your real key. A typo in either silently fails.
- **No email arrives on the first try.** The first submission to a new form triggers a one-time verification email. Check the inbox for the address tied to your account (and the spam folder) and click the verification link.
- **Liquid is eating your markup.** If your form contains literal curly braces (for example in placeholder copy), wrap that section in `{% raw %}...{% endraw %}` so Jekyll's Liquid parser doesn't try to interpret it.
- **Changes aren't showing up.** GitHub Pages builds can take a minute or two, and browsers cache aggressively. Wait for the build to finish (check the Actions tab) and hard-refresh.
- **The include isn't found.** Jekyll includes must live in `_includes/` and be referenced by filename: `{% include contact-form.html %}`. A path prefix will break it.

For anything API-specific, the [debugging section of the docs](https://www.staticforms.dev/docs/html) lists the exact response codes the endpoint returns.

## Frequently asked questions

**Is my API key safe to put in the HTML?**
Yes. It's a public form key, not a secret — like any client-side form, the field ships in your page source. It only authorizes submissions to your account's endpoint and can't be used to read your data.

**Will this work on a custom domain?**
Yes. The form posts to the Static Forms API regardless of where your Jekyll site is hosted, so a custom domain on GitHub Pages works exactly the same.

**Do I need a Jekyll plugin?**
No — and that's the point. GitHub Pages runs Jekyll in `safe` mode and blocks third-party plugins, but this approach is pure HTML, so no plugin is involved.

**How much does it cost?**
There's a free plan that covers a typical personal or small-business contact form. If you need higher volume, file uploads, or advanced spam tools, see the [pricing page](https://www.staticforms.dev/pricing).

## Wrapping up

A Jekyll site on GitHub Pages can't process a form on its own — but it doesn't need to. By posting to a form backend you keep the speed and zero-maintenance hosting of static files while still giving visitors a working contact form. Build the form once as a Jekyll include, store your key in `_config.yml`, and reuse it across the whole site.

Ready to add yours? [Create a free Static Forms account](https://www.staticforms.dev) and grab your API key.

---

## What Is a Webhook and How Does It Work

Source: https://www.staticforms.dev/blog/what-is-a-webhook-and-how-does-it-work  
Date: 2026-06-11T09:19:44.681Z  
Author: Static Forms Team

You're probably dealing with this right now. Something happens in another system, a payment succeeds, a GitHub push lands, a form gets submitted, and your app needs to react right away.

The beginner solution is usually polling. Hit an API every few seconds, ask “anything new?”, then keep doing that forever. It works, but it's noisy, late, and wasteful when nothing changed. That's the gap webhooks fill.

## The Problem Webhooks Solve

A useful way to frame the problem is this: your system often depends on work that starts somewhere else.

A customer submits a form on your static site. A payment provider marks an invoice as paid. A teammate pushes code to GitHub and your deployment pipeline should react. In each case, your app is not creating the event. It is waiting for another system to say, "something happened, act on it now."

That waiting creates an architectural choice.

You can keep asking the other service for updates on a schedule, or you can let that service notify you when the event occurs. Polling can work, but it pushes a lot of responsibility onto the receiver. Your app has to keep checking, keep track of what it has already seen, and decide what changed since the last request.

That sounds simple at first. It rarely stays simple.

Once the integration matters to the business, the main problem is not just wasted requests. It is reliability. If your polling job runs late, you react late. If it fails between checks, you need a safe way to catch up. If the provider returns partial data or rate limits you, your "did anything change?" loop gets more complicated fast.

Webhooks shift that model. The system that knows an event happened sends an HTTP request to your app at the moment it happens. That turns the integration from repeated checking into event delivery.

> Webhooks are less about saving API calls and more about assigning responsibility to the system that has the freshest truth.

That shift matters most on the unhappy path. A production webhook flow has to answer questions polling tends to hide: What if the sender times out? What if it retries the same event three times? What if someone posts a fake payload to your endpoint? What if your app is down for a minute right when the event arrives?

Those are the problems worth solving early.

A webhook receiver is not just a URL that accepts POST requests. It is a small event ingestion system. It needs to verify who sent the request, return the right status code quickly, and handle duplicate deliveries without creating duplicate side effects like double emails, double CRM entries, or repeated deployment jobs. That is why teams use webhooks when they need systems to react quickly, but it is also why production-grade webhook handling needs more care than a toy demo suggests.

## Webhooks vs Polling The Core Concept

A good mental model is this:

Polling is like walking to your mailbox every few minutes to see if a letter arrived.

A webhook is like getting a text message the moment someone has something for you.

![An infographic comparing polling and webhooks for data retrieval, highlighting why webhooks are more efficient and instant.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/5b0768d6-b2c9-4bf3-813a-5ee2e5386d98/what-is-a-webhook-and-how-does-it-work-webhooks-vs-polling.jpg)

### What a webhook actually is

A **webhook** is best understood as a **push-based HTTP callback**. Instead of asking a server for updates repeatedly, the receiving system registers a URL and gets notified automatically when a specific event happens. That design makes webhooks event-driven and near real time because data moves only when something changes rather than on a fixed polling schedule, as explained in [Theneo's webhook overview](https://www.theneo.io/blog/understanding-webhooks-what-they-are-and-how-to-use-them).

In plain English, that means:

1. You expose a URL your app can receive requests on.
2. You tell another service to send event notifications to that URL.
3. When the event happens, that service sends you an HTTP request.
4. Your code handles it.

That's the whole core idea.

### Push versus pull

Here's the shortest useful comparison:

| Approach | Who starts the request | When data moves | Typical downside |
|---|---|---|---|
| **Polling** | Your app | On a schedule | You ask even when nothing changed |
| **Webhook** | The source system | When an event happens | You must run a public receiver |

Polling is still fine sometimes. If a provider doesn't support webhooks, or if you need to fetch a large dataset on a schedule, polling can be the right tool.

But if your question is “what is a webhook and how does it work?”, the answer starts with this distinction. A webhook flips the control flow. Your app stops asking and starts listening.

### A simple example

Suppose Stripe, GitHub, or your form backend supports a `payment_succeeded`, `push`, or `submission.created` event.

Without webhooks:
- your app checks every so often for new payments, commits, or submissions

With webhooks:
- the provider sends a POST request to your endpoint the moment that event occurs

> **Practical rule:** Use polling when you need to fetch data on demand. Use webhooks when your app needs to react to events as they happen.

## Anatomy of a Webhook A Look Under the Hood

A webhook works like a signed delivery arriving at your office. The package has a destination, labels on the outside, and a message inside. Your job is not just to open it. Your job is to confirm it came from the expected sender, record that it arrived, and avoid processing the same package twice if the courier shows up again.

That reliability angle matters because webhook delivery is not a single happy-path POST. In production, requests get retried, handlers time out, payloads arrive out of order, and bad actors can send lookalike requests to public endpoints.

![An infographic titled Anatomy of a Webhook explaining the three core components: Payload, Headers, and Endpoint URL.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/70e37085-f2df-471d-b911-7a208d902361/what-is-a-webhook-and-how-does-it-work-webhook-anatomy.jpg)

### The endpoint URL

The **endpoint** is the public HTTPS address that receives the event. Examples:

- `https://example.com/api/webhooks/github`
- `https://app.example.com/webhooks/payments`

This URL is the delivery address you register with the provider.

A good webhook endpoint stays stable. If you change the path, break TLS, add a redirect the provider will not follow, or deploy an app that sometimes hangs, deliveries start failing. That is why teams often isolate webhook routes from the rest of the app and keep them as boring as possible.

### The HTTP method and headers

Webhook requests are usually **HTTP POST** requests. The headers tell your receiver how to interpret the body and how to decide whether the request should be trusted.

Common header categories include:

- **`Content-Type`** for the payload format, often `application/json`
- **Event headers** such as the event name or type
- **Signature headers** used to verify the sender
- **Delivery ID headers** used to identify one delivery attempt or event message

A conceptual request looks like this:

- `POST /api/webhooks/github`
- `Content-Type: application/json`
- `X-Event-Name: push`
- `X-Signature: ...`
- `X-Delivery-Id: ...`

The exact names vary by provider, so the safe habit is simple. Read the provider docs. Map each header to a clear purpose in your code. Do not guess.

### The payload

The **payload** is the request body. It contains the event data your app will act on.

Usually it is JSON:

```json
{
  "event": "order.paid",
  "id": "evt_123",
  "createdAt": "2026-06-11T12:00:00Z",
  "data": {
    "orderId": "ord_456",
    "customerEmail": "dev@example.com"
  }
}
```

At first glance, that looks straightforward. Parse JSON, branch on `event`, run some code.

Real systems make it messier.

Some providers send a full object. Others send only an ID, and you fetch the latest state from their API. Some events arrive more than once because the sender retried after a timeout. Some arrive late, so `order.shipped` can reach you before `order.paid` if network delays or retries reshuffle delivery. Your handler has to cope with all of that without corrupting state.

### The response code is part of delivery

Your response is not a courtesy. It is part of the delivery protocol.

Providers usually treat a quick **2xx** response as acknowledgment. Anything else tells the sender the event may not have been handled successfully.

| Your response | What the sender usually assumes | Likely outcome |
|---|---|---|
| **2xx** | You accepted the event | Delivery marked successful |
| **4xx** | You rejected the request | Retry behavior depends on provider |
| **5xx** | Your server failed while handling it | Retry is common |
| **Timeout** | No acknowledgment arrived | Retry is common |

That retry behavior is where many webhook bugs begin. If your code creates an order, sends an email, or updates a subscription before it can safely detect duplicates, the same event can trigger the same side effect more than once.

### What a production-ready receiver actually does

A solid webhook handler usually follows this flow:

1. Receive the raw HTTP request.
2. Verify the signature using the raw body bytes.
3. Extract an event ID or delivery ID.
4. Check whether that event was already processed.
5. Store or queue the event for asynchronous work.
6. Return a `2xx` response quickly.
7. Process the business logic in a retry-safe way.

That order matters. Signature verification should happen before you trust the payload. Idempotency checks should happen before you trigger side effects. The acknowledgment should usually happen after the event is durably recorded, not after a long chain of downstream work.

A useful mental model is “ingest first, process second.” Your webhook endpoint is the front door, not the whole house. Its first job is to accept valid deliveries safely and consistently, even when your background workers or third-party dependencies are having a bad day.

If you remember one thing from this section, remember this: a webhook is not complete when a POST hits your server. It is complete when your system can verify it, acknowledge it correctly, and survive retries without doing the same work twice.

## Securing Your Webhooks From Payloads to Production

A webhook endpoint is a public door into your system. If someone can send requests to that door, your code needs a reliable way to tell a real provider delivery from a forged one.

That is the security problem webhooks introduce.

![A professional software developer analyzing secure code on a computer monitor in a modern home office.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/e37cc57d-6533-49b7-99d7-d524dbd55f3d/what-is-a-webhook-and-how-does-it-work-software-developer.jpg)

### Why signature verification matters

Start with the two questions your receiver must answer before it trusts any payload:

1. **Did the expected provider send this request?**
2. **Did the request body arrive unchanged?**

Providers usually answer both with an **HMAC signature**. They compute a digest from the raw request body and a shared secret, then send that digest in a header. Your server computes the same digest from the exact bytes it received and compares the two values with a timing-safe check.

If the values do not match, reject the request.

A practical analogy helps here. Signature verification works like checking the tamper seal on a package before you stock it in inventory. The package may look valid from the outside, but you still verify that it came from the expected sender and was not altered on the way.

### Why raw body handling breaks so many webhook integrations

This part trips up a lot of developers because the JSON looks identical in logs while the signature still fails.

A common failure path looks like this:

- your framework parses the JSON body automatically
- your code turns that parsed object back into a string
- the provider signed the original bytes, not your reconstructed version
- the signature check fails

Whitespace, key order, and encoding details can change the byte sequence without changing the visible data. That is why webhook verification usually has to run against the **raw body buffer** before normal JSON parsing.

> If the provider signs bytes, verify bytes.

### Timestamp checks and replay protection

A valid signature is not enough on its own. If an old request is captured somewhere along the route, it can be replayed later.

Many providers reduce that risk by signing a timestamp along with the body. Your receiver checks whether the timestamp falls inside a small acceptance window. If it is too old, reject the delivery even if the signature matches.

That protects against replay attacks. The payload may be real, but it is no longer safe to act on.

### Security and reliability meet at the same endpoint

Webhook security is not only about blocking fake requests. It is also about handling real requests safely when networks, queues, and downstream services fail.

A provider might send a legitimate event, wait for your acknowledgment, hit a timeout, and retry. Your endpoint now receives the same signed payload again. If your handler creates an order, sends an email, or posts a Slack alert every time it sees that event, one valid delivery can produce duplicate side effects.

That is why a production-ready receiver needs three protections working together:

- **Signature verification** so you only trust authenticated payloads
- **Replay protection** so stale deliveries are rejected
- **Idempotent processing** so retries do not repeat the same business action

This matters in small automations too, not only payment systems. If you are wiring form submissions into chat ops, a duplicated delivery can spam a channel or create duplicate support work. A practical pattern is to verify the webhook, store the event ID, then fan out the notification once. The same care applies when [sending form submissions to Slack](https://www.staticforms.dev/integrations/slack) through a webhook flow.

### A short production checklist

Use this checklist before you expose any webhook receiver to the internet:

- **Use HTTPS** so request data is encrypted in transit
- **Verify the provider signature** with the raw body
- **Check timestamps** if the provider includes them
- **Compare signatures with a timing-safe function**
- **Store event IDs or delivery IDs** to detect retries
- **Queue or persist the event before long-running work**
- **Keep signing secrets in environment variables or a secret manager**

The happy path is easy to demo. Critical work starts when the request is delayed, replayed, retried, or forged. That is the difference between a webhook example that works on localhost and one you can trust in production.

## Practical Use Cases From GitHub to Static Forms

Webhooks make the most sense when you tie them to workflows you already know.

A GitHub push can trigger a deployment. A payment success event can trigger fulfillment. A form submission can create a lead record and send a Slack message. The pattern is the same even though the payloads differ.

### GitHub, payments, and team notifications

A few common examples:

- **GitHub to CI/CD:** when someone pushes to a repository, GitHub sends a webhook that starts a build in Jenkins, GitHub Actions, or your deployment service
- **Payments to order processing:** when a payment provider confirms a charge, your app marks an order as paid and starts fulfillment
- **Slack or support workflows:** an incoming event gets transformed into a message, ticket, or audit log entry

If your team works across support and chat tools, this same model shows up in operational automations too — event notifications keep support tickets, chat channels, and internal systems in sync.

### Forms are events too

Developers sometimes think of webhooks as something only Stripe or GitHub uses. But forms are one of the simplest webhook sources.

A form submission is just an event:
- someone fills out fields
- the browser sends a POST request
- your backend or form service processes it
- optional downstream actions run after that

For static and JAMstack sites, this is especially useful because you often don't want to maintain a custom backend just to receive contact forms.

Here's a plain HTML example that posts to a realistic endpoint:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_STATIC_FORMS_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

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

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

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

And a React version:

```jsx
export default function ContactForm() {
  return (
    <form action="https://api.staticforms.dev/submit" method="POST">
      <input type="hidden" name="apiKey" value="YOUR_STATIC_FORMS_API_KEY" />
      <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

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

      <label>
        Email
        <input type="email" name="email" required />
      </label>

      <label>
        Message
        <textarea name="message" required />
      </label>

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

If you need spam protection on a public form, use a supported challenge such as **reCAPTCHA v2/v3**, **Cloudflare Turnstile**, **hCaptcha**, **ALTCHA**, or a **honeypot** (on Static Forms, everything except reCAPTCHA v2 and the honeypot needs Starter or above). If you accept uploads, keep the platform limit in mind. For Static Forms, uploads are available on Starter and up and capped at **4.5MB per submission**, counting every file plus the other fields. If you send mail from a custom domain, make sure **SPF, DKIM, and DMARC** are configured correctly.

### Where Static Forms fits

![Screenshot from https://www.staticforms.dev](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/6e232fe9-cc92-4db5-bfc7-9f0a9211c965/what-is-a-webhook-and-how-does-it-work-static-forms.jpg)

For static sites, **Static Forms** is one option that handles form submissions at `https://api.staticforms.dev/submit` and, on Starter and up, can route each submission to a generic webhook as JSON POST or to Slack, Discord, and Telegram, with Google Sheets, Notion, Airtable, and Mailchimp on Pro and up. If your goal is to turn frontend form events into downstream automations without building your own receiver first, their [Slack integration for form submissions](https://www.staticforms.dev/integrations/slack) is a useful concrete example.

## How to Build and Consume Webhooks Code Examples

A webhook integration feels simple right up until the first failure. Your payment provider sends `order.paid`, your endpoint times out after writing to the database, and a retry arrives 30 seconds later. If your handler is not verifying signatures or guarding against duplicates, you can ship the same order twice, send two emails, or corrupt state in ways that are hard to unwind.

That is why it helps to build both sides once. One sender. One receiver. One signed request. Then one failed delivery and one duplicate. Webhooks start to make sense when you see the full delivery path, not just the `POST` request that worked in a demo.

### Send a webhook with Node.js

Start with the producer side. A webhook sender packages an event, signs the exact bytes it will send, and treats any non-`2xx` response as a failed delivery that may need a retry.

This example signs the raw JSON payload with HMAC-SHA256 and sends it with a timestamp header.

```js
import crypto from "node:crypto";

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;
const WEBHOOK_URL = "https://example.com/api/webhooks/orders";

async function sendWebhook() {
  const payload = {
    id: "evt_order_paid_123",
    event: "order.paid",
    createdAt: new Date().toISOString(),
    data: {
      orderId: "ord_456",
      customerEmail: "dev@example.com"
    }
  };

  const rawBody = JSON.stringify(payload);
  const timestamp = Math.floor(Date.now() / 1000).toString();

  const signedContent = `${timestamp}.${rawBody}`;
  const signature = crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(signedContent)
    .digest("hex");

  const response = await fetch(WEBHOOK_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-Webhook-Timestamp": timestamp,
      "X-Webhook-Signature": signature
    },
    body: rawBody
  });

  const text = await response.text();
  console.log(response.status, text);
}

sendWebhook().catch(console.error);
```

A few details matter here:

- **Sign the raw string you send:** the receiver must verify the same bytes, in the same order
- **Include a timestamp:** this gives the receiver a replay window check
- **Use a stable event ID:** retries should carry the same ID so the consumer can deduplicate
- **Treat non-`2xx` responses as failed deliveries:** retries are normal webhook behavior

A mailing analogy helps here. The JSON body is the letter. The signature is the tamper-evident seal. The timestamp is the postmark. The event ID is the tracking number. If any of those are missing, the receiver has less context for deciding whether the message is authentic, fresh, and already handled.

### Receive and verify with Express

The receiver side is where production bugs usually show up. The job is not just “parse JSON and run business logic.” The job is to accept an event safely.

That means four steps, in order:

1. Read the raw request body
2. Verify the timestamp and signature
3. Check whether this event was already processed
4. Acknowledge quickly, then do slower work

This example captures the raw body, validates the timestamp, verifies the signature, checks for duplicates, then acknowledges receipt quickly.

```js
import express from "express";
import crypto from "node:crypto";

const app = express();
const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;

// Demo only. Replace with a database or persistent store.
const processedEventIds = new Set();

app.use(
  express.json({
    verify: (req, res, buf) => {
      req.rawBody = buf.toString("utf8");
    }
  })
);

function timingSafeEqual(a, b) {
  const aBuf = Buffer.from(a, "utf8");
  const bBuf = Buffer.from(b, "utf8");

  if (aBuf.length !== bBuf.length) return false;
  return crypto.timingSafeEqual(aBuf, bBuf);
}

app.post("/api/webhooks/orders", async (req, res) => {
  const signature = req.header("X-Webhook-Signature");
  const timestamp = req.header("X-Webhook-Timestamp");

  if (!signature || !timestamp || !req.rawBody) {
    return res.status(400).send("Missing signature data");
  }

  const timestampMs = Number(timestamp) * 1000;
  const age = Math.abs(Date.now() - timestampMs);

  // Example replay window. Tune for your provider and tolerance.
  if (Number.isNaN(timestampMs) || age > 5 * 60 * 1000) {
    return res.status(401).send("Stale webhook");
  }

  const signedContent = `${timestamp}.${req.rawBody}`;
  const expectedSignature = crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(signedContent)
    .digest("hex");

  if (!timingSafeEqual(signature, expectedSignature)) {
    return res.status(401).send("Invalid signature");
  }

  const event = req.body;
  const eventId = event.id;

  if (!eventId) {
    return res.status(400).send("Missing event ID");
  }

  if (processedEventIds.has(eventId)) {
    return res.status(200).send("Already processed");
  }

  processedEventIds.add(eventId);

  res.status(200).send("OK");

  try {
    switch (event.event) {
      case "order.paid":
        console.log("Process paid order:", event.data.orderId);
        break;
      default:
        console.log("Unhandled event:", event.event);
    }
  } catch (err) {
    console.error("Async processing failed:", err);
  }
});

app.listen(3000, () => {
  console.log("Listening on http://localhost:3000");
});
```

Two parts are easy to miss.

First, signature verification must use `req.rawBody`, not `JSON.stringify(req.body)`. Parsing and reserializing can change whitespace, key order, or encoding details. That breaks verification even when the sender is valid.

Second, the in-memory `Set()` is only a teaching aid. In a real app, duplicate protection belongs in durable storage, often with a unique constraint on the provider's event ID or delivery ID. If your process restarts, an in-memory set forgets everything and duplicate deliveries can slip through.

The response timing matters too. Return `200 OK` after you have validated the request and stored enough state to process it safely. Do not wait for email sends, third-party API calls, or long database workflows before acknowledging receipt. Slow handlers invite retries, and retries create duplicates unless your code expects them.

### A Next.js route handler example

The same rules apply in Next.js. Get the raw body first. Verify before trusting the payload. Then parse.

```js
import crypto from "node:crypto";

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET;

function verifySignature(rawBody, timestamp, signature) {
  const expected = crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(`${timestamp}.${rawBody}`)
    .digest("hex");

  const a = Buffer.from(signature, "utf8");
  const b = Buffer.from(expected, "utf8");

  if (a.length !== b.length) return false;
  return crypto.timingSafeEqual(a, b);
}

export async function POST(req) {
  const rawBody = await req.text();
  const timestamp = req.headers.get("x-webhook-timestamp");
  const signature = req.headers.get("x-webhook-signature");

  if (!timestamp || !signature) {
    return new Response("Missing headers", { status: 400 });
  }

  if (!verifySignature(rawBody, timestamp, signature)) {
    return new Response("Invalid signature", { status: 401 });
  }

  const event = JSON.parse(rawBody);

  // Do dedupe and async work here
  console.log("Received event:", event.event);

  return new Response("OK", { status: 200 });
}
```

If you are mentoring a junior dev on this handler, the key lesson is simple. Verification happens before trust. A request that looks like JSON is still just an untrusted HTTP request until the signature matches and the timestamp is within your allowed window.

### A Vue form that submits to a real endpoint

Not every webhook flow starts with your own backend. Sometimes the event begins as a plain HTML form submission, and a hosted service forwards that submission to your app or another tool.

On the sender side, forms are still just POST requests. Here's a Vue component using a hosted form endpoint:

```vue
<template>
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_STATIC_FORMS_API_KEY" />
    <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

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

    <label>
      Email
      <input type="email" name="email" required />
    </label>

    <label>
      Message
      <textarea name="message" required></textarea>
    </label>

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

If you want those submissions forwarded as webhook events, Static Forms does that from the Starter plan up and explains the setup in its [generic webhook integration docs for forwarding form submissions](https://www.staticforms.dev/integrations/webhooks).

The useful mental model is that the form service becomes the webhook producer, and your backend becomes the consumer. The same production rules still apply on your side. Verify where the platform supports verification. Store delivery identifiers. Make your handler idempotent. Expect retries.

## Troubleshooting and Best Practices for Reliability

Most webhook bugs aren't about the happy path. They're about retries, duplicates, timeouts, and handlers that did real work before returning an acknowledgment.

### Reliability checklist

- **Acknowledge fast:** return a `2xx` as soon as you've validated and safely accepted the event
- **Process asynchronously:** queue work or hand it off after acknowledgment when possible
- **Make handlers idempotent:** processing the same event twice should not create duplicate side effects
- **Store an event or delivery ID:** dedupe before doing writes or sending emails
- **Log headers and payload metadata:** don't log secrets, but do log enough to debug failures
- **Test with public URLs:** use a tunnel during local development so providers can reach your machine
- **Subscribe narrowly:** only receive the events your app uses

### The duplicate-delivery mindset

Retries aren't an edge case. They're part of normal webhook behavior.

If your server timed out after successfully writing to the database but before sending `200 OK`, the provider may resend the same event. If your code isn't idempotent, you'll run the same workflow twice.

> Build webhook consumers as if every event might be delivered more than once, because sometimes it will.

### A simple debugging flow

When a webhook “isn't working,” check these in order:

1. **Did the provider send the request?**
2. **Did your endpoint receive it?**
3. **Did signature verification fail?**
4. **Did your code return a non-2xx or time out?**
5. **Did async processing fail after acknowledgment?**

A webhook inspector helps a lot here. If you want a disposable endpoint to inspect payloads and delivery behavior while testing form or automation flows, try a [webhook tester for local debugging](https://www.staticforms.dev/tools/webhook-tester).

---

If you're building a static or JAMstack site and want forms to feed email, Slack, Sheets, or your own webhook endpoint without maintaining backend form handling yourself, [Static Forms](https://www.staticforms.dev) is one practical option to evaluate; Slack and webhooks start on its Starter plan and Google Sheets on Pro.

---

## Master Radio Button CSS Style in 2026

Source: https://www.staticforms.dev/blog/radio-button-css-style  
Date: 2026-06-09T08:07:42.866Z  
Author: Static Forms Team

You're probably staring at a form that works fine, but the default radios look like they belong to a different product. That's the usual problem with radio button CSS style. Native radios are reliable, accessible, and ugly in ways that vary by platform.

The fix isn't “replace everything with divs.” The fix is to keep the native input, keep the browser behavior that users expect, and style only as far as your project needs.

## Why Styling Radio Buttons Is Tricky

Radio buttons are one of those controls that seem simple until you customize them. The underlying HTML behavior matters more than the paint job. A radio group is for **single-choice input**, and only one radio in the same named group can be selected at a time. If the group is required, the browser keeps the form invalid until the user chooses one option, as documented in [MDN's radio input reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/radio).

That built-in behavior is the reason custom styling goes wrong so often. Teams remove the native control, lose keyboard interaction or validation, then spend hours rebuilding what the browser already handled.

If you need a refresher on where radios fit among other form controls, [this breakdown of HTML form input types](https://www.staticforms.dev/blog/form-input-types) is a useful quick reference.

> **Practical rule:** If your custom radio button stops behaving like a native radio group, it's not finished yet.

The other catch is visual rendering. Browsers hand a lot of native form control styling off to the operating system, so your CSS doesn't always get full control. That's why modern radio button CSS style usually falls into two sane options:

- **Use native-first styling** when color changes are enough.
- **Build a custom visual layer** only when your design system needs a fully branded control.
- **Keep the input in the DOM** so the form still validates, submits, and works with assistive tech.

## The Quick Win Using accent-color

If all you need is “make the radio match the brand,” use `accent-color` first. It's the least fragile option, and it preserves the native control instead of fighting it.

`accent-color` is the simplest modern approach, and it's now supported across every current browser — Chrome, Edge, Firefox, and Safari (15.4+). As [Bryntum's guide to styling radio buttons with modern CSS](https://bryntum.com/blog/3-ways-to-style-radio-buttons-with-modern-css/) points out, the appeal is that you keep native behavior, focus styles, and accessibility instead of recreating everything manually with `appearance: none`.

![A digital screen displaying a profile settings form with radio buttons styled via custom CSS code.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/284247ec-da2a-4ac2-9bf1-ad588c18f34c/radio-button-css-style-ui-design.jpg)

### When accent-color is the right choice

This works well when:

- **You want fast alignment with your design system.** A brand red, blue, or green is usually enough.
- **You don't need a custom shape.** The browser keeps the native circle and dot.
- **You care more about stability than visual flair.** Native focus and disabled states remain intact.

Here's a plain HTML form you can ship as-is:

```html
<form action="https://api.example.com/forms/preferences" method="post">
  <fieldset>
    <legend>Email frequency</legend>

    <label>
      <input type="radio" name="frequency" value="daily" required>
      Daily
    </label>

    <label>
      <input type="radio" name="frequency" value="weekly">
      Weekly
    </label>

    <label>
      <input type="radio" name="frequency" value="monthly">
      Monthly
    </label>
  </fieldset>

  <button type="submit">Save preferences</button>
</form>
```

And the CSS:

```css
input[type="radio"] {
  accent-color: #fe5b5b;
}

fieldset {
  border: 0;
  padding: 0;
  margin: 0 0 1rem;
}

label {
  display: flex;
  gap: 0.625rem;
  align-items: center;
  margin-block: 0.75rem;
  cursor: pointer;
}
```

### What it gives you and what it doesn't

`accent-color` is great because it does very little. That's exactly the point.

| Need | accent-color |
|---|---|
| Brand-colored checked state | Yes |
| Native keyboard behavior | Yes |
| Native validation | Yes |
| Custom size and ring thickness | No |
| Animated inner dot | No |
| Fully custom visuals | No |

That last row matters. If your designer wants a larger ring, a softer fill, a custom focus halo, or motion on selection, `accent-color` won't get you there.

> Don't jump to fully custom radios just because you can. If color is the only requirement, native-first styling is usually the better engineering decision.

## Building Fully Custom Radio Buttons with CSS

When `accent-color` isn't enough, the safest pattern is still to keep the actual radio input and style something adjacent to it. That's the approach described in [SitePoint's guide to replacing radio buttons without replacing radio buttons](https://www.sitepoint.com/replacing-radio-buttons-without-replacing-radio-buttons/). The core idea is simple: let the input hold the state, then reflect that state onto an element you can style freely.

![A four-step infographic illustrating the process of building fully custom radio buttons using CSS and HTML.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/96b741bc-d9c7-4450-a2c5-599ec7384159/radio-button-css-style-custom-buttons.jpg)

### Start with the right HTML

This pattern keeps the input inside the label. That gives you a larger hit area and simpler markup.

```html
<form action="https://api.example.com/forms/shipping" method="post">
  <fieldset class="radio-group">
    <legend>Shipping speed</legend>

    <label class="radio">
      <input type="radio" name="shipping_speed" value="standard" checked required>
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Standard</span>
    </label>

    <label class="radio">
      <input type="radio" name="shipping_speed" value="express">
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Express</span>
    </label>

    <label class="radio">
      <input type="radio" name="shipping_speed" value="priority">
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Priority</span>
    </label>
  </fieldset>

  <button type="submit">Continue</button>
</form>
```

A few things are doing real work here:

- **The shared `name` attribute** makes the controls act as one group.
- **The underlying input remains in the form**, so submission and validation still work.
- **The visual span is `aria-hidden`**, because it's decoration, not the actual control.
- **The label wraps everything**, so users can click the text, not just the circle.

### Hide the native indicator without breaking interaction

You want the browser to keep the input alive, focusable, and clickable. You don't want `display: none` or `visibility: hidden` because those remove it from interaction.

Use this instead:

```css
.radio {
  position: relative;
  display: grid;
  grid-template-columns: 1.5rem 1fr;
  gap: 0.75rem;
  align-items: center;
  cursor: pointer;
  min-height: 44px;
}

.radio input[type="radio"] {
  position: absolute;
  opacity: 0;
  inset: 0;
  margin: 0;
}

.radio-ui {
  width: 1.25rem;
  height: 1.25rem;
  border: 2px solid #6b7280;
  border-radius: 50%;
  display: inline-grid;
  place-items: center;
  box-sizing: border-box;
  transition: border-color 160ms ease, box-shadow 160ms ease;
}

.radio-ui::before {
  content: "";
  width: 0.625rem;
  height: 0.625rem;
  border-radius: 50%;
  background: #fe5b5b;
  transform: scale(0);
  opacity: 0;
  transition: transform 160ms ease, opacity 160ms ease;
}

.radio-text {
  line-height: 1.4;
  color: #111827;
}
```

The hidden input stretches across the label, so the whole row is interactive. The custom circle is just a visual proxy.

### Reflect checked state with sibling selectors

This is the part that makes the component feel real. The input owns the state. CSS reads that state and updates the nearby visual element.

```css
.radio input[type="radio"]:checked + .radio-ui {
  border-color: #fe5b5b;
}

.radio input[type="radio"]:checked + .radio-ui::before {
  transform: scale(1);
  opacity: 1;
}
```

That `:checked + .radio-ui` relationship is the heart of fully custom radio button CSS style. You're not faking state with JavaScript. You're letting the browser do its job, then styling the result.

> Animate `opacity` and `transform`, not `display`. The browser can transition those smoothly, and you avoid the abrupt on/off snap that makes custom radios feel cheap.

### A version using appearance none

If you prefer to style the input itself, you can use `appearance: none`. That can work, but it comes with more responsibility because you're removing the default look entirely.

```css
input[type="radio"].radio-reset {
  appearance: none;
  width: 1.25rem;
  height: 1.25rem;
  border: 2px solid #6b7280;
  border-radius: 50%;
  display: inline-grid;
  place-items: center;
  margin: 0;
}

input[type="radio"].radio-reset::before {
  content: "";
  width: 0.625rem;
  height: 0.625rem;
  border-radius: 50%;
  transform: scale(0);
  opacity: 0;
  background: #fe5b5b;
  transition: transform 160ms ease, opacity 160ms ease;
}

input[type="radio"].radio-reset:checked::before {
  transform: scale(1);
  opacity: 1;
}
```

I only use this route when I'm sure the team will handle focus, disabled styling, and browser QA properly. It's easy to get a pretty demo and a broken production control.

### Common implementation mistakes

These show up a lot in code reviews:

- **Using `display: none` on the input.** That kills accessibility and keyboard access.
- **Forgetting label association.** If the text isn't clickable, the control feels worse on both desktop and touch devices.
- **Styling an inline element without sizing rules.** Your custom circle won't size consistently.
- **Misaligning the inner dot.** Grid or flex centering prevents the “dot drifts off-center” bug.
- **Over-animating the component.** Radios should feel responsive, not theatrical.

## Advanced Styling and Accessibility

A custom radio isn't production-ready when it merely looks checked. It's ready when keyboard users can find it, touch users can hit it, disabled states are obvious, and the control still makes sense when styles get more opinionated.

Modern CSS guidance puts a lot of weight on interaction quality, not just visuals. That includes visible focus, keyboard navigability, and a **minimum 44×44 px tappable area** by wrapping the input in a label, as covered in [Modern CSS's custom styled radio guidance](https://moderncss.dev/pure-css-custom-styled-radio-buttons/).

![A digital UI display demonstrating various radio button states including default, hover, selected, focused, and disabled.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/751acb33-fdee-4885-b0a0-2c083e84c5ba/radio-button-css-style-ui-design.jpg)

### Focus styles that users can actually see

When the native control is hidden or heavily restyled, the browser's default outline often won't be enough. Add an explicit focus state.

```css
.radio input[type="radio"]:focus-visible + .radio-ui {
  outline: 3px solid rgba(254, 91, 91, 0.35);
  outline-offset: 3px;
}
```

Use `:focus-visible` instead of `:focus` when possible. Mouse users usually don't need a persistent focus ring after clicking, but keyboard users do.

> A custom radio without a visible focus state is unfinished, no matter how polished the unchecked and checked states look.

If you're grouping related options, [using `fieldset` and `legend` correctly](https://www.staticforms.dev/blog/html-forms-fieldset) helps the form stay understandable for screen readers and for developers reading the markup later.

### Disabled and hover states

Disabled radios should look disabled without becoming unreadable. Hover should help sighted mouse users, but it shouldn't be your only interaction cue.

```css
.radio input[type="radio"]:hover + .radio-ui {
  border-color: #374151;
}

.radio input[type="radio"]:disabled + .radio-ui {
  border-color: #9ca3af;
  background: #f3f4f6;
}

.radio input[type="radio"]:disabled + .radio-ui::before {
  background: #9ca3af;
}

.radio input[type="radio"]:disabled ~ .radio-text {
  color: #6b7280;
  cursor: not-allowed;
}

.radio:has(input[type="radio"]:disabled) {
  cursor: not-allowed;
  opacity: 0.8;
}
```

If you don't want to use `:has()`, you can move the disabled cursor styling to a class added server-side or via framework props.

### Motion that helps instead of distracting

The right animation makes the state change easier to perceive. The wrong one makes forms feel slow.

A small scale-in on the inner dot is usually enough:

```css
.radio-ui::before {
  transition: transform 160ms ease, opacity 160ms ease;
}
```

I'd avoid animating width, height, or layout-related properties here. Those can make the ring jump or shift text alignment. Radios should feel steady.

### SVG when the design system goes beyond circles

Sometimes the design team wants more than a ring and dot. Maybe the selected state uses a branded glyph or a more geometric icon. That's where an inline SVG inside the visual span can work well.

```html
<label class="radio radio-svg">
  <input type="radio" name="plan" value="pro">
  <span class="radio-ui" aria-hidden="true">
    <svg viewBox="0 0 24 24" class="radio-icon">
      <circle cx="12" cy="12" r="9" class="radio-ring" />
      <circle cx="12" cy="12" r="5" class="radio-dot" />
    </svg>
  </span>
  <span class="radio-text">Pro</span>
</label>
```

```css
.radio-icon {
  width: 100%;
  height: 100%;
}

.radio-ring {
  fill: none;
  stroke: #6b7280;
  stroke-width: 2;
}

.radio-dot {
  fill: #fe5b5b;
  transform: scale(0);
  transform-origin: center;
  opacity: 0;
  transition: transform 160ms ease, opacity 160ms ease;
}

.radio-svg input[type="radio"]:checked + .radio-ui .radio-ring {
  stroke: #fe5b5b;
}

.radio-svg input[type="radio"]:checked + .radio-ui .radio-dot {
  transform: scale(1);
  opacity: 1;
}
```

SVG buys you more design freedom, but it also increases the number of moving parts. Only use it when the design needs it.

## Integrating Custom Radios in Frameworks

Once you've got the HTML and CSS pattern right, the framework version should stay boring. That's a good thing. Radios are easiest to maintain when your React, Next.js, or Vue component maps closely to the native markup.

![Screenshot from https://www.staticforms.dev](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/45228bd6-b1d0-45e3-8c4b-25d872e10ad0/radio-button-css-style-form-backend.jpg)

### React and Next.js

In React, keep it controlled only if the rest of the form is already controlled. Otherwise, uncontrolled radios are often simpler.

```jsx
import styles from "./Radio.module.css";

export function Radio({ name, value, checked, onChange, children, required }) {
  return (
    <label className={styles.radio}>
      <input
        type="radio"
        name={name}
        value={value}
        checked={checked}
        onChange={onChange}
        required={required}
      />
      <span className={styles.radioUi} aria-hidden="true" />
      <span className={styles.radioText}>{children}</span>
    </label>
  );
}

export default function PlanForm() {
  const [plan, setPlan] = React.useState("starter");

  return (
    <form action="https://api.example.com/forms/plans" method="post">
      <fieldset>
        <legend>Choose a plan</legend>

        <Radio
          name="plan"
          value="starter"
          checked={plan === "starter"}
          onChange={(e) => setPlan(e.target.value)}
          required
        >
          Starter
        </Radio>

        <Radio
          name="plan"
          value="business"
          checked={plan === "business"}
          onChange={(e) => setPlan(e.target.value)}
        >
          Business
        </Radio>
      </fieldset>

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

If you want a framework-specific form handling reference, [this React forms documentation page](https://www.staticforms.dev/docs/react) is a handy implementation guide.

### Vue

Vue's `v-model` maps nicely to radio groups because the browser behavior is already built for single selection.

```vue
<template>
  <form action="https://api.example.com/forms/notifications" method="post">
    <fieldset>
      <legend>Notification level</legend>

      <label class="radio">
        <input type="radio" name="notifications" value="all" v-model="level" required />
        <span class="radio-ui" aria-hidden="true"></span>
        <span class="radio-text">All updates</span>
      </label>

      <label class="radio">
        <input type="radio" name="notifications" value="important" v-model="level" />
        <span class="radio-ui" aria-hidden="true"></span>
        <span class="radio-text">Important only</span>
      </label>
    </fieldset>

    <button type="submit">Save</button>
  </form>
</template>

<script setup>
import { ref } from "vue";
const level = ref("all");
</script>

<style scoped>
/* reuse the same CSS pattern from earlier */
</style>
```

A few framework-specific gotchas are worth watching:

- **Don't break the shared `name`.** That's what keeps the group behaving as radios.
- **Don't replace radios with clickable divs.** Framework state doesn't excuse losing semantics.
- **Scope styles carefully.** CSS Modules, scoped styles, or component classes help avoid accidental overrides.

## Making Your Styled Form Functional

A polished radio group still isn't useful if the form goes nowhere. Static and JAMstack projects hit this wall all the time. The frontend is clean, the UI looks finished, then someone realizes there's no submission pipeline.

The simplest fix is to post the form to a hosted form backend instead of writing your own handler. That keeps the native form flow intact, which is especially nice when your radios, validation, and labels already rely on normal HTML behavior.

Here's a realistic production-style example:

```html
<form action="https://api.example.com/forms/contact" method="post">
  <fieldset class="radio-group">
    <legend>Reason for contact</legend>

    <label class="radio">
      <input type="radio" name="reason" value="sales" required>
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Sales inquiry</span>
    </label>

    <label class="radio">
      <input type="radio" name="reason" value="support">
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Support request</span>
    </label>

    <label class="radio">
      <input type="radio" name="reason" value="partnership">
      <span class="radio-ui" aria-hidden="true"></span>
      <span class="radio-text">Partnership</span>
    </label>
  </fieldset>

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

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

  <input type="text" name="company_website" tabindex="-1" autocomplete="off" style="position:absolute;left:-9999px">

  <div class="cf-turnstile" data-sitekey="your-turnstile-site-key"></div>

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

The practical concerns are straightforward:

- **Spam protection matters.** Use a honeypot and a challenge option such as reCAPTCHA v2, reCAPTCHA v3, or Cloudflare Turnstile if your backend supports them.
- **Uploads need explicit limits.** If your form accepts files, keep the limit clear in the UI. Hosted form backends cap upload size — Static Forms accepts files from the Starter plan up and rejects any submission over **4.5MB**, counting every file plus the other fields — so match your copy and validation to the actual backend rule.
- **Email delivery needs proper domain setup.** If you send from your own domain, SPF, DKIM, and DMARC need to be configured correctly or your form notifications and auto-responses can become unreliable.
- **GDPR isn't just legal copy.** It affects consent wording, retention, export, and deletion workflows.

Before you ship, test the whole interaction. Styled radios often pass visual review and fail usability review. [Uxia's guide to UI validation](https://www.uxia.app/blog/user-interface-design-testing) is a solid reference for checking whether a polished interface is easy to use.

---

If you want to keep the frontend simple and skip writing backend form handlers, [Static Forms](https://www.staticforms.dev) is one practical option for static and JAMstack sites. You point your form at its submission endpoint, keep native HTML forms, and add things like spam protection, GDPR controls, webhooks and file uploads up to 4.5MB per submission (Starter and up), and custom-domain email delivery with SPF, DKIM, and DMARC support (Pro and up) without standing up your own server.

---

## How to Add Platform-Independent Forms to WordPress

Source: https://www.staticforms.dev/blog/platform-independent-forms-wordpress  
Date: 2026-06-07  
Author: Static Forms Team

Most WordPress forms are trapped. They depend on PHP running on your server, a form plugin storing entries in your database, and `wp_mail()` hoping your host's mail configuration actually delivers. The moment you switch hosts, change form plugins, or migrate to a static site, those forms break — and every submission, integration, and notification rule has to be rebuilt from scratch.

A **platform-independent form** solves this by decoupling the form from WordPress entirely. The form markup lives wherever you want, but the submission goes to a dedicated, portable endpoint. Move your site to GitHub Pages, Netlify, Astro, or a hand-coded HTML page tomorrow, and the *exact same form* keeps delivering to the *exact same inbox* — no rebuild required.

In this guide, we'll show you how to add platform-independent forms to WordPress using [Static Forms](https://www.staticforms.dev), covering the official plugin, page-builder integrations, and the plain-HTML approach that works on any platform.

## What "Platform-Independent" Actually Means

A WordPress form is platform-dependent when it relies on things that only exist inside WordPress:

- **PHP processing** — the submission is handled by server-side code that ships with WordPress.
- **Plugin-specific storage** — entries live in a database table owned by Contact Form 7, WPForms, Gravity Forms, etc.
- **Host mail delivery** — notifications depend on your server's mail setup, which is famously unreliable.

A platform-independent form removes all three dependencies. The form simply POSTs its fields to an external API endpoint that handles validation, spam filtering, storage, and email delivery. WordPress becomes just one place the form *happens to live* — not the thing the form *depends on*.

The practical payoff:

- **No lock-in** — migrate hosts or platforms without touching your form logic.
- **Reliable delivery** — email is sent by infrastructure built for it, not your shared host.
- **One inbox everywhere** — the same endpoint serves your WordPress site, your landing pages, and your future static site.
- **No PHP to maintain or secure** — fewer plugins, smaller attack surface.

## Prerequisites

Before you start, make sure you have:

- A WordPress site (self-hosted or WordPress.com Business+ with plugin support)
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

You'll choose **one** of three approaches below depending on how your site is built. All three produce the same result: portable forms that post to the same endpoint.

## Approach 1: The Official WordPress Plugin (Recommended)

The official Static Forms plugin is the easiest path if you already use **Elementor Pro** or **Contact Form 7**. It forwards submissions server-to-server, so your API key never reaches the browser.

### Step 1: Install the Plugin

1. Download the plugin ZIP from the [WordPress integration docs](https://www.staticforms.dev/docs/wordpress).
2. In WordPress, go to **Plugins → Add New → Upload Plugin**.
3. Choose the ZIP, click **Install Now**, then **Activate**.

### Step 2: Add Your API Key

Go to **Settings → Static Forms** and paste the API key from your [Static Forms dashboard](https://www.staticforms.dev/app/forms). This is stored once, server-side, and reused by every integration mode.

### Step 3: Connect Your Forms

Pick the mode that matches your setup:

**Elementor Pro**

1. Edit your form widget.
2. Open **Actions After Submit**.
3. Add **Static Forms** to the actions list.

Submissions are now sent server-to-server to Static Forms every time the form is submitted.

**Contact Form 7**

1. In **Settings → Static Forms**, tick **"Forward Contact Form 7 submissions"**.
2. Every CF7 form on your site now forwards to Static Forms automatically.
3. To opt a single form out, add `staticforms: off` to that form's **Additional Settings** tab.

**The `[staticforms]` Shortcode (no form plugin needed)**

If you don't use a page builder or CF7, the plugin ships a ready-made contact form. Drop this into any page or post:

```text
[staticforms]
```

Customize the fields and the post-submit redirect:

```text
[staticforms fields="name,email,message" redirect="https://yoursite.com/thank-you"]
```

### Why This Is Still Platform-Independent

This is the key point: **the plugin posts to the same endpoint your static HTML would use.** When you migrate off WordPress later, you swap the form `action` on the new site to that endpoint and submissions keep flowing to the same inbox — zero downtime, zero reconfiguration. The plugin is a convenience layer, not a dependency.

## Approach 2: Plain HTML in a Custom HTML Block (Works Everywhere)

If you want maximum portability — or you're on a WordPress setup without Elementor or CF7 — skip the plugin and paste a plain HTML form directly into a page. This is the most platform-independent option because the form has *no* WordPress dependency at all. The same markup works unchanged on a static site.

### Step 1: Add a Custom HTML Block

1. Go to **Pages → Add New** (or edit an existing page).
2. Click **+** to add a block and choose **Custom HTML**.
3. Paste the form code below.

### Step 2: Paste Your Form

```html
<form action="https://api.staticforms.dev/submit" method="POST" id="sf-contact">
  <label for="name">Your Name</label>
  <input type="text" id="name" name="name" required>

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

  <label for="message">Message</label>
  <textarea id="message" name="message" required></textarea>

  <!-- Static Forms configuration -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  <input type="hidden" name="replyTo" value="@">
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">

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

**Replace `YOUR_API_KEY_HERE`** with your actual API key from the dashboard.

### Step 3: Understand the Configuration Fields

- **`action`** — points to the Static Forms endpoint that handles every submission.
- **`apiKey`** — authenticates the form with your account.
- **`replyTo="@"`** — tells Static Forms to use the submitter's email as the reply-to address, so you can reply directly from your inbox.
- **`honeypot`** — a hidden field that traps spam bots. Real users never see or fill it.

That's it — this form is fully portable. Copy it to a `.html` file on GitHub Pages, an Astro component, or a Next.js page and it behaves identically.

### Optional: AJAX Submission Without Leaving the Page

For a smoother experience, submit via JavaScript and show an inline confirmation instead of a page redirect:

```html
<div id="sf-status"></div>

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

  form.addEventListener('submit', async (e) => {
    e.preventDefault();
    const data = Object.fromEntries(new FormData(form));

    try {
      const res = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(data),
      });
      const result = await res.json();

      if (result.success) {
        status.textContent = 'Thanks! Your message has been sent.';
        form.reset();
      } else {
        throw new Error(result.message || 'Submission failed');
      }
    } catch (err) {
      status.textContent = 'Something went wrong. Please try again.';
    }
  });
</script>
```

## Approach 3: Other Form Plugins

Many WordPress form plugins (Gravity Forms, WS Form, Fluent Forms, and others) let you set a **custom form action** or add a **webhook/POST integration**. Point that action at:

```text
https://api.staticforms.dev/submit
```

…and include your `apiKey` as a hidden field or POST parameter. Your existing plugin handles the UI; Static Forms handles delivery and storage. This keeps the submission pipeline portable even while you keep your favorite form builder.

## Adding Spam Protection

The hidden honeypot field stops most bots, but for higher-traffic sites you can layer on CAPTCHA. Static Forms supports reCAPTCHA v2 on every plan, plus hCaptcha, Cloudflare Turnstile, ALTCHA and reCAPTCHA v3 from the Starter plan up ($6/month, or $4/month billed annually).

For example, to add Google reCAPTCHA, load the script in your page and add the widget:

```html
<script src="https://www.google.com/recaptcha/api.js" async defer></script>

<div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
```

Then configure the matching secret key in your [Static Forms CAPTCHA settings](https://www.staticforms.dev/app/forms). See our [understanding reCAPTCHA guide](/blog/understanding-recaptcha) and [Cloudflare Turnstile best practices](/blog/cloudflare-turnstile-best-practices) for details.

## Going Beyond Email: Webhooks and Integrations

Because submissions flow through Static Forms rather than WordPress, you get integrations that don't depend on WordPress plugins:

- **Webhooks** to Slack, Telegram, Discord, your CRM, or any custom endpoint (from the Starter plan up)
- **Google Sheets** for a live spreadsheet of submissions (Pro and Agency only, alongside Notion, Airtable and Mailchimp)
- **File uploads** with persistent storage and download from your inbox (from the Starter plan up)
- **Custom fields** by prefixing a field name with `$`, e.g. `name="$company"`

Configure these once in your [dashboard](https://www.staticforms.dev/app/forms) and they apply no matter which platform the form lives on. Learn more in our [Slack integration guide](/blog/how-to-send-form-submissions-to-slack) and [Google Sheets integration guide](/blog/google-sheets-integration-guide).

## The Migration Test

Here's the real proof that your forms are platform-independent. Suppose you decide to move from WordPress to a static site:

1. Export or rebuild your pages on the new platform (Astro, Next.js, plain HTML — anything).
2. Copy your form markup over, keeping the same `action` and `apiKey`.
3. Deploy.

That's the entire migration as far as forms are concerned. No rewiring notifications, no exporting entries from a plugin database, no re-creating spam rules. Submissions land in the same inbox they always did. Try doing that with a form locked inside a WordPress plugin.

## Troubleshooting

**Not receiving submissions?**

- ✅ Confirm the API key in the form matches your dashboard
- ✅ Check your spam/junk folder
- ✅ Verify your account email is confirmed in Static Forms

**Form posts but shows an error?**

- ✅ Open the browser console and check for JavaScript errors
- ✅ Confirm the endpoint URL is exactly `https://api.staticforms.dev/submit`
- ✅ When submitting via JavaScript, include the `Content-Type: application/json` header

**Using the plugin and the key is exposed in page source?**

- ✅ Make sure you configured the key under **Settings → Static Forms**, not as a visible field. The plugin forwards server-to-server precisely so the key stays off the page.

## Conclusion

WordPress is a great place to build pages — but your forms shouldn't be hostage to it. By posting submissions to a portable endpoint instead of relying on PHP, plugin databases, and host mail, you get forms that are reliable today and portable tomorrow.

Whether you use the official plugin for Elementor and Contact Form 7, paste plain HTML into a Custom HTML block, or wire up your existing form builder, the result is the same: one inbox, one endpoint, zero lock-in.

Ready to build forms that outlive your platform? [Sign up for Static Forms](https://www.staticforms.dev) and get started free.

For more integration walkthroughs, see our guides for [GitHub Pages](/blog/github-pages-contact-form-tutorial), [Astro](/blog/astro-contact-form-tutorial), and [Next.js](/blog/using-staticforms-with-nextjs).

---

## HTML Tag Button

Source: https://www.staticforms.dev/blog/html-tag-button  
Date: 2026-06-03T09:58:02.403Z  
Author: Static Forms Team

You build a quick contact form, add a "Close" button to a modal, click it, and the page reloads. That bug usually isn't React, Vue, Next.js, or your modal logic. It's the HTML button element doing exactly what the platform says it should do.

The html tag button looks simple until it sits inside a real form, picks up framework event handlers, and becomes the only thing standing between the user and a hosted form backend. That's where small details matter. A missing `type`, a disabled state that never clears, or a button rendered as a styled `<div>` can turn a straightforward UI into a support ticket.

## Why Your Button Might Be Submitting Forms By Itself

A lot of button bugs start with the same setup. You've got a form, maybe a newsletter signup or contact page on a static site. Inside that form, you add a secondary button for "Open help", "Close", "Preview", or "Add another field". Then you click it and the browser submits the form.

That behavior surprises people because the UI looks like "just a button." In HTML, it isn't. The `<button>` element is an interactive form control whose behavior depends on its `type`. If it's associated with a form and you don't set `type`, it can act as a submit control according to the [HTML Standard's button element rules](https://html.spec.whatwg.org/multipage/form-elements.html).

> **Practical rule:** If a button is not meant to submit a form, write `type="button"` every time.

This catches people in modals, newsletter forms, search bars, and static-site contact forms. It's even more annoying in JAMstack builds because there may be no server logs to tell you why a click triggered navigation or why a form posted unexpectedly.

If you're wiring up a plain HTML form for a static site, a working baseline like this [free HTML form example](https://www.staticforms.dev/blog/create-free-html-form) is useful. It gives you a clean starting point before JavaScript and component abstractions complicate the button behavior.

## Core Syntax and Essential Attributes

`<button>` does not expose many attributes, but the few that matter determine what gets submitted, which endpoint receives it, and whether the user can act at all. If you build forms that post to a static form backend, these details stop being academic fast.

### Start with type and set it explicitly

`type` controls the button's job. Treat it as required in code review, especially inside forms and component libraries where a missing attribute can slip through unnoticed.

W3Schools also recommends setting it explicitly in [their button tag reference](https://www.w3schools.com/tags/tag_button.asp).

Use these values on purpose:

- **`type="button"`** for UI actions such as opening help, toggling panels, or launching a modal
- **`type="submit"`** for the control that should send form data
- **`type="reset"`** for restoring initial field values, though many teams avoid it because accidental resets are frustrating

```html
<form action="https://api.example.com/contact" method="post">
  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <button type="button" id="open-help">Help</button>
  <button type="submit">Send</button>
  <button type="reset">Clear</button>
</form>
```

In React, Vue, Astro, Blade, or plain HTML, the browser still decides what an untyped button does. Frameworks can hide the markup, but they do not change the platform rule.

### Use name and value when the clicked button changes backend behavior

A submit button can send its own `name` and `value` with the form. That is useful when one form supports more than one action and the backend needs to know which path to run.

```html
<form action="https://api.example.com/posts" method="post">
  <input type="text" name="title" required />

  <button type="submit" name="intent" value="draft">Save Draft</button>
  <button type="submit" name="intent" value="publish">Publish</button>
</form>
```

This pattern holds up well on static sites too. A form service can inspect `intent=draft` versus `intent=publish`, and your serverless function or webhook can branch without extra hidden inputs or client-side state.

### Disabled changes both UX and form behavior

`disabled` prevents clicks, keyboard activation, and normal form participation.

```html
<button type="submit" disabled>Sending...</button>
```

That is useful for duplicate-submit protection, but it has a cost. A disabled button will not submit, and its value will not be included in the request. If your validation code disables the button and never restores it, the form appears broken even though the markup is fine.

This shows up often with static form handlers because there may be no application server logs to explain why nothing was posted.

### Use form when the button lives outside the form element

Buttons can be associated with a form by `id` even when they sit elsewhere in the DOM. This solves a common layout problem in sticky action bars, card footers, drawers, and modal shells.

```html
<form id="contact-form" action="https://api.example.com/contact" method="post">
  <input type="text" name="name" required />
  <input type="email" name="email" required />
</form>

<footer class="form-actions">
  <button type="submit" form="contact-form">Send Message</button>
</footer>
```

This is one of those native HTML features that gets overlooked because many developers reach for JavaScript first. In component-based apps, it can simplify markup and reduce event plumbing.

### Button-level form overrides can be powerful

Submit buttons can override the parent form with attributes such as:

- **`formaction`** to send the submission to a different URL
- **`formmethod`** to change the HTTP method
- **`formenctype`** to change how the payload is encoded
- **`formtarget`** to choose where the response opens
- **`formnovalidate`** to skip built-in validation for that button only

```html
<form id="profile-form" action="https://api.example.com/profile" method="post">
  <input type="text" name="displayName" required />
</form>

<button type="submit" form="profile-form">Save</button>
<button
  type="submit"
  form="profile-form"
  formaction="https://api.example.com/profile/preview"
  formnovalidate
>
  Preview
</button>
```

Used carefully, these attributes let one form support multiple backend flows. For example, a static site might send the normal submit button to a service endpoint, while a preview button posts to a serverless route that returns rendered output. Used carelessly, they make form behavior hard to reason about. If each button submits somewhere different, document it clearly and test the network requests, not just the UI state.

## Button vs Input vs Anchor A Semantic Showdown

A lot of button bugs start as semantic bugs. The UI looks right, QA clicks it once, and nobody notices the mismatch until keyboard behavior, screen reader output, or form handling breaks in production.

`<button>`, `<input>`, and `<a>` can all be styled to look the same. They do different jobs in the platform, and that difference matters all the way through to submission handling and analytics.

### Quick comparison

| Element | Semantic Meaning | Allowed Content | Default Behavior in a Form | Best For |
|---|---|---|---|---|
| `<button>` | Interactive control for an action | Text, icons, emphasis, line breaks, images, other phrasing content | Can submit depending on `type` | Most UI actions and form submits |
| `<input type="button">` | Simple button control | No nested HTML, value text only | Does not submit unless scripted | Legacy or very simple controls |
| `<a>` | Navigation to another resource or location | Text and nested inline content | Not a form submit control | Links, navigation, downloads, route changes |

### Use button for actions

Use `<button>` when the click performs an action in the current interface. Opening a modal, toggling filters, copying text, incrementing quantity, and submitting a form all belong here.

```html
<button type="button" aria-expanded="false" aria-controls="filters-panel">
  Show filters
</button>
```

`<button>` also scales better once the UI gets real styling. You can include an icon, wrap text on two lines, hide extra text for visual users but keep it for screen readers, and still keep one coherent accessible name. That becomes useful fast in component libraries and design systems.

For static sites, this choice affects backend integration too. A contact form that posts to Static Forms or another form endpoint should use a real submit button, not a link with a click handler pretending to submit. Native form submission gives you predictable request behavior, preserves keyboard support, and degrades better if JavaScript fails.

### Use input for narrow cases

`<input type="button">` still has valid uses. It is compact, familiar, and fine for a plain control with a single text label.

```html
<input type="button" value="Refresh Preview" />
```

Its limits show up quickly. The label lives in `value`, not child content, so adding an inline SVG, highlighted text, or a loading spinner turns into extra markup around the control or a different element altogether. In modern frontend code, `<button>` is usually the better default unless you are maintaining older markup or generating very simple form controls.

One practical exception is `<input type="submit">`. It is still common in server-rendered forms and static site templates because it is concise and works well. But if the design calls for richer content, a spinner, or separate visible and accessible labels, `<button type="submit">` is easier to work with.

### Use anchor for navigation

Use `<a>` when the destination is a URL. That includes page navigation, file downloads, hash jumps, and client-side route changes in frameworks that render links as anchors.

```html
<a href="/pricing" class="button-link">View pricing</a>
```

Styling a link to look like a button is fine. Changing its job is not. If the element submits data, toggles UI state, or closes a dialog, a link is the wrong primitive even if `href="#"` and JavaScript make it appear to work.

Frameworks make this easy to blur. In React, Next.js, Vue, and similar stacks, a routed link component often renders an anchor underneath. That is correct for navigation. A checkout step that saves data before routing may still need a real `<button>` inside a form, followed by navigation after the backend confirms success.

> If you are reaching for `role="button"` on an anchor, stop and check whether the element should have been a `<button>` from the start.

One more rule saves a lot of debugging time. Do not nest interactive elements. Putting a `<button>` inside an `<a>`, or the reverse, creates messy focus behavior, unreliable click handling, and confusing output for assistive tech.

## Styling Buttons with Modern CSS

Many developers don't struggle to make buttons look good. They struggle to make them look good without breaking focus styles, text layout, or cross-browser consistency.

Buttons also come with one detail many developers miss. They use **`border-box` by default**, unlike most HTML elements, so the rendered size already includes padding and border, as explained in this [button sizing explainer](https://www.youtube.com/watch?v=LFOHcadBncc). That usually helps, but global resets can change assumptions.

![A modern interior design website homepage featuring a professional living room and an inspirational call to action.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/db8bdcab-6ba9-42bc-97f2-272f2723f506/html-tag-button-interior-design.jpg)

### A solid base style

Start from a small, explicit base instead of hoping your reset gets every browser edge case right.

```css
.button {
  --btn-bg: #111827;
  --btn-fg: #ffffff;
  --btn-border: #111827;
  --btn-bg-hover: #1f2937;
  --btn-ring: #fe5b5b;

  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 0.5rem;

  min-height: 2.75rem;
  padding: 0.75rem 1rem;
  border: 1px solid var(--btn-border);
  border-radius: 0.5rem;

  background: var(--btn-bg);
  color: var(--btn-fg);
  font: inherit;
  font-weight: 600;
  line-height: 1.2;
  text-decoration: none;
  cursor: pointer;
}

.button:hover {
  background: var(--btn-bg-hover);
}

.button:focus-visible {
  outline: 3px solid var(--btn-ring);
  outline-offset: 2px;
}

.button:disabled {
  opacity: 0.6;
  cursor: not-allowed;
}
```

That gives you predictable alignment, readable text, and a visible keyboard focus state without relying on browser defaults.

### Handle icon-only and long-label cases

Icon-only buttons need extra care. Give them a stable tap target and keep the icon from shrinking awkwardly.

```css
.button-icon {
  width: 2.75rem;
  padding: 0;
}

.button-icon svg {
  width: 1.25rem;
  height: 1.25rem;
  flex: none;
}
```

For buttons with long labels, decide whether you want wrapping or truncation. Don't let it happen by accident.

```css
.button-truncate {
  max-width: 14rem;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}
```

### Watch your resets and utility classes

Frameworks and utility libraries can unintentionally flatten button behavior.

- **Reset conflicts:** A global `appearance: none` or `border: 0` may be fine, but only if you replace the lost affordances.
- **Link-button mixing:** Shared utility classes across `<a>` and `<button>` are fine until one control wraps text differently or aligns content off-center.
- **State styling:** `:hover` isn't enough. Style `:focus-visible` and `:disabled` on purpose.

A good button style system doesn't just match Figma. It survives the practical states users encounter.

## Writing Accessible Buttons Everyone Can Use

If a control performs an action, use a real button. MDN describes `<button>` as an **activatable** control intended to work across mouse, keyboard, touch, voice, and assistive technologies in [its element reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button). That's why replacing it with a clickable `<div>` is such a bad trade.

![An infographic titled Writing Accessible Buttons Everyone Can Use, listing six key practices for creating inclusive web buttons.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/55c8c123-c9df-4edb-9970-b8e3a93a8817/html-tag-button-accessible-design.jpg)

### The non-negotiables

A button should be:

- **Keyboard reachable:** Users must be able to Tab to it.
- **Keyboard activatable:** Native buttons support activation through standard keyboard interaction. Don't replace that with custom key handling unless you have to.
- **Visibly focused:** If someone tabs onto the button, they need to see where they are.
- **Clearly named:** The accessible name must communicate the action.

This is why a real `<button>` saves work. A `<div tabindex="0">` makes you rebuild semantics, keyboard behavior, and state announcements that the platform already gives you.

### Icon-only buttons need a real name

An "X" icon may be obvious visually, but accessibility APIs need an actual label. MDN notes that icon-only buttons still need a concise accessible name, and the button's content or labeling needs to make that purpose clear in [our guide to HTML labels](https://www.staticforms.dev/blog/label-tags-html).

Use either visible text, visually hidden text, or `aria-label` when the design has no visible label.

```html
<button type="button" aria-label="Close dialog" class="button-icon">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="M6 6l12 12M18 6L6 18" />
  </svg>
</button>
```

Or:

```html
<button type="button" class="button-icon">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="M6 6l12 12M18 6L6 18" />
  </svg>
  <span class="sr-only">Close dialog</span>
</button>
```

```css
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  white-space: nowrap;
  border: 0;
  clip: rect(0, 0, 0, 0);
}
```

> Don't hide meaningful button text with `display: none`. That removes it from the accessibility tree.

### Use ARIA for state, not as a substitute for semantics

ARIA helps when the button controls stateful UI. It doesn't turn the wrong element into the right one.

Use `aria-pressed` for toggle buttons:

```html
<button type="button" aria-pressed="false" id="mute-toggle">
  Mute
</button>
```

Use `aria-expanded` with `aria-controls` when a button shows or hides content:

```html
<button type="button" aria-expanded="false" aria-controls="faq-panel">
  Show answer
</button>

<div id="faq-panel" hidden>
  ...
</div>
```

### Keep labels honest

"Submit" is acceptable. "Go" is usually weak. "Request demo", "Send message", and "Download invoice" are better because users know what happens next.

That matters even more on forms. The button is often the final confirmation that the user's data is about to leave the page.

## JavaScript Interaction and Event Handling

Buttons are where your UI usually meets state. Loading, validation, disabling, analytics, dialog opening, optimistic updates. Most of the messy parts happen right after a click.

![A six-step infographic illustrating the process of handling user interactions with JavaScript buttons in web development.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/f050ca35-88c7-4bfa-9eb5-6f82c15af39c/html-tag-button-javascript-event.jpg)

### Click handling without fighting the browser

For a plain action button, the pattern is simple:

```html
<button type="button" id="copy-url">Copy URL</button>
```

```js
const copyButton = document.getElementById('copy-url');

copyButton.addEventListener('click', async () => {
  await navigator.clipboard.writeText(window.location.href);
  copyButton.textContent = 'Copied';
});
```

For submit buttons, decide whether you want native form submission or JavaScript-controlled submission. Don't mix them casually.

If you need custom validation or async logic first, intercept the submit event instead of only listening for button clicks:

```html
<form id="contact-form" action="https://api.example.com/contact" method="post">
  <input type="email" name="email" required />
  <button type="submit" id="submit-btn">Send</button>
</form>
```

```js
const form = document.getElementById('contact-form');
const submitButton = document.getElementById('submit-btn');

form.addEventListener('submit', async (event) => {
  event.preventDefault();

  submitButton.disabled = true;
  submitButton.textContent = 'Sending...';

  try {
    const formData = new FormData(form);

    const response = await fetch(form.action, {
      method: form.method,
      body: formData
    });

    if (!response.ok) {
      throw new Error('Request failed');
    }

    submitButton.textContent = 'Sent';
    form.reset();
  } catch (error) {
    submitButton.disabled = false;
    submitButton.textContent = 'Send';
  }
});
```

If you want a deeper walkthrough of JavaScript-powered form submissions, this guide on [HTML forms with JavaScript](https://www.staticforms.dev/blog/html-forms-with-javascript) is a practical companion.

### Prevent duplicate submissions

The most common button-related JavaScript bug after accidental submits is double submits. A user clicks twice because nothing changed visually after the first click.

Fix that with immediate state feedback:

- **Disable early:** Set `disabled = true` before the async call starts.
- **Change the label:** "Send" becoming "Sending..." confirms the click landed.
- **Recover on failure:** Re-enable on errors, validation failures, and network interruptions.

### Enable buttons from real state, not vibes

For validation-driven UIs, tie `disabled` to actual field validity or business rules.

```js
const emailInput = document.querySelector('input[name="email"]');
const saveButton = document.getElementById('save-btn');

function syncButtonState() {
  saveButton.disabled = !emailInput.checkValidity();
}

emailInput.addEventListener('input', syncButtonState);
syncButtonState();
```

That's better than enabling the button on any input event and hoping the submit handler catches the rest.

## Common Pitfalls and Browser Quirks

The html tag button isn't hard. It's just easy to underestimate. Most bugs come from a few repeat offenders.

![An infographic illustrating six common web development pitfalls and browser quirks when working with HTML buttons.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/9570cdd7-ea54-467d-89fb-9c04ff56e2ce/html-tag-button-common-pitfalls.jpg)

### The bugs I see most often

- **Accidental submission:** A button inside a form omits `type` and submits during unrelated UI actions.
- **Broken hosted forms:** For static-site form builders, the button is often the only user action that triggers the backend, so a misconfigured `type`, disabled state, or hidden control can break the flow without useful server-side logs, as noted in Lenovo's overview of [HTML button behavior](https://www.lenovo.com/us/en/glossary/html-button-tag/).
- **Reset misuse:** `type="reset"` clears more than users expect. It's rarely the right default for production forms.
- **Interactive nesting:** Putting a button inside a link, or vice versa, creates confusing click behavior and accessibility issues.
- **Event bubbling surprises:** Parent click handlers fire when you only meant to handle the button itself.

### Event bubbling can make good markup feel broken

A very normal pattern is a clickable card with a nested button. Then the user clicks "Delete" and the card's outer click handler also runs.

```html
<div class="card" id="card">
  <h3>Draft Post</h3>
  <button type="button" id="delete-btn">Delete</button>
</div>
```

```js
document.getElementById('card').addEventListener('click', () => {
  console.log('Open details');
});

document.getElementById('delete-btn').addEventListener('click', (event) => {
  event.stopPropagation();
  console.log('Delete item');
});
```

You don't always need `stopPropagation()`, but nested interactive patterns are where bubbling gets expensive.

> Test the button by clicking its text, its icon, and any surrounding padded area. Different click targets can expose event bugs fast.

### Browser styling still needs checking

Even with modern resets, buttons can differ in font inheritance, inner padding, focus presentation, and appearance defaults. If your design system supports Chrome, Safari, and Firefox, test all three before you call the component done.

A common failure path is applying a global class built for anchors to buttons and assuming they'll render identically. They usually won't. Buttons have their own default behavior, box model assumptions, and disabled states.

### Value debugging trips people up

If you expect a button's `name` and `value` to show up in submitted data, make sure the user manually clicked that submit button. A form submitted through script or Enter-key behavior may not include the same button intent you expected.

That's one of those bugs that looks like "backend inconsistency" but starts in the markup.

## Using Buttons in Frameworks and with Form Backends

Frameworks don't change what a button is. They mostly make it easier to hide the native behavior under abstractions.

### React and Next.js patterns

In React, always be explicit with `type`. That matters even for small component libraries because a generic `Button` component often ends up rendered inside forms later.

```jsx
import { useState } from 'react';

export default function ContactForm() {
  const [sending, setSending] = useState(false);

  return (
    <form
      action="https://api.staticforms.dev/submit"
      method="post"
      onSubmit={() => setSending(true)}
    >
      <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

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

      <label>
        Email
        <input type="email" name="email" required />
      </label>

      <label>
        Message
        <textarea name="message" required></textarea>
      </label>

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

      <button
        type="button"
        onClick={() => {
          console.log('Open help modal');
        }}
      >
        Help
      </button>
    </form>
  );
}
```

In Next.js app router projects, this same pattern still applies. Server Actions are useful in some cases, but plain HTML form posts are still a very practical option for static and mostly-static sites.

### Vue keeps the same rules

Vue's event syntax is different. The button semantics are not.

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

const sending = ref(false);

function handleSubmit() {
  sending.value = true;
}
</script>

<template>
  <form
    action="https://api.staticforms.dev/submit"
    method="post"
    @submit="handleSubmit"
  >
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

    <label>
      Email
      <input type="email" name="email" required />
    </label>

    <label>
      Message
      <textarea name="message" required />
    </label>

    <button type="submit" :disabled="sending">
      {{ sending ? 'Sending...' : 'Submit' }}
    </button>

    <button type="button" @click="console.log('Preview form')">
      Preview
    </button>
  </form>
</template>
```

The big framework mistake isn't Vue-specific or React-specific. It's assuming your custom `<Button>` component can infer intent safely. It usually can't.

### End-to-end form handling on static sites

For JAMstack sites, the button is often the handoff point from frontend to backend processing. The simplest setup is still a normal HTML `<form>` and a submit button that posts to a hosted endpoint.

```html
<form
  action="https://api.staticforms.dev/submit"
  method="post"
  enctype="multipart/form-data"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://example.com/thanks" />

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

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Resume
    <input type="file" name="resume" />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

  <label>
    <input type="checkbox" name="consent" required />
    I agree to the processing of my data
  </label>

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

That pattern works well when you want backend processing without maintaining your own server code. It's also where button details become operational details:

- **Spam protection:** If you use reCAPTCHA v2/v3, Cloudflare Turnstile, Altcha, or a honeypot, the submit button is part of the completion flow. A disabled or hidden button can break the entire path.
- **GDPR handling:** Consent controls are usually paired directly with the final submit action, so the button label and state need to align with what the form does.
- **File uploads:** File inputs need `enctype="multipart/form-data"` on the form, and your submit button should reflect upload state clearly. Size limits are a separate matter: Static Forms, for example, offers uploads on Starter and up and caps the whole submission at **4.5MB**, counting every file plus the other fields.
- **Email deliverability:** If notifications come from a custom domain, SPF, DKIM, and DMARC setup matter on the backend side, but the frontend still owns the last visible action the user trusts.

### Honest alternatives

Hosted form backends are one option, not the only one. Depending on the project, you might choose Formspree, Getform, Basin, Web3Forms, or a serverless function you maintain yourself.

The trade-off is usually simple. If you want complete control, own the backend. If you want the form to work with standard HTML on a static site and delegate delivery, spam filtering, webhooks, uploads, and notifications, a hosted endpoint is often the faster path.

---

If you want that plain HTML approach without building your own form handler, [Static Forms](https://www.staticforms.dev) is one practical option for static and JAMstack sites. You point your form's `action` to its hosted endpoint, use a normal `<button type="submit">`, and get form processing, spam protection options like reCAPTCHA v2 (plus v3 and Turnstile on Starter and up), GDPR tools, webhook routing and file uploads up to 4.5MB per submission on Starter and up, and custom-domain email support with SPF, DKIM, and DMARC on Pro and up.

---

## 10 Form UX Best Practices for Developers in 2026

Source: https://www.staticforms.dev/blog/form-ux-best-practices  
Date: 2026-05-28T09:52:28.116Z  
Author: Static Forms Team

A user lands on your signup page ready to act. They've already clicked the ad, trusted the recommendation, or decided your product is worth trying. Then the form asks for job title, company size, phone number, industry, team count, address, country, and a password with rules hidden inside placeholder text. On mobile, the button sits below the fold. They pause, lose momentum, and leave.

That's the true cost of bad form UX. Not just annoyance, but intent wasted at the most fragile point in the journey.

Forms aren't admin plumbing. They're the place where your interface asks users for effort. If that effort feels heavier than the value they expect back, they bail. Nielsen Norman Group's long-running [web form design guidance](https://www.nngroup.com/articles/web-form-design/) keeps returning to the same core idea: reduce friction with shorter forms, clear grouping, visible labels, and simple layouts. That advice has held up because the underlying problem hasn't changed. Users still scan first, estimate effort fast, and quit when the interaction feels messy.

Good form UX best practices aren't abstract design rules. They show up in HTML attributes, validation timing, keyboard types, field order, button copy, and what happens after submit. This guide stays at that level. You'll get 10 practical patterns you can implement in code, in a CMS, or in a no-code builder without turning your forms into a redesign project.

## 1. Minimize Form Fields and Steps

A signup form looks short in a planning doc. In production, every extra input adds hesitation, keyboard switching, validation risk, and one more reason to quit halfway through.

The fastest improvement is still the least glamorous one. Cut fields. Teams usually add inputs to satisfy reporting, lead scoring, or internal curiosity, then wonder why completion drops. If a field does not affect account creation, compliance, pricing, fulfillment, or the very next screen, remove it from the first step.

Slack-style onboarding works because it earns the right to ask for more later. Early signup asks for the minimum needed to create momentum. That trade-off matters. You get less data upfront, but more completed starts, and you can collect profile details after activation when the user already sees value.

![A laptop screen displaying a clean, modern create account form on a desk in a bright office.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/aff4a7d5-80b6-4000-bbbf-a528102b70b1/form-ux-best-practices-signup-form.jpg)

### Split complexity across steps the user can understand

Some forms really do need more information. Insurance quotes, tax prep, loan applications, and B2B onboarding often have legitimate data requirements. The mistake is showing all of it at once.

A better implementation pattern is progressive disclosure. Start with the smallest set that can move the user forward, then reveal the next decision only when it becomes relevant. Ask for email and password first. Show company fields only after the user chooses a business plan. Request billing details after plan selection, not before.

That structure reduces perceived effort and makes the code easier to maintain. Conditional sections can be driven from form state instead of shipping one oversized template with every possible field visible.

A simple review pass usually catches obvious cuts:

- Remove duplicate asks, like collecting email for signup and again for marketing preferences.
- Merge related inputs where format allows it, such as one "Full name" field instead of separate first and last name fields.
- Defer enrichment fields, like company size or job title, until after signup.
- Hide fields behind a choice, such as showing VAT ID only when "Business purchase" is selected.

For plain HTML forms, semantic grouping matters too. Use `<fieldset>` and `<legend>` so related questions read as one unit visually and to assistive tech. Static-site teams can use this guide to [grouping form sections with fieldset](https://www.staticforms.dev/blog/html-forms-fieldset).

> **Practical rule:** Every field should have a job. If it does not change routing, fulfillment, legal handling, or the next screen, it probably belongs later.

## 2. Clear and Descriptive Field Labels

A user opens a checkout form, sees a field labeled “Name,” and pauses. Cardholder name? Account name? Shipping recipient? That half-second of doubt is enough to cause bad input, extra corrections, or a dropped form.

Clear labels remove that hesitation. They tell people exactly what belongs in the field, and they give frontend teams a cleaner contract to build against. If the label says “Work email,” validation rules, autofill behavior, and error copy all get easier to define.

“Name” is vague. “Full name on card” is clear. “Phone” might work for a callback form, but if the number will be used for account alerts or SMS consent, say that in the label or helper text. Good forms reduce interpretation. Users should not have to guess what format, identity, or context you mean.

Keep labels visible at all times. Placeholder text can support an example, but it should not carry the whole instruction because it disappears as soon as typing starts. Floating labels also create trade-offs. They save space, but they often shrink text, reduce scan speed, and make review states harder to parse, especially on mobile.

![A computer screen showing a sign-up form with valid email input and an invalid confirmation email error.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/61724af4-6fbe-4761-9cd1-ba2879d0508a/form-ux-best-practices-form-validation.jpg)

### Better labels usually sound more specific, not longer

A simple rewrite pass usually improves form clarity fast:

- **Weak:** Name  
  **Better:** Full name
- **Weak:** Company  
  **Better:** Company name
- **Weak:** ID  
  **Better:** Order number
- **Weak:** Address  
  **Better:** Street address

Helper text should handle the part the label should not carry. The label identifies the data. The helper text explains the edge case, format, or consequence.

For example:
- **Label:** Mobile number  
  **Helper text:** Used for delivery updates by SMS
- **Label:** Tax ID  
  **Helper text:** Required for business invoices in the EU
- **Label:** Username  
  **Helper text:** 3 to 20 characters, letters and numbers only

That split matters in implementation too. Short, stable labels are easier to scan and localize. Helper text can change by market, plan, or selected options without forcing a full label rewrite.

Code-wise, keep it explicit:

```html
<label for="card-name">Full name on card</label>
<input id="card-name" name="cardName" autocomplete="cc-name" aria-describedby="card-name-help" />
<p id="card-name-help">Enter the name exactly as it appears on the card.</p>
```

Then connect the help text with `aria-describedby` when the extra instruction affects completion or validation. That prevents a common accessibility failure where helpful text is visible on screen but never announced to screen reader users. If you want to pair label clarity with field-level checks, this guide to [JavaScript form validation patterns](https://www.staticforms.dev/blog/form-validation-javascript) shows how to wire the two together without turning the form into a wall of warnings.

## 3. Real-time Validation and Error Feedback

A user finishes a long form, hits Submit, and gets five errors at once. At that point, the problem is no longer validation logic. It is recovery cost.

Real-time validation works when it reduces that cost without interrupting typing. The usual mistake is firing errors on the first keystroke. Email fields flash red before the address is complete. Password rules appear one by one in a way that feels punitive. A better default is to validate on blur, or once the field has enough input to judge meaningfully. For high-risk checks like username availability or coupon codes, debounce the request so the UI stays calm and the API does not get hammered.

The message also has to do real work. Users need the fix right where the error happens, in plain language, with enough detail to act on it.

![A person holding a smartphone showing a mobile user interface form for creating a new account.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/c03ec451-be8d-4024-97b7-e8f207406053/form-ux-best-practices-mobile-form.jpg)

### Show the fix next to the problem

Good:
- “Enter a valid email address, like name@company.com”
- “Password must include at least one number”
- “Choose a username that isn't already taken”

Bad:
- “Invalid input”
- “Submission failed”
- “Error 400”

A practical client-side pattern looks like this:

```html
<label for="email">Work email</label>
<input id="email" name="email" type="email" aria-describedby="email-error" />
<p id="email-error" role="alert"></p>
```

```js
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');

email.addEventListener('blur', () => {
  if (!email.validity.valid) {
    error.textContent = 'Enter a valid work email, like name@company.com.';
    email.setAttribute('aria-invalid', 'true');
  } else {
    error.textContent = '';
    email.removeAttribute('aria-invalid');
  }
});
```

That pattern is a solid baseline, but production forms usually need a little more discipline. Keep the error container in the DOM from the start so layout does not jump. Tie the message to the field with `aria-describedby`. Set `aria-invalid="true"` only when the field fails validation. If you validate during typing, reserve that for supportive feedback such as password strength or character limits, not aggressive error states.

For no-code builders, the same rule applies. Turn on inline validation, place the message under the field, and rewrite generic system text. “This field is required” is acceptable. “Enter your VAT ID to generate a business invoice” is better when the context matters.

Then validate again on the server. Client-side validation improves completion and reduces avoidable mistakes. It does not protect your backend, and it cannot catch business rules that depend on server state.

If you want a fuller implementation reference, this guide to [JavaScript form validation patterns](https://www.staticforms.dev/blog/form-validation-javascript) shows how to handle blur events, async checks, and accessible error messaging without turning the form into a wall of warnings.

## 4. Smart Auto-fill and Pre-population

A user opens your signup form on a phone, taps the first field, and expects the device to do some of the work. If the browser can fill name, email, address, and company in one pass, the form feels short. If it cannot, the same form suddenly feels longer than it is.

Auto-fill support is one of those implementation details users rarely praise and quickly notice when it fails. Teams usually break it in predictable ways: custom inputs that hide the underlying field, vague `name` attributes, `autocomplete="off"` on the whole form, or design systems that look polished but confuse password managers and browsers.

### Use browser hints the way browsers expect them

A few attributes do a lot of work here:

```html
<input name="givenName" autocomplete="given-name" />
<input name="familyName" autocomplete="family-name" />
<input name="email" type="email" autocomplete="email" />
<input name="company" autocomplete="organization" />
<input name="address1" autocomplete="street-address" />
<input name="postalCode" autocomplete="postal-code" />
```

The practical rule is simple. Your label, `name`, and `autocomplete` value should all point to the same meaning. If the visible label says "Work email" but the underlying field name is `contact_1` and the component strips native attributes, browser autofill gets unreliable fast.

Pre-population adds another layer. If a user is signed in, fill stable account data such as name, email, shipping address, or company details pulled from their profile. Do not pre-select consent boxes, legal attestations, or anything that changes the user's stated intent. That saves keystrokes without creating compliance problems.

I have seen prefill backfire when teams hide editable values inside collapsed sections. The data is technically there, but users do not trust what they cannot easily review. A visible filled field with a clear edit path beats a clever shortcut every time.

A few implementation rules help:

- **Pre-fill data that is likely still correct:** saved addresses, invoice details, account email
- **Show the value plainly:** let users confirm it at a glance
- **Make edits cheap:** one tap or click, no modal maze
- **Respect shared-device risk:** avoid exposing sensitive profile data in the wrong context

For no-code builders, the same principle applies. Turn on field prefill from logged-in profile data or URL parameters only for values the user would reasonably expect. Map browser-recognized field types where the tool allows it. If the builder offers "disable autocomplete" as a styling or privacy toggle, use it sparingly, because it often hurts completion more than it helps.

> Browser autofill works best when field labels, HTML attributes, and stored user data all describe the same thing.

## 5. Mobile-first and Responsive Form Design

Desktop-first forms usually fail in small, annoying ways. Inputs are too short. Labels wrap badly. Buttons sit too close together. The keyboard covers the current field. None of those issues look severe in isolation. Together, they kill momentum.

The more useful mobile conversation now goes beyond “make it single-column.” Newer roundups highlight device-specific friction reducers such as native features, address lookup, and minimum 48-pixel touch targets in [Venture Harbour's form design best-practice overview](https://ventureharbour.com/form-design-best-practices/). For a hard floor, WCAG 2.2 success criterion [2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) (Level AA) asks for pointer targets of at least 24 by 24 CSS pixels, and the AAA criterion 2.5.5 asks for 44 by 44. That advice matters because a form can be technically responsive and still feel terrible on a phone.

Typeform's single-question flow is one answer to that problem. Stripe's mobile payment forms are another. Different interaction models, same principle: reduce thumb effort and decision load.

### Build for thumbs, keyboards, and bad conditions

These implementation details matter more than visual polish:

- **Use the right input type:** `type="email"`, `type="tel"`, `inputmode="numeric"`.
- **Keep touch targets roomy:** Small hit areas create accidental taps and missed checkboxes.
- **Support native lookups:** Address autocomplete is often better than free typing.
- **Keep the primary button visible:** Don't make users scroll blindly to find the action.

Here's a simple example:

```html
<input type="email" autocomplete="email" />
<input type="tel" autocomplete="tel" />
<input inputmode="numeric" pattern="[0-9]*" />
```

On mobile, I also avoid side-by-side fields unless the pairing is obvious and short, such as month and year. Even then, I test on a real phone. Browser emulation won't show you keyboard overlap, lag on weak networks, or how cramped a form feels outdoors in bright light.

## 6. Progress Indicators for Multi-step Forms

A user reaches step two, sees no step count, no estimate, and no sign of what comes next. Completion drops fast in that moment, not because the fields got harder, but because the process stopped feeling finite.

That is the primary job of a progress indicator. It reduces uncertainty. In frontend terms, it sets expectations before the user decides whether to keep going.

Multi-step forms work best when each screen answers one clear question: where am I, what is this step for, and how much is left? Booking flows from products like Airbnb handle this well because each stage has a distinct purpose. Dates. Guests. Payment. Review. Users do not need to guess what the form is trying to collect.

### Match the progress pattern to the form logic

Use numbered steps for a fixed sequence. They set a stable expectation and are easy to label with plain language.

- **Step 1 of 3**
- **Account**
- **Billing**
- **Confirm**

Use a percentage bar only when the path is predictable. If later answers reveal extra steps, a percentage can become misleading fast. I avoid percent-based progress on conditional forms unless I can calculate progress against the user's actual path, not the maximum possible path.

Here is a simple accessible baseline:

```html
<p aria-live="polite">Step 2 of 4</p>
<h3>Billing details</h3>
```

That markup is enough to improve orientation, but implementation details decide whether the experience holds up in production.

- **Keep previous answers when users go back:** Losing state makes the progress UI feel misleading.
- **Group fields by user intent:** “Contact details” and “Payment” are clearer than arbitrary splits like one field per screen.
- **Show upcoming steps clearly:** If review and confirmation are separate, say so.
- **Handle conditional branches carefully:** Update the indicator without jumping backward or renumbering in confusing ways.

The microcopy matters too. “Step 2 of 4: Billing details” works better than “Continue setup” because it tells users both position and purpose. In no-code builders, this usually means turning on visible step labels, not just the bar. In custom builds, store the current step and completed steps in state so the UI, validation, and analytics stay aligned.

A progress indicator cannot fix a badly sequenced form. It does make a well-structured flow feel manageable, which is often the difference between a form that gets finished and one that gets abandoned.

## 7. Sufficient and Accessible Visual Contrast and Typography

Many forms are technically functional and still hard to use because the text is faint, the labels are tiny, or the error state relies on color alone.

This gets worse on mobile. Glare, motion, low battery brightness, and older screens all punish low-contrast UI. A form that looked clean in a design review can become unreadable during actual use. That's why form UX best practices should include typography and contrast as interaction decisions, not just branding decisions.

### Make the form readable before you make it elegant

I default to visible labels, readable body text, and generous spacing before adding any visual refinement. Apple's system typography and Google's Material patterns both tend to feel solid because they prioritize legibility first.

A few practical checks catch most of the usual mistakes:

- **Increase label contrast:** Light gray labels often disappear against white inputs.
- **Use clear type sizes:** Small text creates zooming and rereading.
- **Don't rely on red alone:** Pair error color with text and iconography.
- **Preserve focus states:** Custom outlines often get removed and never replaced.

Here's a safe baseline:

```css
label {
  font-size: 1rem;
  color: #1f2937;
}

input {
  font-size: 1rem;
  line-height: 1.5;
  padding: 0.875rem 1rem;
  border: 1px solid #6b7280;
}

input:focus {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
}
```

You don't need a dramatic design system to make forms easier to complete. You need text people can read, controls they can identify, and states they can distinguish quickly.

## 8. Contextual Help, Tooltips, and Inline Assistance

Some fields need explanation. The mistake is hiding that explanation in the wrong place.

A tooltip icon beside every label usually looks tidy and works poorly, especially on mobile. Many users won't tap it, won't notice it, or won't remember the content after it disappears. Inline help works better when the field is complex, such as password rules, username constraints, tax identifiers, or delivery instructions.

GitHub often does this well around repository settings. The interface keeps advanced guidance close to the control without turning every screen into a wall of copy.

### Put help where the confusion happens

Use helper text under the field when:
- the format is unusual
- the data has a business-specific rule
- the user may worry why you need it

Examples of useful microcopy:
- “We'll use this email for receipts and account alerts.”
- “Use the legal business name shown on invoices.”
- “Optional. Add apartment or suite if needed.”

Short beats clever here. One or two lines is usually enough.

> Don't make users open a tooltip to understand a required field.

A practical pattern:

```html
<label for="vat-id">VAT ID</label>
<input id="vat-id" name="vatId" aria-describedby="vat-help" />
<p id="vat-help">Only required for businesses that need tax-compliant invoices.</p>
```

Mailchimp-style examples are useful when they match real expectations. “name@company.com” is better than “example@example.com” if you're collecting work emails. The closer the hint is to what users type, the less translation work they have to do.

## 9. Clear Call-to-action Button Design and Copy

“Submit” is rarely the best label.

Your button is the commitment point. Users look at it to confirm what happens next. If the copy is vague, they hesitate. If the state is unclear, they tap twice. If the button blends into the page, they scroll around to find the finish line.

Slack uses action-specific copy like “Continue with Email.” That works because it describes the next move, not the system event. “Create account,” “Send request,” “Get quote,” and “Book demo” are stronger than generic labels because they confirm intent.

### The button should answer one question

That question is: what happens when I press this?

A few practical patterns help:
- **Use explicit verbs:** “Start free trial” beats “Continue.”
- **Show loading state:** Replace the label with “Sending…” or add a spinner.
- **Prevent duplicate submits:** Disable while the request is in flight.
- **Keep it visually primary:** Users shouldn't mistake “Cancel” for the main action.

Code example:

```html
<button type="submit" id="submitBtn">Create account</button>
```

```js
form.addEventListener('submit', () => {
  submitBtn.disabled = true;
  submitBtn.textContent = 'Creating account...';
});
```

This is also where post-submit UX matters. A good form doesn't just send data. It confirms success in plain language. If a support request was sent, say when the user should expect a reply. If an email confirmation is coming, tell them where to look.

With Static Forms, a hidden `redirectTo` field sends people to your own thank-you page after a successful submission, and auto-responders (Starter plan and up) send the confirmation email for you.

Google, Stripe, and Typeform all handle button states cleanly because the interface acknowledges the action immediately. That tiny feedback loop prevents a lot of resubmits and a lot of doubt.

## 10. Security, Trust Signals, and Privacy Transparency

Some forms fail because they ask too much. Others fail because they don't explain enough.

If you collect personal data, users want to know what happens next. They want to know why you need the information, whether the connection is secure, whether they're signing up for marketing, and whether the message will go to a real domain. Luke Wroblewski's long-standing work on web forms also surfaces a harder trade-off that many best-practice lists skip: reducing friction while still handling consent, validation, anti-abuse protections, and privacy-sensitive operations in a lightweight way, as discussed in [Luke Wroblewski's web forms reference](https://static.lukew.com/webforms_lukew.pdf).

That means “fewer fields” isn't the whole story. Sometimes the right extra element is a consent checkbox, a short privacy note, or a confirmation message that explains retention and next steps.

### Add trust without adding clutter

Useful trust elements include:
- **A plain-language privacy note:** “We'll only use your email to reply to this request.”
- **Consent that matches the use case:** Separate support follow-up from newsletter signup.
- **Visible secure transport:** HTTPS is baseline, not a badge of honor.
- **Anti-spam that respects users:** Honeypots and modern challenge tools are often less disruptive than old-school CAPTCHAs.

If you're hardening a public form, this guide on [spam protection for website forms](https://www.staticforms.dev/blog/spam-email-bot) covers practical ways to reduce bot abuse without turning every submission into a puzzle. For a low-friction challenge, [Cloudflare Turnstile best practices](/blog/cloudflare-turnstile-best-practices) shows how to keep it invisible for most visitors. It also helps to follow broader operational guidance like [NiKa Consulting Group's security advice](https://www.nikaconsulting.co.nz/why-ssl-and-better-security-matters-for-your-website/) when reviewing SSL, trust, and basic site security expectations.

For privacy-sensitive forms, I like microcopy such as:
- “We'll respond to this inquiry by email. No marketing unless you opt in.”
- “Your file is only used to review this request.”
- “You can request export or deletion of your data.”

That kind of transparency reduces uncertainty. It also gives legal and compliance requirements a cleaner UX surface.

If the form takes attachments, the [HTML file upload guide](/blog/file-upload-html) covers labelled upload fields, size checks and server-side safety.

## Top 10 Form UX Best Practices Comparison

| Feature | Implementation complexity | Resource requirements | Expected outcomes | Ideal use cases | Key advantages |
|---|---:|---|---|---|---|
| Minimize Form Fields and Steps | Low–Medium (requires analysis) | Analytics, user research, A/B testing | Higher completion rates, lower abandonment | Quick signups, lead capture, static sites | Faster submissions, improved conversions |
| Clear and Descriptive Field Labels | Low | Copywriting, accessibility review | Fewer errors, faster completion | Any form, accessibility-focused sites | Improved clarity and screen reader support |
| Real-time Validation and Error Feedback | Medium–High | JavaScript dev, testing, accessibility work | Better data quality, fewer backend errors | Payment, signups, complex inputs | Immediate fixes, reduced frustration |
| Smart Auto-fill and Pre-population | Medium | Dev work, privacy considerations, cross-browser testing | Faster completion, higher conversions | Returning users, checkouts, mobile users | Reduces typing, improves mobile UX |
| Mobile-First and Responsive Form Design | Medium | Responsive design, device testing | Higher mobile completion, fewer input errors | Mobile-heavy traffic, responsive sites | Touch-friendly, context-aware inputs |
| Progress Indicators for Multi-Step Forms | Medium | UI/UX design, state management | Increased completion on long forms | Onboarding, multi-step checkout, surveys | Reduces perceived complexity, guides users |
| Sufficient and Accessible Visual Contrast and Typography | Low–Medium | Design review, accessibility audits | Improved readability, WCAG compliance | Public-facing and regulated sites | Broader accessibility, better readability |
| Contextual Help, Tooltips, and Inline Assistance | Low–Medium | UX writing, lightweight UI components | Fewer support requests, more accurate data | Complex fields, infrequent tasks | Clarifies expectations without clutter |
| Clear Call-to-Action Button Design and Copy | Low | Design and copy testing | Higher conversions, fewer duplicate submits | All forms, critical actions | Clear intent, better accessibility and feedback |
| Security, Trust Signals, and Privacy Transparency | Medium–High | Legal review, security implementation, compliance | Increased user trust, legal compliance | Sensitive data collection, regulated industries | Builds confidence, protects user data and brand |

## Build Forms That Convert, Not Confuse

Good forms don't feel impressive. They feel easy.

That's usually the result of small decisions made well. You cut fields that don't earn their place. You keep labels visible. You validate at the right time. You let browsers help with autofill. You build for thumbs instead of giant desktop monitors. You explain complex fields where confusion starts, not after submission fails. You make the button specific. You show enough privacy and security context that users can trust the interaction without reading a policy first.

The reason form UX work is so valuable is that users notice every rough edge immediately. They don't need to articulate the issue. They just stop. A label is vague, a keyboard is wrong, an error message is useless, a step feels endless, or the submit action feels risky. Any one of those can break the flow. In aggregate, they make the form feel heavier than it is.

This is also why strong form UX best practices live in implementation details, not just design principles. The difference between a frustrating form and a high-performing one is often hidden in field names, `autocomplete` attributes, validation timing, touch target size, focus styles, and the sentence under a checkbox. Teams that treat forms as a frontend systems problem, not just a UI component, usually end up with better completion and fewer support issues.

If you're improving an existing form, don't redesign everything at once. Pick the clearest point of friction and fix that first. Remove three fields. Rewrite one vague label. Replace placeholders with visible labels. Add inline error text. Test the mobile keyboard flow on a real device. Those changes are small enough to ship quickly and meaningful enough to affect completion.

If you want a simpler backend path while refining the frontend experience, a hosted form handler can help keep your implementation lean. Static Forms is one option if you want to process HTML form submissions without building your own server logic, and its `redirectTo` field lets you send people to your own thank-you page. For a starting point that already follows these basics, the free [HTML form generator](/tools/form-generator) gives you labelled, accessible contact form markup to build on.

The best forms respect user effort. That's the standard worth building toward.

---

If you're polishing the frontend but don't want to maintain form processing yourself, [Static Forms](https://www.staticforms.dev) gives you a hosted endpoint for HTML forms with options for email delivery, webhooks and file uploads (Starter and up), spam protection, and GDPR-related controls. It's a practical fit for static sites and modern frameworks when you want to spend more time on UX and less time wiring backend form handling.

---

## 10 Best Contact Form for WordPress Plugins in 2026

Source: https://www.staticforms.dev/blog/best-contact-form-for-wordpress  
Date: 2026-05-19T09:26:42.191Z  
Author: Static Forms Team

A contact form looks simple until the site goes live and the problems start. Leads disappear into crowded inboxes. Spam slips through. A client asks for file uploads, conditional logic, or a CRM connection, and the cheap plugin choice suddenly turns into a rebuild.

That is why choosing the best contact form for wordpress is less about the form builder and more about the operating model behind it. You are deciding where submissions are stored, how notifications are handled, what happens when email delivery fails, how much plugin weight you add to WordPress, and who has to maintain all of it six months from now.

The right answer changes by site type. A solo blogger can get by with a simple free plugin. An agency building lead-gen sites, membership sites, or client funnels usually needs better integrations, stronger spam controls, cleaner handoff, and fewer support headaches. Developers also have a different set of priorities. They often want full frontend control without forcing every project into another heavy builder inside wp-admin.

That is why this guide does more than rank familiar plugins. It covers the usual WordPress form tools, but it also includes Static Forms, a backend form service for WordPress projects that do not need a full plugin-based form management layer. If you want to see how that setup works in practice, the <a href="https://www.staticforms.dev/docs/wordpress">Static Forms WordPress integration guide</a> shows the implementation path clearly.

The recommendations are also framed by user type, not just feature lists. Some tools are better for no-code site owners. Some make more sense for developers. Others earn their keep on agency builds where licensing, maintainability, and client handoff matter as much as the form itself.

## 1. Static Forms

![Static Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/157b99e3-d24c-4535-95e8-c6426fd770a5/best-contact-form-for-wordpress-static-forms.jpg)

Static Forms is the option I reach for when a site doesn't need a heavy WordPress form plugin. If the goal is simple, reliable submission handling with strong spam protection, branded email delivery, and webhook support (Starter plan and up), a backend service is often cleaner than adding another large plugin stack.

That matters more than most buyers realize. A lot of "best contact form for wordpress" lists assume every site wants a drag-and-drop builder inside wp-admin. Many don't. Some sites just need a clean HTML form, a submission endpoint, and reliable delivery without extra database clutter or builder UI.

### Why it stands out on modern WordPress builds

Static Forms fits especially well on lightweight WordPress builds, headless projects, landing pages, and agency sites where you want control over the front end and don't want form logic to dictate the whole implementation. You point your form action at the service, wire up the fields, and you're done.

For teams that care about privacy and operational controls, its capabilities become especially compelling. The product is built around privacy-first handling, with export and deletion controls, consent features, webhook integrations and file uploads up to 4.5MB per submission on Starter and up, and custom-domain sending with SPF, DKIM, and DMARC on Pro and up.

A practical example: if you're building a brochure site for a law firm, consultancy, or B2B SaaS company, you can keep the front end custom, submit to Static Forms, forward leads into Slack or your CRM through webhooks (Starter plan and up), and avoid giving editors a form builder they may never use correctly.

> **Practical rule:** If your team mostly needs reliable submissions, spam filtering, notifications, exports, and automations, a backend service is often a better fit than a feature-packed builder.

### What works well in production

The setup is quick, and the operational features are unusually strong for this category. It supports reCAPTCHA v2/v3, Cloudflare Turnstile, Altcha (v3, Turnstile, and Altcha on Starter and up), honeypots, file uploads (Starter and up), CSV export, and AI-powered auto-replies (Starter and up) billed from a pay-as-you-go AI credit wallet.

It also has a free-forever plan, with Pro starting at $9/month on [Static Forms](https://www.staticforms.dev).

If you want the WordPress implementation path, use the [Static Forms WordPress setup guide](https://www.staticforms.dev/docs/wordpress).

- **Best for no-code and custom front ends:** Works well when the form markup is simple but the delivery workflow still matters.
- **Best for agencies:** You can standardize one backend across WordPress, Webflow, and static client sites.
- **Watch the limits:** The 4.5MB cap on each submission, counting every file plus the other fields, won't suit intake flows that require larger attachments.

## 2. WPForms

![WPForms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/e5bd0765-64bb-4371-a023-9337073e72a6/best-contact-form-for-wordpress-form-builder.jpg)

A common client handoff looks like this: the site is live, the forms work, and six months later the office manager needs to change a field, add a notification, or publish a second inquiry form without calling a developer. WPForms fits that situation better than almost anything else on this list.

It is the safe recommendation for small businesses, nonprofits, and marketing teams that want a polished builder inside WordPress. The interface is easy to understand, the templates shorten setup time, and basic tasks stay manageable for non-technical admins after launch. That matters more than feature count on many projects.

### Where WPForms earns its popularity

WPForms is strong when speed and clarity matter more than deep customization. You can launch a contact form, quote request, newsletter signup, or simple payment form quickly, and the admin experience usually stays clean enough that clients do not break things the first week after handoff.

WPForms has 5+ million active installs on WordPress.org. It is widely used, broadly supported, and familiar to freelancers inheriting existing sites.

I usually recommend it for brochure sites, local service businesses, and straightforward lead generation builds. A roofing company, dentist, or accounting firm rarely needs a complicated workflow engine. They need forms that look professional, route submissions correctly, and are simple to update later.

> Easy to manage beats endlessly flexible on sites where the client will own day-to-day edits.

### The trade-offs to price before you commit

WPForms gets more expensive as requirements expand. The free version is useful, but many features clients ask for after launch, such as advanced payments, marketing integrations, conditional behavior, and higher-end templates, push you into paid tiers. That is not a flaw. It is just the pricing reality, and it should be part of the recommendation from day one.

There is also a ceiling to how far I want to stretch it on complex builds. If a project needs heavy logic, layered approval flows, or highly customized data handling, I start comparing it against Gravity Forms, WS Form, or even a service-based setup like Static Forms for a custom front end. WPForms is best when the job is to get reliable forms live fast, not to turn WordPress into an internal operations system.

Spam control needs attention too. WPForms supports the usual defenses, but no form plugin is maintenance-free once a site starts attracting junk submissions. Use CAPTCHA carefully, keep notifications tidy, and review a practical guide to [stopping form spam and bot email problems](https://www.staticforms.dev/blog/spam-email-bot) before the inbox turns into a cleanup project.

## 3. Gravity Forms

![Gravity Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/ab3795f8-aeb6-4131-9e45-5da3bad7cf70/best-contact-form-for-wordpress-gravity-forms.jpg)

A client asks for "a contact form," then the scope turns into lead routing, conditional follow-ups, payment collection, file uploads, and CRM handoff. That is usually the point where Gravity Forms enters the conversation.

Gravity Forms fits projects where the form is part of the business process, not just a way to send an email. I use it on builds that need structured intake, approval paths, registrations, or data pushed into other systems without bolting together a pile of lighter tools. For agencies, that matters because complexity tends to show up after launch, not before it.

### Best fit for agencies and process-heavy sites

Gravity Forms earns its place on sites with actual operational logic behind the form. Good examples include franchise lead distribution, internal service requests, multi-step applications, event registration, and gated user flows where each answer changes what happens next.

The add-on ecosystem is a big reason teams stick with it. There is a mature market around Gravity Forms, and that reduces risk on custom builds. If a client later asks for e-signatures, payments, user registration, or a connection to a CRM, there is a decent chance the path already exists. That is a different buying decision from a no-code plugin like WPForms, and it is also different from a backend service such as Static Forms, where the strength is pairing a custom front end with a separate submission handler.

One practical pattern I see often is a university or multi-location business using a single Gravity Forms setup to handle different inquiry types. Conditional logic controls which fields appear, who gets notified, what confirmation is shown, and where the submission goes next. You can build that cleanly inside WordPress if the team is willing to own the setup.

### Trade-offs that show up in real projects

Gravity Forms asks more from the implementer. The builder is capable, but non-technical editors do not always find it as approachable as more beginner-focused products. Styling can also take extra work, especially on sites with a highly customized theme or strict design system.

Cost needs a sober look too. The base license may cover the initial brief, then a client wants advanced integrations or a specific workflow and the required license tier changes. That is normal for this category, but it should be discussed before the proposal is signed.

I also would not choose Gravity Forms for every small business site. If the job is a basic inquiry form on a brochure site, this is often more system than the client needs. In those cases, a simpler plugin is easier to hand off and easier to support. If the project needs a custom front end with a lightweight backend, a service approach can be cleaner as well.

- **Choose Gravity Forms for process-heavy builds:** It handles conditional logic, multi-step flows, registrations, and integrations well.
- **Skip it for simple brochure sites:** A basic contact form rarely justifies the extra setup and license cost.
- **Document the build before handoff:** Complex notification rules, feeds, and field logic can confuse the next person in the admin.

## 4. Ninja Forms

![Ninja Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/acbf55f6-041e-48f4-8d92-deaf11237592/best-contact-form-for-wordpress-ninja-forms.jpg)

A common client scenario goes like this. The site only needs a basic contact form at launch, but everyone knows the request list will grow after the first campaign, event signup, or intake workflow. Ninja Forms fits that kind of project well because the free version is usable enough to start with, and the paid add-ons let you expand later.

That flexibility is a key selling point. You can build straightforward contact and inquiry forms without buying into a full premium stack on day one, which makes it attractive for small businesses, nonprofits, and agencies working with phased budgets.

I usually put Ninja Forms in the middle ground. It gives non-technical teams a builder they can work with, but it is also modular enough for developers who want to add only the features a project needs. That makes it a reasonable alternative when WPForms feels too packaged and Gravity Forms feels heavier than the brief requires.

The catch is pricing drift.

Modular billing looks efficient at first. Then a client asks for conditional logic, payment collection, email marketing sync, file uploads, or a CRM connection, and the total cost starts to move. On a single site, that may still be fine. Across several client builds with slightly different requirements, it gets harder to standardize and harder to predict support costs.

That is the trade-off I would call out before recommending it to an agency or freelance team. Ninja Forms works best when the future roadmap is still uncertain and you want to avoid overbuying early. If the scope is already clear and you know the form will need several advanced features, a more bundled product can be cheaper and simpler to maintain.

It also sits in an interesting spot in this list because not every project should stay inside WordPress forever. If the goal is a lightweight front end with less plugin overhead, a backend service such as Static Forms may be cleaner. If the team wants form management in the WordPress dashboard and expects gradual feature creep, Ninja Forms is still a practical option.

- **Choose Ninja Forms for phased projects:** It is a good fit when the site starts simple and the form stack will probably expand later.
- **Watch add-on costs early:** The budget can change quickly once integrations and workflow features are added.
- **Good for agencies that scope carefully:** It works best when someone is tracking which features each client needs, instead of buying add-ons reactively.

## 5. Formidable Forms

![Formidable Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/f939e8f8-e4dd-48b2-8e8f-a4cec418ebb9/best-contact-form-for-wordpress-form-builder.jpg)

A client asks for more than a contact form. They want a quote calculator this month, a searchable directory next quarter, and front-end submissions that publish to the site after moderation. That is the kind of project where Formidable Forms starts to make sense.

I rarely recommend it for simple lead capture. I do recommend it when the form is really the input layer for a larger data workflow inside WordPress.

### Where it earns its keep

Formidable's core advantage is Views. You can collect structured data, store it in WordPress, and publish it back out as tables, grids, calendars, directories, or other front-end listings without stitching together several separate plugins.

That matters in real builds. A local business directory, scholarship listing, equipment rental calculator, or internal resource hub can live in one system instead of a form plugin plus custom post type work plus extra display tooling. Fewer moving parts usually means fewer plugin conflicts and less maintenance later.

It also fills a different role than a backend form service like Static Forms. Static Forms is a cleaner fit when the site just needs lightweight form handling without adding more WordPress overhead. Formidable is for teams that want the data to stay inside WordPress and power visible site features.

### Where teams misjudge it

The mistake is buying it for a basic contact page.

Formidable has more setup overhead than beginner-focused builders, and that cost is real. You need to think through field structure, entry management, display logic, and who will maintain it after launch. For an agency, that can be a good trade if the client is paying for custom workflows. For a small brochure site, it is usually unnecessary complexity.

The interface is capable, but it assumes the builder has a plan. That is why developers and technically minded agencies tend to get more value from it than no-code users who just want a form live by the end of the afternoon.

- **Best for agencies building custom workflows:** Strong choice for calculators, directories, application forms, and user-submitted content.
- **Best for developer-led WordPress projects:** Good fit when form data needs to be displayed, filtered, or edited on the front end.
- **Weak fit for simple contact forms:** If the goal is fast setup and low client training overhead, a lighter tool is easier to justify.

## 6. Fluent Forms

![Fluent Forms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/df0f58eb-a0dd-483e-9bad-b40fe8907848/best-contact-form-for-wordpress-form-plugin.jpg)

Fluent Forms appeals to a specific kind of buyer: someone who wants a modern UI, plenty of built-in capability, and a plugin that feels less bloated than some of the older heavyweights.

I tend to recommend it for agencies managing multiple SMB sites where speed of delivery matters but the client still wants more than a barebones contact form. It often feels like a practical middle ground.

### Why agencies like it

You get drag-and-drop building, multi-step forms, partial entries, conversational forms, reporting, and a broad integrations list without the product feeling as fragmented as some add-on-driven stacks.

A practical example: for a SaaS landing page, Fluent Forms works well if marketing wants one lead form, one demo request form, one survey flow, and some automation into tools like Airtable or Sheets. It covers a lot of common growth use cases in one place.

The main reason it makes this list isn't hype. It's value density. Teams often discover they can cover most real-world requests without shopping for extra components right away.

### Where to be careful

Fluent Forms has a smaller third-party ecosystem than the oldest incumbents. That's usually fine until you need something oddly specific.

It's also worth remembering a broader market gap that many buyers miss. Feature-rich builders can become a burden on lightweight sites. Some simpler options specifically market themselves as lightweight and loading no JavaScript — a reminder to match the tool to the site. On a marketing site with lots of scripts already loaded, the trade-off may be fine. On a stripped-down performance build, it may not be.

## 7. Forminator

![Forminator (WPMU DEV)](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/5d5ac121-d6be-4a90-81c5-e097bcfe24c4/best-contact-form-for-wordpress-form-builder.jpg)

A common client request goes like this: they start by asking for a contact form, then add a quote calculator, a lead quiz, a poll, and a payment field two weeks later. Forminator exists for that kind of scope creep.

It is one of the more capable free-first options in WordPress if the site needs interactive marketing elements as well as standard forms. Beyond contact forms, it covers polls, quizzes, calculations, and payments in one plugin. That can save time on small builds where installing separate tools would create more maintenance work than the site justifies.

### Best for marketing sites that want more than form submissions

Forminator fits teams using forms to qualify leads, test offers, or collect richer first-party data. A financial advisor, mortgage broker, or agency can run an inquiry form, a basic calculator, and a quiz-style intake flow from the same interface. For that kind of site, keeping everything under one system is cleaner than mixing a form plugin with a separate quiz product and hoping the styling stays consistent.

There is also a practical agency angle here. If you already work inside the WPMU DEV ecosystem, Forminator benefits from that shared environment. Support, updates, and account management feel less scattered.

That said, this is not the same kind of recommendation as Static Forms. Static Forms is a backend service choice for developers who want to keep the frontend minimal and skip a full WordPress form stack. Forminator sits on the opposite side of that decision. It is for site owners who want more built-in interface, more marketing features, and less custom implementation work.

### Where to be careful

The trade-off is straightforward. More capability usually means more plugin surface area, more settings, and more things to test after updates. If the site only needs a fast contact form with basic delivery, Forminator can be excessive.

Some useful features also make more sense if you are already bought into the wider WPMU DEV toolset. That is not a problem, but it is a real platform decision, not just a form decision.

A form plugin touches public inputs, email routing, uploads, validation, and stored submission data. Treat it like production infrastructure. Keep it updated, test notifications after changes, and review spam protection before launch.

For no-code users who want quizzes or calculators without adding another service, Forminator is a strong option. For developers building lean sites, it may feel heavier than necessary.

## 8. HappyForms

![HappyForms](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/29c5a012-942f-4325-9612-9c8048f3d2a6/best-contact-form-for-wordpress-form-builder.jpg)

HappyForms is one of the simpler recommendations in this list, and that's a good thing. It's designed for people who don't want a sprawling add-on ecosystem or a dashboard full of workflow options they'll never touch.

The Customizer-based live editing experience still feels approachable, especially for small teams that are already comfortable making basic design changes inside WordPress.

### Best for straightforward site owners

HappyForms is a good fit for local businesses, creators, and small service sites that want conditional logic, multi-page support, payments, and a few marketing integrations without turning forms into a full operational system.

A practical example: a wedding photographer site might use HappyForms for inquiries, package requests, and session deposits. The owner can preview edits as they work, which reduces the fear that often comes with builder interfaces.

This kind of product is easy to underestimate. Not every client wants "enterprise workflow depth." Many just want a form tool that doesn't fight them.

### Where it tops out

The ecosystem is smaller than the biggest names, and that matters once needs become more custom. Agencies building advanced portals, front-end data applications, or extensively integrated sales workflows will usually outgrow it.

Still, there's a lot to like in products that avoid needless complexity. HappyForms keeps the scope tight, and on the right site, that restraint is a strength.

- **Good fit:** Small business sites, portfolios, brochure sites, and solo operators.
- **Less ideal:** Large workflows, complex reporting, or highly customized agency builds.
- **Main advantage:** You don't spend time managing extra moving parts.

## 9. WS Form

![WS Form](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/3f9a6643-a716-46a7-bc24-b480e8e64fb1/best-contact-form-for-wordpress-form-templates.jpg)

WS Form is for people who read form documentation on purpose. That's not a joke. It's a serious product for developers, technical site builders, and agencies that care about deep field control, accessibility, calculated logic, and efficient handling of large form setups.

It doesn't get recommended as often in mainstream beginner roundups, but experienced WordPress builders often appreciate tools like this because they expose more of the underlying machinery.

### Why developers rate it highly

WS Form is feature-complete in the way technical users tend to value. Conditional logic, calculated fields, repeaters, exports, anti-spam tooling, accessibility-minded choices, and wide integration coverage are all part of the appeal.

A practical example: if you're building a multi-step intake system for a legal practice or a detailed project brief workflow for a digital agency, WS Form gives you the control to model complicated inputs cleanly.

It also tends to suit teams that dislike buying many separate add-ons for obvious needs. The more you care about granularity, the more attractive WS Form becomes.

### Why it's not for everyone

Power comes with a learning curve. Non-technical editors can find it intimidating if they only expected a simple drag-and-drop form builder.

That's the recurring pattern in this market. The best contact form for wordpress isn't automatically the product with the most settings. It's the one whose complexity matches the job. For some builds, WS Form is exactly right. For many small sites, it's excessive.

## 10. HubSpot WordPress Plugin

![HubSpot WordPress Plugin (Forms + CRM)](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/screenshots/7523e1c1-cb14-447c-abbd-561f2103b6c9/best-contact-form-for-wordpress-hubspot-plugin.jpg)

A familiar scenario: the contact form works, notifications arrive, and then lead handling falls apart. One inquiry sits in an inbox. Another gets copied into a spreadsheet. A third never reaches sales. HubSpot earns its place on this list because it closes that gap inside one system.

The core value is not the form builder itself. It is the direct handoff from form submission into CRM records, contact timelines, email follow-up, and basic automation. For teams already running sales or marketing inside HubSpot, that saves setup time and cuts down on the fragile plugin-to-plugin chains that often break later.

### Best for teams that care about follow-up discipline

HubSpot fits companies where the website is part of a broader lead process, not just a place to collect messages. A B2B team running demo requests, gated content, newsletter signups, and chat can keep those interactions tied to the same contact history from the start.

That matters in practice. Sales can see what the person downloaded. Marketing can segment by form activity. Operations can stop asking which plugin owns the data.

This is also one of the easier choices on the list if your business already pays for HubSpot. In that case, adding another WordPress form plugin often creates duplicate form logic, duplicate contact storage, and extra sync work for no clear benefit.

### The trade-off is commitment to the HubSpot stack

HubSpot makes less sense if you just need a fast contact form on a small brochure site. The plugin is attached to a much bigger platform decision, and that has cost implications. It also changes where submission data lives, who can access it, and how your team handles exports or compliance reviews.

I usually frame it this way for clients. If the form is the front door to a sales process, HubSpot can be a strong fit. If the form is only there to send a few emails each week, it is often more system than the site needs.

Teams that want lighter infrastructure, or that prefer a service-based backend instead of a full CRM, should also compare alternatives outside the usual plugin model. For example, these [form backend integration options for connecting submissions to other tools](https://www.staticforms.dev/docs/integrations) show a very different approach from the all-in-one CRM route.

## Top 10 WordPress Contact Forms: Feature Comparison

| Product | Core features | UX & reliability | Value proposition & pricing | Best for / Target | Unique selling point |
|---|---:|---|---|---|---|
| **Static Forms** | Serverless form backend; instant email/CSV; webhooks and file uploads (4.5MB per submission) from Starter; GDPR controls; AI auto-reply (Starter and up) | Setup in under 1 min; privacy-first | Free-forever; Starter from $6/month ($4/month billed annually); Pro from $9/month; scalable | Frontend devs, static sites, agencies, no-code creators | Plug-and-play serverless forms + AI auto-replies and strong spam protection |
| WPForms | Drag-and-drop builder; 2,100+ templates; payments & page-builder support | Beginner-friendly; fast setup; strong docs/support | Tiered paid plans; promotional first-year pricing | Small businesses, freelancers, agencies needing commerce | Large template library and easy marketing integrations |
| Gravity Forms | WordPress-native framework; conditional logic; many add-ons | Developer-focused; mature and reliable | Paid licenses (tiered); add-ons for Pro/Elite | Agencies and complex WordPress sites | Deep add-on ecosystem for complex workflows |
| Ninja Forms | Drag-and-drop; free core with modular add-ons; CRM integrations | Friendly UI; flexible extensibility | Free core; pay-per-add-on or bundles | Teams wanting a la carte features or bundles | Start free then add only needed features |
| Formidable Forms | Advanced data collection; Views for front-end display; calculators | App-like builder; steeper learning curve | Paid tiers for Business/Elite features | Agencies building data-driven apps, directories | Views feature for front-end data apps (tables, calendars) |
| Fluent Forms | Performance-minded builder; multi-step, integrations, AI tools | Lightweight; good performance; modern UI | Competitive pricing; many features included | Agencies needing speed and styling controls | High feature-per-dollar with strong native integrations |
| Forminator (WPMU DEV) | Forms, quizzes, polls; conditional logic; payments in Pro | Generous free tier; backed by WPMU DEV support | Free core; Pro via WPMU DEV membership | Teams that use WPMU DEV ecosystem | Combined forms + quizzes + WPMU DEV tools and support |
| HappyForms | Live Customizer builder; conditional logic; payments | Minimal setup; real-time preview; low overhead | Free core; paid upgrades | Non-technical users wanting simplicity | Built into WP Customizer for immediate live edits |
| WS Form | Advanced field controls; accessibility focus; many add-ons | Performance-oriented; steep learning curve | Pro recommended for add-ons; paid tiers | Agencies and developers needing power & speed | Accessibility and deep form control for complex sites |
| HubSpot WordPress Plugin | Drag-and-drop forms + CRM sync; email & chat; analytics | Integrated CRM experience; easy contact syncing | Free plugin; advanced HubSpot features require paid tiers | Teams needing CRM-linked forms and marketing tools | Native HubSpot CRM integration for submissions |

## Making Your Final Choice on a WordPress Form

Choosing the best contact form for wordpress isn't really about finding the most popular plugin. It's about choosing the right operating model for your site. That's why so many disappointing form setups happen on otherwise well-built websites. The team buys for features, not for fit.

For most small businesses, WPForms is still the easiest safe recommendation. It's approachable, flexible enough for common business needs, and widely trusted. If the site owner wants a builder that non-technical staff can use without much training, it's hard to argue against it. The trade-off is that advanced features can push you up the pricing ladder, and you still need to manage the usual plugin maintenance, spam control, and email reliability concerns.

For agencies and developers, Gravity Forms, Formidable Forms, and WS Form make more sense when forms are tied to actual business processes. If submissions trigger workflows, create front-end records, power calculators, or connect to outside systems, these tools justify their complexity. They aren't the fastest path to "just add a contact page," but they're often the right long-term choice for structured data collection.

Ninja Forms and Forminator sit in the middle. Both can work well when budget matters and the team wants room to grow. Ninja Forms is especially appealing if you like modular buying. Forminator is attractive when quizzes, polls, and more interactive lead capture are part of the plan. Fluent Forms also earns its place in that practical middle tier, especially for agencies that want a broad feature set with a more modern feel.

HappyForms is the reminder that simpler can be better. Plenty of websites do not need a form automation platform. They need a contact form that looks decent, handles inquiries, and doesn't turn routine edits into a mini training session.

Then there's the option most plugin roundups barely address: skipping the traditional plugin model entirely. Static Forms is the strongest choice here when you want a clean front end, external processing, webhook-friendly workflows (webhooks start on the Starter plan), and a more privacy-conscious setup without making WordPress responsible for everything. On modern builds, especially lightweight or custom-styled sites, that approach often ages better than piling one more large plugin into the stack.

A practical way to decide is to ask four questions:

- **Who will manage the forms later:** A developer, a marketer, or a client who barely logs into WordPress.
- **What happens after submission:** An email notification, a CRM entry, a sales workflow, or a compliance-sensitive process.
- **How much form logic is real:** One contact form, or a workflow with routing, uploads, conditional paths, and data reuse.
- **How much complexity can the site afford:** In admin overhead, performance impact, and future maintenance.

By answering those, the right tool usually becomes obvious. The best contact form for wordpress is the one that captures leads reliably, fits the way your team works, and doesn't create more operational drag than the form is worth.

---

If you want a simpler way to handle WordPress forms without relying on a heavy builder, [Static Forms](https://www.staticforms.dev) is worth trying. It lets you connect a custom or standard HTML form to a hosted backend, add spam protection, send branded confirmations, use webhooks (Starter plan and up), export submissions, and keep the front end under your control. For agencies, developers, and teams building lightweight WordPress sites, it's a practical alternative to the usual plugin-first approach.

---

## Mastering File Upload HTML: A 2026 Guide

Source: https://www.staticforms.dev/blog/file-upload-html  
Date: 2026-05-04T07:09:33.342Z  
Author: Static Forms Team

A request like “can we just add a file upload field?” usually lands late in a project, right when someone needs resumes, screenshots, invoices, or signed PDFs flowing through a form by the end of the day.

The frontend part looks tiny. One `<input>` tag and you’re done. In practice, **file upload html** only feels simple until the first broken submission, oversized file, fake MIME type, inaccessible custom button, or missing backend endpoint shows up. Then you realize the upload flow is really four jobs at once: browser UI, client-side validation, server-side safety, and delivery to something that can store or process the file.

That’s why the best implementations stay boring at the core and only add polish where it helps. Start with standards-compliant HTML. Add JavaScript for preview and validation. Keep security checks on the server where they belong. Make the UI accessible before you make it flashy.

## Your Complete Guide to HTML File Uploads

The modern file upload flow exists because two browser capabilities finally matured together. The `<input type="file">` control itself is old: it was first proposed in [RFC 1867](https://datatracker.ietf.org/doc/html/rfc1867) in 1995. What changed is the File API, which gives JavaScript access to the selected files for previews and validation. That combination made it possible to check files before submission and validate them in the browser, as documented in [MDN’s file input reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file).

That shift changed how good forms are built. A basic upload can still work with plain HTML, but a production-ready one usually needs more:

- **Solid form markup** that sends binary data correctly
- **JavaScript enhancements** for previews, size checks, and friendlier feedback
- **Server-side validation** because client-side checks can be bypassed
- **Accessible controls** so keyboard and screen reader users can complete the task
- **A backend target** that can accept `multipart/form-data`

The pattern matters more than the framework. Whether you’re wiring up a static marketing site, a React app, or a Webflow form, the same fundamentals apply. For more examples after this guide, see the [HTML file input guide](/blog/html-file-input) for the `accept`, `multiple` and `capture` attributes, and the [Next.js document upload tutorial](/blog/nextjs-contact-form-document-upload) for a framework version.

> A file upload field is never just a field. It’s a contract between the browser, your validation logic, and the system receiving the file.

The rest of the work is sequencing. Build the simplest version first. Then improve the user experience. Then lock it down.

## Building the Basic File Upload Form

A file upload starts with three essential elements on the form: **`method="post"`**, **`enctype="multipart/form-data"`**, and **`<input type="file">`**.

![A hand-drawn illustration depicting an HTML input tag with type file and name profilePic attributes.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/637a0c2a-ae8a-49bf-85e3-8b5a866dd920/file-upload-html-input-code.jpg)

Here’s the smallest version that works:

```html
<form
  action="/upload"
  method="post"
  enctype="multipart/form-data"
>
  <label for="resume">Upload your resume</label>
  <input
    id="resume"
    name="resume"
    type="file"
    accept=".pdf,.doc,.docx"
  />

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

`multipart/form-data` is the encoding that lets files travel in an HTTP request body. RFC 1867 introduced it, and [RFC 7578](https://datatracker.ietf.org/doc/html/rfc7578) is the current specification. If you forget `enctype="multipart/form-data"`, the browser falls back to `application/x-www-form-urlencoded` and sends only the file name, not the file. That’s the most common reason uploads fail.

### The attributes that matter

Each attribute solves a different problem:

| Attribute | What it does | Why you need it |
|---|---|---|
| `method="post"` | Sends data in the request body | File data doesn’t belong in a URL |
| `enctype="multipart/form-data"` | Encodes file content correctly | Required for binary uploads |
| `type="file"` | Opens the file picker | Gives the browser permission to select local files |
| `name="resume"` | Names the submitted field | Your backend uses this key |
| `accept=".pdf,.doc,.docx"` | Filters visible file types in the picker | Helps users choose the right file |

> **Why it matters:** `accept` improves guidance, but it’s only a browser hint. It doesn't replace server-side validation.

If you need multiple uploads, add the `multiple` attribute:

```html
<form
  action="/upload-gallery"
  method="post"
  enctype="multipart/form-data"
>
  <label for="photos">Upload project photos</label>
  <input
    id="photos"
    name="photos"
    type="file"
    accept="image/png,image/jpeg"
    multiple
  />

  <button type="submit">Upload photos</button>
</form>
```

### A better default markup pattern

This is the version I recommend as your baseline:

```html
<form
  action="/upload"
  method="post"
  enctype="multipart/form-data"
>
  <div>
    <label for="portfolioFile">Portfolio file</label>
    <p id="portfolioHelp">
      Accepted formats: PDF, DOCX. One file only.
    </p>
    <input
      id="portfolioFile"
      name="portfolioFile"
      type="file"
      accept=".pdf,.docx"
      aria-describedby="portfolioHelp"
      required
    />
  </div>

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

This gives you four things immediately:

- **A visible label** users can click
- **Help text** that explains the expected format
- **A named field** your backend can read
- **Correct form encoding** for actual file transfer

If you need a working reference for plain HTML form wiring, the [Static Forms HTML docs](https://www.staticforms.dev/docs/html) show the same pattern in a lightweight setup.

## Creating Interactive Uploads with JavaScript

Plain HTML is enough to submit a file. It’s not enough to make the interaction feel good.

Users expect to see what they picked, know whether it’s too large, and get feedback before waiting for a failed submission. That’s where the File API helps. Browser-side access to selected files is what turned file upload html from a blunt form control into something you can shape into a decent experience.

![A diagram comparing a basic HTML file input with an enhanced JavaScript drag and drop interface.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/39b3dc43-1989-4e1d-8f09-ce6f854836cf/file-upload-html-drag-drop.jpg)

### Start with file selection feedback

This pattern keeps the native input, then adds a simple status area.

```html
<form id="uploadForm" method="post" enctype="multipart/form-data">
  <label for="avatar">Choose an avatar</label>
  <input
    id="avatar"
    name="avatar"
    type="file"
    accept="image/png,image/jpeg"
  />

  <p id="fileStatus">No file selected.</p>
  <img id="preview" alt="Selected image preview" hidden width="160" />

  <button type="submit">Upload</button>
</form>
```

```html
<script>
  const input = document.getElementById('avatar');
  const fileStatus = document.getElementById('fileStatus');
  const preview = document.getElementById('preview');

  input.addEventListener('change', () => {
    const file = input.files[0];

    if (!file) {
      fileStatus.textContent = 'No file selected.';
      preview.hidden = true;
      preview.removeAttribute('src');
      return;
    }

    fileStatus.textContent = `${file.name} selected`;

    if (file.type === 'image/png' || file.type === 'image/jpeg') {
      const reader = new FileReader();

      reader.onload = (event) => {
        preview.src = event.target.result;
        preview.hidden = false;
      };

      reader.readAsDataURL(file);
    } else {
      preview.hidden = true;
      preview.removeAttribute('src');
    }
  });
</script>
```

That alone is a big usability improvement. People can confirm the selected file before sending it.

### Add client-side size validation

For production forms, reject obvious bad input before it hits the network. [Transloadit’s guide to file uploads](https://transloadit.com/devtips/mastering-file-uploads-comprehensive-guide-for-developers/) recommends validating file size on the client before transmission. A common example is checking that a file stays under **5MB, or 5,242,880 bytes**. If the form posts to Static Forms (uploads need the Starter plan or above), use **4MB (4,194,304 bytes)** instead: the whole submission, every file plus the other fields, has to stay under 4.5MB (more in the Static Forms section below).

```html
<script>
  const maxSize = 4 * 1024 * 1024; // 4MB: Static Forms caps the whole submission at 4.5MB

  input.addEventListener('change', () => {
    const file = input.files[0];

    if (!file) return;

    if (file.size > maxSize) {
      fileStatus.textContent = 'File is too large. Maximum size is 4MB.';
      input.value = '';
      preview.hidden = true;
      preview.removeAttribute('src');
      return;
    }

    fileStatus.textContent = `${file.name} selected`;
  });
</script>
```

> **Practical rule:** client-side validation improves speed and user experience. It does not make the upload secure.

### Validate type and show clear errors

You can combine size and type checks in one place:

```html
<script>
  const allowedTypes = ['image/png', 'image/jpeg'];

  input.addEventListener('change', () => {
    const file = input.files[0];

    if (!file) {
      fileStatus.textContent = 'No file selected.';
      return;
    }

    if (!allowedTypes.includes(file.type)) {
      fileStatus.textContent = 'Please choose a PNG or JPEG image.';
      input.value = '';
      preview.hidden = true;
      preview.removeAttribute('src');
      return;
    }

    if (file.size > maxSize) {
      fileStatus.textContent = 'File is too large. Maximum size is 4MB.';
      input.value = '';
      preview.hidden = true;
      preview.removeAttribute('src');
      return;
    }

    fileStatus.textContent = `Ready to upload: ${file.name}`;
  });
</script>
```

Three UX details matter here:

- **Reset the input** after invalid selection so users can re-pick the same file.
- **Write specific error text** instead of a generic “invalid file.”
- **Keep the native input in the DOM** even if you style a custom button around it.

### A simple custom button pattern

Native file inputs are awkward to style. The safest workaround is to visually hide the input and trigger it with a button or label.

```html
<label for="attachment" class="upload-button">Choose file</label>
<input
  id="attachment"
  name="attachment"
  type="file"
  accept=".pdf,.docx"
  hidden
/>
<p id="attachmentName">No file selected.</p>

<script>
  const attachment = document.getElementById('attachment');
  const attachmentName = document.getElementById('attachmentName');

  attachment.addEventListener('change', () => {
    const file = attachment.files[0];
    attachmentName.textContent = file ? file.name : 'No file selected.';
  });
</script>
```

This gives you styling freedom without replacing the browser’s actual file picker logic.

## Securing and Future-Proofing Your Upload Form

The fastest way to turn a harmless form into a security problem is to trust the uploaded file because the browser UI looked restrictive.

That mistake shows up everywhere. Developers add `accept=".jpg,.png"` and assume they’ve blocked dangerous uploads. They haven’t. The browser can help steer the user, but the server still has to inspect what arrives, reject what doesn’t belong, and store files safely.

![An infographic detailing essential best practices for securing file upload forms and explaining potential security risks.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/4746aed2-020f-4ec6-86ed-aba1c2c05f29/file-upload-html-security-infographic.jpg)

### What the server must do

[OWASP’s File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) is blunt about this: unvalidated uploads remain a common path to web exploits, and OWASP recommends **server-side sanitization** plus storing uploads **outside the webroot** because MIME spoofing is easy on weak systems.

That leads to a short list of essential requirements:

- **Check the file on the server** against an allowlist of expected types
- **Rename files** using application-generated identifiers instead of trusting user filenames
- **Enforce size limits** at the server or middleware layer
- **Store files outside public directories** unless you intentionally serve them
- **Reject executable or unexpected formats** even if the extension looks harmless

> If your backend accepts user filenames directly, you’re giving strangers input over your storage layer. Rename every uploaded file.

A practical server policy might look like this:

| Concern | Bad approach | Better approach |
|---|---|---|
| File type | Trust `Content-Type` header | Inspect and validate server-side |
| Filename | Save original filename directly | Generate your own filename |
| Storage | Save in a public uploads folder by default | Store outside webroot |
| Size | Limit only in frontend JavaScript | Enforce hard limits server-side too |

If your team needs a broader security review beyond uploads, this overview of [affordable OWASP Top 10 pentesting](https://www.affordablepentesting.com/post/what-is-owasp-top-10) is a useful way to frame where upload flaws fit inside the wider application risk picture.

### Accessibility is part of production quality

Security gets most of the attention. Accessibility gets skipped because the default input technically works. That’s not enough when you replace the native control with a styled button, drop zone, or custom status UI.

The simple fix is usually the right one:

```html
<label for="contractFile">Upload signed contract</label>
<p id="contractHelp">
  Select a PDF file. You can also use the button with your keyboard.
</p>
<input
  id="contractFile"
  name="contractFile"
  type="file"
  accept=".pdf"
  aria-describedby="contractHelp"
/>
```

When you build custom wrappers, keep them keyboard-focusable and make sure instructions are visible, not hidden inside placeholder text or tooltip-only UI.

### What doesn’t hold up over time

These shortcuts create fragile upload flows:

- **Client-only validation**
  Useful for feedback, useless as a trust boundary.

- **Extension-only checks**
  A filename can say one thing while the file content says another.

- **Public storage by default**
  Fine for intentional media libraries. Risky for arbitrary user uploads.

- **JavaScript-only custom controls with weak focus states**
  They often look better in screenshots than they work in actual forms.

A professional upload form protects the server, helps the user recover from mistakes, and still works without fancy UI.

## Making Your File Upload Form Work with Static Forms

Frontend developers usually get stuck at the same point. The HTML is fine, the JavaScript preview works, and then someone asks the obvious question: where does the file go?

If you’re building a static site or you don’t want to maintain your own upload endpoint, you need a backend service that accepts `multipart/form-data`, stores the file, and gives you a reliable submission workflow. The mechanics stay the same. The destination changes.

![A diagram illustrating the flow from a static HTML upload form through a service to cloud storage.](https://cdnimg.co/ddd8d9fb-9b81-4eed-89ed-45a76c40be86/ba809f26-6656-4bca-be92-f5b701f66ec4/file-upload-html-data-flow.jpg)

### A working form pattern

At the form level, the setup is familiar:

```html
<form
  action="https://api.staticforms.dev/submit"
  method="post"
  enctype="multipart/form-data"
>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />

  <label for="document">Upload your document</label>
  <p id="documentHelp">Accepted file: PDF, up to 4MB.</p>

  <input
    id="document"
    name="document"
    type="file"
    accept=".pdf"
    aria-describedby="documentHelp"
    required
  />

  <input type="text" name="name" placeholder="Your name" required />
  <input type="email" name="email" placeholder="Your email" required />

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

The important part isn’t the visual markup. It’s that the form is still using **`method="post"`** and **`enctype="multipart/form-data"`**, and the receiving endpoint is built to process file submissions.

What Static Forms does with the file:

- **Plans:** file uploads work from the Starter plan up. On the Free plan, a submission that includes a file is rejected.
- **Size:** the whole submission, meaning every file plus the other fields, has to stay under 4.5MB. Anything larger is refused with an HTTP 413 error before Static Forms processes it. The `multiple` attribute works, but the files share that limit, so two 3MB files are too much.
- **Delivery:** files are attached to the notification email. When the form stores submissions, they are also kept in private storage that you can download from your Inbox (1 GB on Starter, 5 GB on Pro, 10 GB on Agency).
- **File types:** the server doesn't filter by type, so `accept` and your client-side checks are what steer people to the right format.

The [file uploads docs](/docs/forms/file-uploads) cover the AJAX version with `FormData`.

### Good patterns for static sites

When the backend is handled by a form service, the frontend job becomes simpler:

1. **Keep the native input**
   It’s the most reliable source of file selection behavior.

2. **Apply client-side validation before submit**
   Check file size and accepted types so users get instant feedback.

3. **Send one clean multipart request**
   Don’t overcomplicate the browser side if the endpoint already accepts standard form submissions.

4. **Use webhooks only when you need downstream automation**
   For example, forwarding metadata into a CRM or triggering storage workflows.

Here’s a lightweight validation layer:

```html
<script>
  const form = document.querySelector('form');
  const fileInput = document.getElementById('document');
  // The whole request must stay under 4.5MB; 4MB leaves room for the other fields.
  const maxTotalBytes = 4 * 1024 * 1024;
  const allowed = ['application/pdf'];

  form.addEventListener('submit', (event) => {
    const files = Array.from(fileInput.files);

    if (files.length === 0) return;

    if (files.some((file) => !allowed.includes(file.type))) {
      event.preventDefault();
      alert('Please upload PDF files only.');
      return;
    }

    const totalBytes = files.reduce((sum, file) => sum + file.size, 0);
    if (totalBytes > maxTotalBytes) {
      event.preventDefault();
      alert('Your files add up to more than 4MB. Please send smaller files.');
    }
  });
</script>
```

> Keep the browser-side rules aligned with the backend’s actual limits. Mismatched validation is one of the easiest ways to confuse users.

### Don’t lose accessibility when you integrate

The integration step is where teams often swap in a custom drop zone and accidentally make the form worse. That’s avoidable. Pairing a standard file input with a visible label and `aria-describedby` improves usability for assistive technology users, and custom drop zones should preserve focus management and keyboard access (see the [Filestack accessibility writeup](https://blog.filestack.com/html-file-upload-accessibility/) for examples).

That’s a strong argument for staying close to native HTML unless a custom interaction solves a real problem. The same applies to the rest of the form: these [form UX best practices](/blog/form-ux-best-practices) cover labels, error messages and mobile layout.

A practical deployment checklist looks like this:

- **Label every file input** with visible text
- **Attach help text** for allowed formats and limits
- **Match frontend checks to backend rules**
- **Test with keyboard only**
- **Submit a real file before launch**
- **Verify where the uploaded file appears after submission**

For static sites, that’s often enough. You get a normal form workflow without standing up your own upload API.

## File Upload Examples for Your Stack

The browser rules stay consistent, but each framework wraps the file input a little differently. The easiest way to avoid trouble is to keep the same mental model everywhere: hold a reference to the selected file, validate it, then submit it with `FormData`.

### React example

This version keeps the selected file in component state and posts it with `fetch`.

```jsx
import { useState } from 'react';

export default function ResumeUploadForm() {
  const [file, setFile] = useState(null);
  const [message, setMessage] = useState('No file selected.');

  function handleFileChange(event) {
    const selected = event.target.files[0];

    if (!selected) {
      setFile(null);
      setMessage('No file selected.');
      return;
    }

    if (selected.type !== 'application/pdf') {
      setFile(null);
      setMessage('Please choose a PDF file.');
      event.target.value = '';
      return;
    }

    setFile(selected);
    setMessage(`Ready to upload: ${selected.name}`);
  }

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

    if (!file) {
      setMessage('Choose a file before submitting.');
      return;
    }

    const formData = new FormData();
    formData.append('resume', file);

    await fetch('/upload', {
      method: 'POST',
      body: formData,
    });

    setMessage('Upload submitted.');
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="resume">Upload resume</label>
      <input
        id="resume"
        name="resume"
        type="file"
        accept=".pdf"
        onChange={handleFileChange}
      />
      <p>{message}</p>
      <button type="submit">Submit</button>
    </form>
  );
}
```

### Vue example

Vue works well when you keep the file object in reactive state and let the template reflect the current status.

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

const file = ref(null);
const message = ref('No file selected.');

function onFileChange(event) {
  const selected = event.target.files[0];

  if (!selected) {
    file.value = null;
    message.value = 'No file selected.';
    return;
  }

  if (!['image/png', 'image/jpeg'].includes(selected.type)) {
    file.value = null;
    message.value = 'Please upload a PNG or JPEG image.';
    event.target.value = '';
    return;
  }

  file.value = selected;
  message.value = `Selected: ${selected.name}`;
}

async function submitForm() {
  if (!file.value) {
    message.value = 'Pick a file first.';
    return;
  }

  const formData = new FormData();
  formData.append('image', file.value);

  await fetch('/upload', {
    method: 'POST',
    body: formData,
  });

  message.value = 'Upload submitted.';
}
</script>

<template>
  <form @submit.prevent="submitForm">
    <label for="image">Upload image</label>
    <input
      id="image"
      type="file"
      accept="image/png,image/jpeg"
      @change="onFileChange"
    />
    <p>{{ message }}</p>
    <button type="submit">Upload</button>
  </form>
</template>
```

### Webflow and WordPress pattern

In no-code and low-code tools, the usual issue isn’t JavaScript. It’s missing form attributes.

Check these first:

- **Form method**
  Set it to `post`.

- **Encoding**
  Add `multipart/form-data`.

- **Field name**
  Make sure the file input has a real `name` attribute.

- **Endpoint**
  Confirm the form action points to the service receiving the upload.

For a complete React walkthrough, the [Next.js document upload tutorial](/blog/nextjs-contact-form-document-upload) builds the same pattern step by step. If you're on WordPress, [free WordPress file upload forms](/blog/file-upload-form-wordpress-free) compares plugins and the form-backend route.

A good file upload experience isn’t about clever UI. It’s the result of a native input, focused JavaScript, strict backend validation, and a receiving endpoint that behaves predictably.

---

If you want a backend that handles file uploads for static sites without building your own server, [Static Forms](https://www.staticforms.dev) is a straightforward option. You point your form `action` to its endpoint, keep your standard HTML and `multipart/form-data` setup, and get file handling (from the Starter plan), spam protection, webhooks, and GDPR-friendly controls without changing how your frontend form works.

---

## How to Send Form Submissions to Slack in Under 2 Minutes

Source: https://www.staticforms.dev/blog/how-to-send-form-submissions-to-slack  
Date: 2026-05-02  
Author: Static Forms Team

Email inboxes are where leads go to die. By the time you scroll past three newsletters and a calendar invite, that "interested customer" has moved on to the next tab. If your team already lives in Slack, your form submissions should too.

This tutorial walks you through connecting any HTML form on your website to a Slack channel using Static Forms. The result: every time a visitor hits **Submit**, a clean, structured message lands in the channel of your choice — within seconds. No Zapier subscription, no custom Slack app, no incoming webhook URLs to manage. We'll cover the connection flow, build a working HTML form, verify end-to-end delivery, and troubleshoot the issues that typically trip people up.

## What You'll Learn

- How to connect a Slack workspace to your Static Forms account
- What happens behind the scenes when you authorize
- How to build a working HTML form that sends to Slack
- How to verify the connection with a test submission
- How to route different forms to different Slack channels
- Common use cases for teams using Slack
- How to troubleshoot common delivery issues

## Prerequisites

Before you begin, make sure you have:

1. A **Static Forms account** with at least one verified account. [Sign up here](https://www.staticforms.dev) if you don't have one.
2. A **paid plan** — Slack is available from the Starter plan ($6/month, or $4/month billed annually). [View pricing](https://www.staticforms.dev/pricing) to upgrade if needed.
3. **Admin or owner access** to a Slack workspace — or permission from your workspace admin to install apps.
4. A **website or local HTML file** where you can add a form.

Got all four? Let's wire it up.

## Step 1: Open the Integrations Page

Log into your [Static Forms dashboard](https://www.staticforms.dev/app/forms) and click **Settings** in the top navigation. From the account list, choose the account you want Slack notifications for, then click the **Integrations** tab.

You'll see a list of available integrations including **Webhooks**, **Google Sheets**, and **Slack**. Click the Slack card to expand it.

## Step 2: Connect to Slack

Click the **Connect to Slack** button. You'll be redirected to Slack's standard OAuth consent screen, where you'll:

1. **Pick a workspace** from the dropdown in the top-right corner.
2. **Choose a channel** that should receive the notifications (for example, `#leads`, `#contact-form`, or `#support`).
3. **Click Allow** to authorize the connection.

Slack redirects you back to the integrations page with a success confirmation. The card now shows your connected workspace and channel name.

> **Note**: Static Forms only requests the minimum scope needed to post messages to the channel you select. We never request access to read messages, list members, or post to other channels.

### What Happens Behind the Scenes

When you authorize, Static Forms:

1. Receives a **webhook URL** from Slack tied to your selected workspace and channel
2. Stores the webhook URL **encrypted** in our database — it's never exposed in the dashboard
3. Enables notifications immediately — the very next form submission triggers a Slack message

You don't need to create a Slack app, manage OAuth tokens, or configure any incoming webhook manually. The entire flow is handled by our pre-built integration.

## Step 3: Send a Test Notification

Before wiring up a real form, click the **Send test message** button on the Slack integration card. Switch over to Slack — within a couple of seconds, a test notification appears in the channel you selected.

If the test message arrives, your connection is healthy. If it doesn't, jump to the [Troubleshooting](#troubleshooting) section.

## Step 4: Grab Your API Key

You need your account's `apiKey` to point a form at it. Still in the **Settings** area, click the **Account** tab. Copy the `apiKey` value — it's a long string that looks like `sf_live_...`.

> Treat your `apiKey` like a password. Don't commit it to a public repo.

## Step 5: Build the HTML Form

Drop this HTML anywhere on your website. Replace `YOUR_API_KEY` with the key you copied in Step 4 and update the redirect URL to your own thank-you page.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>Contact Us</title>
</head>
<body>
  <form action="https://api.staticforms.dev/submit" method="POST">
    <!-- Static Forms config -->
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
    <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you" />

    <!-- Your fields -->
    <label for="name">Name</label>
    <input type="text" id="name" name="name" required />

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

    <label for="subject">Subject</label>
    <input type="text" id="subject" name="subject" />

    <label for="message">Message</label>
    <textarea id="message" name="message" rows="5" required></textarea>

    <button type="submit">Send Message</button>
  </form>
</body>
</html>
```

That's the entire form. No JavaScript, no backend, no fetch calls. The browser POSTs the form data straight to `https://api.staticforms.dev/submit`, Static Forms validates it, runs spam checks, and forwards a structured notification to your Slack channel.

## Step 6: Submit and Verify

Open the page in your browser, fill out the form, and click **Send Message**. Within seconds:

1. The browser redirects to your `redirectTo` URL.
2. A notification appears in your Slack channel showing every field you submitted.

Your form is now wired to Slack.

## What the Slack Message Looks Like

Static Forms uses Slack's **Block Kit** format to deliver rich, structured notifications. Each submission shows up as:

**Header** — A bold title identifying the account that received the submission, so you can tell at a glance which form it came from.

**Form fields** — Each field from the submission is displayed in a clean **two-column layout**. Field names appear on the left in bold, values on the right. For example:

> **Name** — Jane Smith
> **Email** — jane@example.com
> **Message** — I'd like to learn more about your enterprise plan.

**Footer** — A subtle line showing the submission timestamp and a link to view the full record in your dashboard.

The result is scannable at a glance — your team can read the whole submission, reply in a thread, and assign follow-up without ever opening another tab.

## Managing the Integration

### Enable / Disable Notifications

Toggle the switch on the Slack integration card to pause or resume notifications. When disabled, form submissions still process normally — email notifications, webhooks, and Google Sheets sync all continue — only the Slack message is skipped.

This is useful during maintenance windows or when a high-volume campaign would flood your channel.

### Disconnect

Click **Disconnect** to remove the Slack connection entirely. The webhook URL is deleted from our system and no further messages are sent. Your Slack channel history is unaffected — all previously posted notifications remain.

### Reconnect to a Different Channel

To change the destination channel, disconnect the current connection and click **Connect to Slack** again. During the OAuth flow, select the new channel.

## Routing Different Forms to Different Channels

Static Forms organizes integrations per **account**. Each account has its own `apiKey` and its own Slack connection. To route forms separately:

1. Create a new account in your dashboard for each form (e.g., "Sales Leads", "Support", "Newsletter").
2. Connect each account to a different Slack channel.
3. Use each account's `apiKey` in the corresponding HTML form.

For example:

- **Marketing landing page form** → `Sales Leads` account → `#sales` channel
- **Help page form** → `Support` account → `#support` channel
- **Footer signup** → `Newsletter` account → `#growth` channel

You can also connect different accounts to entirely different Slack workspaces — useful for agencies managing multiple clients.

## Common Use Cases

### Lead Alerts to #sales

Connect your landing page form to your `#sales` channel. Your sales team sees every lead the moment it arrives. They can discuss the lead in a Slack thread, assign follow-up, and respond faster than any competitor still checking their inbox.

### Support Tickets to #support

Route support form submissions to `#support`. Use Slack threads to triage issues in real time. Pair this with the Google Sheets integration to keep a permanent log of every request while your team handles them in Slack.

### Event RSVPs to #events

Post every RSVP to your `#events` channel so your team can see registrations rolling in live. It's a great morale boost during a launch — and you'll know instantly if signups stall.

### Internal Feedback to #product

Use a feedback form on your internal tools and route submissions to `#product`. Your product team gets unfiltered user feedback without anyone needing to compile a report.

## Pairing Slack with Other Integrations

Slack is great for awareness but not great for archival. For most teams, the winning combo is:

- **Slack** for instant alerts and team discussion
- **Google Sheets** for the permanent record and ad-hoc analysis
- **Email notifications** as a backup channel for individual reviewers

All three can run in parallel on the same account. Submissions are processed once and fanned out to every enabled destination — if Slack is down, the email and sheet still work, and vice versa.

If you haven't set up Sheets yet, see our guide on [How to Automatically Send Form Submissions to Google Sheets](/blog/google-sheets-integration-guide).

## Slack vs. Google Sheets vs. Webhooks

Not sure which integration to use? Here's a quick comparison:

| | Slack (Native) | Google Sheets (Native) | Webhooks |
|---|---|---|---|
| **Best for** | Real-time team alerts | Data logging & analysis | Custom backends |
| **Setup time** | 30 seconds | 30 seconds | 2 minutes |
| **Code required** | None | None | Endpoint needed |
| **Cost** | Free (Starter plan and above) | Free (Pro plan and above) | Free (Starter plan and above) |
| **Output** | Channel message | Spreadsheet row | HTTP POST to your server |
| **Searchable** | Slack search | Sheets filter/sort | Your own system |
| **Team visibility** | Entire channel sees it | Shared spreadsheet | Depends on your setup |

The best approach for most teams is to **use Slack and Google Sheets together** — Slack for instant awareness, Sheets for the permanent record. Both can be enabled on the same account simultaneously.

## Troubleshooting

### The test message didn't arrive

Check that the channel still exists and hasn't been archived. If you connected to a private channel and later removed the Static Forms app from it, the webhook is invalid. Click **Disconnect**, then **Connect to Slack** again to generate a fresh connection.

### The form submits but nothing arrives in Slack

Three things to verify:

1. **Slack toggle is on** — the switch on the integration card must be enabled.
2. **You're using the right `apiKey`** — each account has its own key. Submissions to the wrong account go to the wrong (or no) Slack channel.
3. **Static Forms isn't classifying the submission as spam** — check your dashboard's **Submissions** view. Spam-flagged submissions are stored but not forwarded to integrations.

### "Delivery failed" appears on the integration card

The webhook is no longer valid. Most common causes:

- The Static Forms app was removed from your Slack workspace
- The destination channel was deleted or archived
- Workspace admin changed app permissions

Fix: **Disconnect**, then **Connect to Slack** again. The reconnect generates a brand-new webhook URL.

### Some fields are missing from the Slack message

Static Forms includes every field present in the submission. If a field is missing, double-check that your HTML `<input>` has a `name` attribute (not just an `id`) — only fields with `name` are sent.

### My form has 30+ fields and the message is truncated

Slack caps message block size. For very large submissions, the Slack notification may be truncated. The full submission is always available in your Static Forms dashboard and via email — Slack is built for a quick heads-up, not full archival.

### Rate limits

Slack enforces rate limits on incoming webhooks (approximately one message per second per channel). Under normal usage this is never an issue. If you're receiving hundreds of submissions per minute during a viral campaign, some notifications may be delayed or dropped. Consider disabling Slack temporarily during extreme volume and relying on Google Sheets or email for the full record.

Errors never block form submission delivery — email notifications, webhooks, and Google Sheets sync continue working normally even if the Slack notification fails.

## Complete Working Example

Here's a production-ready contact form with basic styling and a honeypot field for extra spam protection:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>Contact Us</title>
  <style>
    body { font-family: system-ui, sans-serif; max-width: 480px; margin: 4rem auto; padding: 0 1rem; }
    label { display: block; margin-top: 1rem; font-weight: 600; }
    input, textarea { width: 100%; padding: 0.5rem; border: 1px solid #ccc; border-radius: 4px; }
    button { margin-top: 1.5rem; padding: 0.75rem 1.5rem; background: #0070f3; color: #fff; border: 0; border-radius: 4px; cursor: pointer; }
    .honeypot { position: absolute; left: -5000px; }
  </style>
</head>
<body>
  <h1>Contact Us</h1>
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
    <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you" />

    <!-- Honeypot: bots fill this in, humans never see it -->
    <div class="honeypot" aria-hidden="true">
      <label for="company">Company</label>
      <input type="text" id="company" name="honeypot" tabindex="-1" autocomplete="off" />
    </div>

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

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

    <label for="message">Message</label>
    <textarea id="message" name="message" rows="5" required></textarea>

    <button type="submit">Send Message</button>
  </form>
</body>
</html>
```

Drop this into any static site — Next.js, Gatsby, Hugo, plain HTML, GitHub Pages — and you're done. Submissions land in Slack instantly.

## You're Done!

You now have a fully working pipeline from your website to your Slack channel. To recap:

- Connected Slack to your Static Forms account via native OAuth
- Built a working HTML form pointing at the Static Forms API
- Verified end-to-end delivery with a test submission
- Set up routing for multiple forms to different channels
- Layered in extra spam protection with a honeypot field

If you want to take it further:

- Add [Altcha CAPTCHA](/blog/implementing-altcha-captcha-html-website) for privacy-first spam protection
- Mirror submissions to [Google Sheets](/blog/google-sheets-integration-guide) for long-term storage

Have feedback or want a feature added? [Get in touch](https://www.staticforms.dev/contact) — we read every message.

---

*Slack integration is available from the Starter plan ($6/month, or $4/month billed annually). [View pricing](https://www.staticforms.dev/pricing) to learn more about Static Forms plans.*

---

## How to Send Form Submissions to Google Sheets

Source: https://www.staticforms.dev/blog/google-sheets-integration-guide  
Date: 2026-04-21  
Author: Static Forms Team

Spreadsheets are the original data tool. Whether you're tracking leads, collecting RSVPs, or logging support requests, having every form submission land in a Google Sheet gives you instant access to filter, sort, chart, and share the data with your team — all without writing a line of code.

Today we're launching a **native Google Sheets integration** for Static Forms, available on the Pro and Agency plans. Connect your Google account with one click, and every submission is appended as a new row in a dedicated spreadsheet. No Zapier. No Make. No Google Apps Script. Just your forms and your sheet.

## What You'll Learn

- How to connect Google Sheets to a form
- How form fields become spreadsheet columns
- How to manage separate spreadsheets for different forms
- Troubleshooting common issues

## Prerequisites

Before you begin, make sure you have:

1. A **Static Forms Pro or Agency** account (Google Sheets integration is Pro and Agency only). [Upgrade here](/pricing) if you're on the Free or Starter plan.
2. A **Google account** (any Gmail or Google Workspace account).
3. At least one **form** in your Static Forms dashboard.

Already have all of these? Let's get started.

## Step 1: Open the Form's Delivery Settings

Log into your Static Forms dashboard and open the form you want to connect. Choose **Delivery** in the form's navigation and find the **Google Sheets** card.

## Step 2: Connect Your Google Account

Click **Connect Google account**. Google shows its standard OAuth consent screen and asks you to approve two scopes:

- **`drive.file`** lets Static Forms use only the files you create or open with it. It gives no access to the rest of your Drive.
- **`userinfo.email`** tells Static Forms which Google account you connected, so the card can show it.

After you approve, Google sends you back to the form's Delivery page, which confirms that Google Sheets is connected.

### What Happens Behind the Scenes

When you connect, Static Forms:

1. Creates a new spreadsheet in your Google Drive titled **"Static Forms — (your form's name)"**, or the form's delivery email if the form has no name, with a **Submissions** tab
2. Stores an encrypted refresh token so it can add rows on your behalf
3. Turns the sync on, so the next form submission adds the first row

You don't need to create the spreadsheet yourself, share it with a service account, or configure anything in the Google Cloud Console.

## Step 3: Check the Connection

Back on the Delivery page, the Google Sheets card shows:

- **Connected as**: the Google email you authorized with
- **Spreadsheet**: an **Open in Sheets** link to the new spreadsheet
- **Tab**: the tab rows go to (**Submissions** by default)
- **Last sync**: when the last row went in

Click **Open in Sheets** to find the empty spreadsheet. The card has no test button; your first real submission (Step 4) writes the header row and the first row.

## Step 4: Submit a Real Form

Now submit the form using its API key (from your website, a `curl` command, or any HTTP client). A new row appears in the spreadsheet.

Here's a simple HTML form you can drop into any page. Replace `YOUR_API_KEY` with the form's API key:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY" />
  <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you" />

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

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

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="4" required></textarea>

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

Submit the form, then check your spreadsheet — you'll see a new row with columns for `submitted_at`, `submission_id`, `name`, `email`, and `message`. Every field in the form becomes a column.

## How Dynamic Columns Work

One of the best things about our integration is that **you never need to configure column mapping**. Here's how it works:

1. **First submission**: Static Forms reads your form data keys (`name`, `email`, `message`, etc.) and writes them as the header row. Two meta-columns are always prepended: `submitted_at` and `submission_id`.

2. **Subsequent submissions**: Each new submission is appended as a row, aligned to the existing header.

3. **New fields appear**: If a later submission includes a field that didn't exist before (say `phone`), Static Forms appends it as a new column at the end of the header row. Earlier rows will have blank cells for that column — just like you'd expect.

This means your spreadsheet schema evolves with your form. Add a field to your HTML form, and the column appears on the next submission. No reconfiguration needed.

## Managing the Integration

### Enable / Disable Sync

Toggle the sync switch on the integration card to pause or resume the form's own rows. Your spreadsheet stays intact. Form rules that send to Google Sheets keep adding rows while the switch is off, until you disconnect.

### Send Rows to Another Tab

By default, rows go to a tab called **Submissions**. A [form rule](/docs/forms/rules) can send matching submissions to another tab of the same spreadsheet. If that tab doesn't exist yet, Static Forms creates it when the next matching submission arrives.

This is useful if you want to organize data by month or campaign:

- `Submissions`: the default
- `April-2026`: for date-based organization
- `Landing-Page-Leads`: for campaign-specific tracking

### Disconnect

Click **Disconnect** to remove the connection and its stored tokens from Static Forms. Your spreadsheet stays in your Google Drive with all existing data. You can reconnect at any time, which creates a new spreadsheet.

Disconnecting doesn't revoke Static Forms' access at Google. To do that, remove Static Forms at [myaccount.google.com/permissions](https://myaccount.google.com/permissions). Revoking removes every permission you gave Static Forms on that Google account: Sign in with Google, and every form connected to Google Sheets with that Google account, not only one. Those forms stop adding rows until they are connected again. You can still sign in with Google afterwards; Google asks for your consent again.

## Per-Form Connections

Each form in Static Forms has its own Google Sheets connection. This means you can:

- Connect different Google accounts to different forms
- Have separate spreadsheets for your contact form and your job application form
- Share one form's spreadsheet with a teammate without giving them your whole dashboard

Open each form's **Delivery** settings to set up its connection.

## Common Use Cases

### Lead Generation

Connect your landing page form to Google Sheets and share the spreadsheet with your sales team. They see leads the moment they come in, with no dashboard login required.

### Event RSVPs

Create a simple RSVP form, connect it to Sheets, and use Google Sheets' built-in `COUNTA()` function to track attendance in real time.

### Support Requests

Log every support request as a row. Use conditional formatting to highlight unresolved tickets, and add a "Status" column manually for your team to update.

### Data Export & Analysis

Unlike email-based form submissions, spreadsheet data is instantly sortable, filterable, and chartable. Use Google Sheets' pivot tables, `QUERY()` function, or connect to Google Data Studio for reporting dashboards.

## Troubleshooting

### "Last error" appears on the integration card

If a submission fails to sync, the error and timestamp are displayed on the card. Common causes:

- **Token expired or revoked**: Someone revoked the Google authorization, for example at [myaccount.google.com/permissions](https://myaccount.google.com/permissions). Click **Disconnect**, then **Connect Google account** again.
- **Spreadsheet deleted**: If you deleted the spreadsheet from Google Drive, disconnect and reconnect to create a new one.

Errors never block form submission delivery — your email notifications and webhooks continue working normally even if the Sheets sync fails.

### I renamed or deleted the tab

You won't see an error for this. On the next submission, Static Forms recreates the tab under its configured name (**Submissions** by default) with a fresh header row. Rows you already have stay in the renamed tab.

### Form submissions arrive but no row appears

1. Check that the integration is **enabled** (the toggle should be on).
2. Check that you're using the right form's API key. Each form has its own connection.
3. Look for a **Last error** on the card. If the authorization was revoked, disconnect and connect again.

### I want to use an existing spreadsheet

The current integration auto-creates a new spreadsheet on connect. If you need to write to an existing sheet, you can use our [Webhook integration](/docs/webhooks) with [Zapier](/docs/integrations/zapier) or [Make](/docs/integrations/make) instead, which offer full control over the destination.

## Google Sheets vs. Webhooks vs. Zapier

Not sure which integration to use? Here's a quick comparison:

| | Google Sheets (Native) | Webhooks | Zapier/Make |
|---|---|---|---|
| **Setup time** | 30 seconds | 2 minutes | 5-10 minutes |
| **Code required** | None | Endpoint needed | None |
| **Cost** | Free (Pro plan) | Free (Starter plan and above) | Zapier/Make subscription |
| **Destination** | Google Sheets only | Any HTTP endpoint | 5,000+ apps |
| **Column mapping** | Automatic | You parse the JSON | Visual mapper |
| **Best for** | Quick spreadsheet logging | Custom backends | Multi-step workflows |

For most users who just want their form data in a spreadsheet, the native integration is the fastest path.

## What's Next

Static Forms also connects natively to Slack, Discord, Telegram, Notion, Airtable and Mailchimp. If there's an integration you'd like to see, [let us know](/contact).

Ready to get started? [Open your forms](/app/forms), pick one, and connect Google Sheets from its **Delivery** settings.

---

*Google Sheets integration is available on the Pro and Agency plans. Plain webhooks are available from the $6/month Starter plan (or $4/month billed annually). [View pricing](/pricing) to learn more about Static Forms plans.*

---

## hCaptcha Best Practices

Source: https://www.staticforms.dev/blog/hcaptcha-best-practices  
Date: 2026-03-13  
Author: Static Forms Team

hCaptcha is a strong fit when you want privacy-friendly spam protection without depending on Google services. This guide focuses on the decisions and operational details that matter most when you use hCaptcha well.

If you're using Static Forms, where hCaptcha is available from the Starter plan up, and want the exact setup steps and code examples, use the [hCaptcha documentation](/docs/forms/security/hcaptcha). That doc covers the provider-specific setup flow, HTML snippet, React example, expected token field, and troubleshooting.

## When hCaptcha is a good fit

hCaptcha usually makes sense when you want:

- A privacy-friendly alternative to reCAPTCHA
- Support for checkbox and invisible modes
- A familiar CAPTCHA flow with flexible rollout options
- A provider that works well for both static HTML forms and frontend frameworks

If your priority is the lowest possible friction, [Cloudflare Turnstile](/docs/forms/security/turnstile) may be a better fit; see [Cloudflare Turnstile best practices](/blog/cloudflare-turnstile-best-practices) for keys, test keys and token timing. If your priority is privacy-first protection without a third-party CAPTCHA provider, consider [ALTCHA](/docs/forms/security/altcha).

## Best practices before you launch

### 1. Keep your keys separated correctly

Your **site key** belongs in your frontend. Your **secret key** belongs in your server-side configuration or form backend settings only.

That means:

- Put the site key in your HTML or frontend app
- Save the secret key only in secure backend settings
- Never expose the secret key in client-side code

## 2. Register every domain you actually use

Add all real environments in hCaptcha before you test:

- Production domain
- Staging domain
- `localhost` if you test locally

Most "invalid" or "domain not registered" errors come from incomplete domain configuration rather than a broken form.

### Use separate keys for production and non-production

Do not treat all environments as one hCaptcha site unless you have a strong reason to do so.

A better setup is:

- One hCaptcha site and key pair for production domains only
- A separate hCaptcha site and key pair for staging, preview, and local development

This makes it easier to rotate keys, isolate testing, and avoid accidental cross-environment configuration mistakes.

### Do not add localhost to your production hCaptcha site

`localhost` is useful for development, but it should live only in your non-production hCaptcha configuration.

Avoid adding `localhost` to the production site registration. Keeping production domains separate reduces confusion and keeps your production configuration tighter.

## 3. Use invisible mode and execute the challenge at submit time

This is the single biggest implementation detail people get wrong, and it causes intermittent "verification failed" errors that are hard to reproduce.

hCaptcha tokens are valid for **only 120 seconds** from when the widget solves them. The default visible-checkbox integration auto-completes as soon as the user clicks. If they then take their time filling the form, attach a large file, or submit over a slow network, the token can expire mid-flight and hCaptcha rejects it as `expired-input-response` or `invalid-or-already-seen-response`.

The fix is to render the widget in **invisible mode** and trigger the challenge from your submit handler:

```tsx
import HCaptcha from '@hcaptcha/react-hcaptcha';

const captchaRef = useRef<HCaptcha>(null);

async function handleSubmit(e) {
  e.preventDefault();
  // Mint the token at submit time so it stays well within the 120s TTL
  const { response: token } = await captchaRef.current!.execute({ async: true });
  // ...append token and POST
}

return (
  <form onSubmit={handleSubmit}>
    {/* ...form fields */}
    <HCaptcha sitekey={SITE_KEY} size="invisible" ref={captchaRef} />
    <button type="submit">Send</button>
  </form>
);
```

With this pattern the token is seconds old by the time your backend verifies it, regardless of how long the upload takes. Most users see no widget at all — the challenge UI only appears when hCaptcha's risk engine actually wants user interaction.

Recommend this as your default integration pattern, **even when forms don't have file uploads** — it eliminates a class of intermittent failures with no real downside. Reserve the visible checkbox variant for high-risk endpoints where you want the friction.

The docs cover the full HTML, React, and Next.js implementations: [View the hCaptcha setup guide](/docs/forms/security/hcaptcha).

## 4. Verify the token field your backend expects

When hCaptcha completes successfully, your form must send the token field your backend expects.

That field name matters. If the widget renders correctly but the token is submitted under the wrong name, verification will fail even though the user completed the challenge.

If you're using Static Forms, the required field name is documented here: [hCaptcha for Static Forms](/docs/forms/security/hcaptcha).

## 5. Treat CAPTCHA as one layer, not the whole spam strategy

hCaptcha works best alongside the rest of your form hardening:

- Keep required fields tight
- Use validation for email and message fields
- Add honeypot protection when appropriate
- Review abuse patterns instead of assuming one provider will stop everything

Start with a layered setup, then tune based on real submissions.

## 6. Test the full submission path, not just widget rendering

It is not enough to see the widget on the page. Before shipping, confirm the full flow:

1. The widget loads on the right domains
2. The user can complete the challenge
3. The token is included in the form submission
4. Your backend accepts the submission successfully

That last step catches most configuration mistakes.

## Common mistakes to avoid

Here are the issues teams hit most often:

- Mixing up the site key and the secret key
- Registering production but forgetting staging or localhost
- Sending the wrong token field name
- Using the visible checkbox and letting the token expire during long sessions or slow uploads (use invisible + execute-on-submit)
- Assuming the frontend widget alone is enough without verifying the end-to-end submission

## Implementation checklist

Use this as a quick handoff list:

- Create or configure your hCaptcha site
- Register your domains
- Save the hCaptcha secret key in your backend or form handler
- Add the widget with your site key
- Confirm the form submits the token field your backend expects
- Run a real test submission in each environment

If you're using Static Forms, go straight to the docs for the exact code and setup walkthrough:

- [hCaptcha with Static Forms](/docs/forms/security/hcaptcha)
- [Spam protection overview](/docs/forms/security)
- The form's Security tab in your [dashboard](/app/forms)

## Choosing between hCaptcha and the other options

Use hCaptcha when you want a familiar CAPTCHA experience and a privacy-friendly alternative to Google. Use Turnstile when reducing visible challenge friction is the top priority. Use ALTCHA when you want a privacy-first approach without relying on a third-party CAPTCHA account.

The provider comparison page is the best starting point if you are still deciding: [Compare spam protection options](/docs/forms/security).

---

## Cloudflare Turnstile Best Practices

Source: https://www.staticforms.dev/blog/cloudflare-turnstile-best-practices  
Date: 2026-03-11  
Author: Static Forms Team

Cloudflare Turnstile is a strong choice when you want low-friction spam protection without traditional CAPTCHA puzzles. This guide focuses on rollout advice, implementation pitfalls, and the details that matter when you use Turnstile well.

If you're using Static Forms, where Turnstile is available from the Starter plan up, and want the exact setup steps and code examples, use the [Cloudflare Turnstile documentation](/docs/forms/security/turnstile). That doc covers the dashboard setup, HTML example, React flow, token field name, and troubleshooting.

## When Turnstile is a good fit

Turnstile is a good choice when you want:

- Minimal user interruption during form submission
- A non-Google CAPTCHA option
- A clean experience for marketing sites and contact forms
- A provider that works well with static HTML and frontend frameworks

If you want checkbox and invisible modes with a more familiar CAPTCHA pattern, [hCaptcha](/docs/forms/security/hcaptcha) may be a better fit. If you want a privacy-first option without a third-party CAPTCHA provider, look at [ALTCHA](/docs/forms/security/altcha).

## Best practices before you launch

### 1. Keep the site key and secret key in the right places

Cloudflare gives you two different keys:

- The **site key** is public and belongs in your frontend
- The **secret key** is private and belongs in your backend or form service configuration

Do not expose the secret key in your HTML or client-side JavaScript. With Static Forms, the secret key goes in the form's **Security** tab, and Turnstile is available from the Starter plan up.

### 2. Register every environment you plan to use

Add all relevant domains to your Turnstile widget configuration:

- Production
- Preview or staging
- `localhost` for local testing

Turnstile failures often come from domain configuration gaps rather than bad frontend code.

#### Use separate widgets and keys for production and non-production

Do not reuse the same Turnstile widget everywhere unless you intentionally want one shared configuration.

A better setup is:

- One production widget and key pair for live domains only
- A separate non-production widget and key pair for staging, preview, and local development

This keeps testing isolated, makes rotation safer, and reduces the chance of shipping a development configuration into production.

#### Do not add localhost to the production widget

`localhost` belongs in a non-production widget only.

Keep your production Turnstile widget limited to real live domains, and use a separate widget for staging and local work.

### 3. Make token handling explicit in your implementation

Make sure you know which token field name your backend expects and verify that your frontend sends that exact field.

That is one of the most important implementation details to verify. If you render the widget but submit a different field name, verification will fail.

Static Forms expects the token as `cf-turnstile-response`, the same name Cloudflare's widget uses for its hidden input. The [Cloudflare Turnstile with Static Forms](/docs/forms/security/turnstile) guide has HTML, React and Next.js examples.

### 4. Test the complete submission flow

A rendered widget is only the first half of the job. Before launch, verify that:

1. The Turnstile script loads
2. The widget renders on the page
3. The token is attached to the form submission
4. Your backend accepts the request successfully

This is especially important in React or Next.js apps where token handling is often manual.

### 5. Mint the token at submit time, not at page load

This is the single biggest implementation detail people get wrong, and it causes intermittent "verification failed" errors that are hard to reproduce.

Turnstile tokens are valid for **300 seconds** from when the widget solves them, and each token can be verified only once. The default integration (`<div class="cf-turnstile" data-sitekey="...">`) auto-solves the challenge as soon as the page loads. If the user spends a few minutes filling out the form, picks a large file attachment, or submits over a slow network, the token can expire mid-flight and Cloudflare rejects it with `invalid-input-response` or `timeout-or-duplicate`.

The fix is to render the widget in **execute mode** and trigger the challenge from your submit handler:

```javascript
const widgetId = window.turnstile.render('#cf-widget', {
  sitekey: 'YOUR_SITE_KEY',
  execution: 'execute',           // generate token on demand
  appearance: 'interaction-only', // widget stays invisible unless a challenge is needed
  callback: (token) => pendingResolve(token),
});

form.addEventListener('submit', async (e) => {
  e.preventDefault();
  const token = await new Promise((resolve) => {
    pendingResolve = resolve;
    window.turnstile.reset(widgetId);
    window.turnstile.execute(widgetId);
  });
  // ...append token and POST
});
```

With this pattern:

- The token is seconds old by the time your backend verifies it, regardless of how long the upload takes
- Most users see no widget at all (silent verification)
- The challenge UI only appears when Cloudflare's risk engine actually wants user interaction

Recommend this as your default integration pattern, **even when forms don't have file uploads** — it eliminates a class of intermittent failures with no real downside.

### 6. Plan for failure states

Even with execute-on-submit, you should still:

- Disable submit until the widget script has loaded
- Show a clear retry message when verification fails
- Branch on Static Forms' stable error codes: retry automatically on `captcha_expired_or_reused`, and show the retry message on `captcha_required` or `captcha_failed`

If you're using Static Forms, the implementation details for those flows live here: [Read the Turnstile setup guide](/docs/forms/security/turnstile).

### 7. Combine Turnstile with broader spam controls

Turnstile is one layer of protection. For better results:

- Keep field validation strict
- Use required fields intentionally
- Add honeypot protection where it makes sense
- Review submission patterns and adjust based on real abuse

This usually performs better than relying on a single control.

## Test keys for local and CI testing

Cloudflare publishes dummy keys for automated tests. They work on any domain, including `localhost`, so you don't need to register a test domain:

| Key | Value | Behavior |
|-----|-------|----------|
| Site key | `1x00000000000000000000AA` | Always passes (visible widget) |
| Site key | `2x00000000000000000000AB` | Always blocks (visible widget) |
| Site key | `3x00000000000000000000FF` | Forces an interactive challenge |
| Secret key | `1x0000000000000000000000000000000AA` | Always passes validation |
| Secret key | `2x0000000000000000000000000000000AA` | Always fails validation |
| Secret key | `3x0000000000000000000000000000000AA` | Fails as an already-spent token (`timeout-or-duplicate`) |

A test site key produces the dummy token `XXXX.DUMMY.TOKEN.XXXX`. Production secret keys reject it, so pair test keys with test keys.

Use them on a separate test form. Never save a test secret key on a live form. When we called siteverify on October 27, 2026, the `1x…AA` secret accepted any non-empty token, not just the dummy one, so a form with it saved lets any bot through.

For a localhost test page and a lookup table of Turnstile token errors, see [Turnstile test keys, localhost and token errors](/blog/turnstile-test-keys-token-errors).

## Common mistakes to avoid

The most common Turnstile issues are:

- Saving the site key where the secret key should go
- Forgetting to allow the domain in Cloudflare
- Using the wrong token field name
- Rendering the widget but never appending the token in a custom React flow
- Auto-solving on page load and letting the token expire during long sessions or slow uploads (use execute-on-submit)
- Testing only the UI instead of a real end-to-end submission

## Implementation checklist

Use this checklist before launch:

- Create a Turnstile widget in Cloudflare
- Register all production, staging, and local domains
- Save the Turnstile secret key in your backend or form service settings
- Add the widget to your form using the site key
- Confirm the form sends the token field your backend expects
- Run real test submissions in every environment

If you're using Static Forms, use:

- [Cloudflare Turnstile with Static Forms](/docs/forms/security/turnstile)
- [Spam protection overview](/docs/forms/security)
- The form's Security tab in your [dashboard](/app/forms)

## Choosing between Turnstile and the other options

Use Turnstile when low friction is the priority. Use hCaptcha when you want a more traditional CAPTCHA experience with visible or invisible modes. Use ALTCHA when you want a privacy-first option without a third-party CAPTCHA account.

If you are still choosing a provider, start here: [Compare spam protection options](/docs/forms/security).

---

## How to Add a Contact Form to Google Sites

Source: https://www.staticforms.dev/blog/google-sites-contact-form-tutorial  
Date: 2026-03-10  
Author: Static Forms Team

Google Sites is one of the easiest ways to build a website. It is free, works inside your browser, and integrates with the rest of Google Workspace. However, Google Sites does not include a built-in contact form that sends submissions to your email. The only native option is embedding a Google Form, which looks out of place and lacks features like email notifications, spam protection, and custom styling.

In this tutorial, you will learn how to add a professional contact form to your Google Sites website using Static Forms. The form will send submissions directly to your inbox, protect against spam, and match the look and feel of your site — all without writing any backend code.

## Why Not Just Use Google Forms?

Before we dive in, you might wonder why you would not just embed a Google Form. Here are some reasons:

- **No email notifications by default** — Google Forms collects responses in a spreadsheet but does not email you when someone submits
- **Limited styling** — Google Forms has its own design that cannot be customized to match your site
- **No spam protection** — there is no honeypot or CAPTCHA support
- **No reply-to address** — you cannot reply directly to the person who submitted the form

Static Forms solves all of these problems. You get instant email notifications, built-in spam protection, custom styling, and the ability to reply directly to submissions.

## Prerequisites

Before you begin, make sure you have:

- A Google Sites website (new Google Sites, not the classic version)
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## How It Works

Google Sites lets you embed custom HTML code into any page using the **Embed** feature. The embedded code runs inside an iframe on your page. We will use this feature to add an HTML form that submits data to the Static Forms API, which then delivers the submission to your email inbox.

The flow looks like this:

1. Visitor fills out the form on your Google Sites page
2. The form sends data to Static Forms via the API
3. Static Forms delivers the submission to your email
4. The visitor sees a success confirmation message

## Step 1: Get Your Static Forms API Key

1. Go to [staticforms.dev](https://www.staticforms.dev) and create a free account
2. Verify your email address
3. Copy your API key from the [dashboard](https://www.staticforms.dev/app/forms)

You will need this key in the next step.

## Step 2: Create the Contact Form HTML

Copy the following HTML code. This is a complete, self-contained contact form with built-in styling that works inside Google Sites. (If you'd rather pick your own fields, the free [HTML form generator](/tools/form-generator) builds the markup for you; paste its output into the same embed block.)

```html
<html>
<head>
  <style>
    * {
      box-sizing: border-box;
      margin: 0;
      padding: 0;
    }
    body {
      font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
      padding: 20px;
      background: transparent;
      color: #333;
    }
    h2 {
      font-size: 24px;
      margin-bottom: 8px;
    }
    .subtitle {
      color: #666;
      margin-bottom: 24px;
      font-size: 14px;
    }
    .form-group {
      margin-bottom: 16px;
    }
    label {
      display: block;
      margin-bottom: 4px;
      font-weight: 500;
      font-size: 14px;
    }
    input[type="text"],
    input[type="email"],
    textarea {
      width: 100%;
      padding: 10px 12px;
      border: 1px solid #d1d5db;
      border-radius: 6px;
      font-size: 14px;
      font-family: inherit;
      transition: border-color 0.2s;
    }
    input:focus,
    textarea:focus {
      outline: none;
      border-color: #2563eb;
      box-shadow: 0 0 0 3px rgba(37, 99, 235, 0.1);
    }
    textarea {
      resize: vertical;
      min-height: 100px;
    }
    button {
      background-color: #2563eb;
      color: white;
      padding: 10px 24px;
      border: none;
      border-radius: 6px;
      font-size: 14px;
      font-weight: 500;
      cursor: pointer;
      transition: background-color 0.2s;
    }
    button:hover {
      background-color: #1d4ed8;
    }
    button:disabled {
      background-color: #9ca3af;
      cursor: not-allowed;
    }
    .alert {
      padding: 12px 16px;
      border-radius: 6px;
      margin-bottom: 16px;
      font-size: 14px;
      display: none;
    }
    .alert-success {
      background-color: #d1fae5;
      color: #065f46;
      border: 1px solid #a7f3d0;
    }
    .alert-error {
      background-color: #fee2e2;
      color: #991b1b;
      border: 1px solid #fecaca;
    }
  </style>
</head>
<body>
  <h2>Contact Us</h2>
  <p class="subtitle">Send us a message and we will get back to you shortly.</p>

  <div id="alertBox" class="alert"></div>

  <form id="contactForm">
    <div class="form-group">
      <label for="name">Name *</label>
      <input type="text" id="name" name="name" required />
    </div>

    <div class="form-group">
      <label for="email">Email *</label>
      <input type="email" id="email" name="email" required />
    </div>

    <div class="form-group">
      <label for="subject">Subject</label>
      <input type="text" id="subject" name="subject" />
    </div>

    <div class="form-group">
      <label for="message">Message *</label>
      <textarea id="message" name="message" required></textarea>
    </div>

    <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />

    <button type="submit" id="submitBtn">Send Message</button>
  </form>

  <script>
    var form = document.getElementById('contactForm');
    var submitBtn = document.getElementById('submitBtn');
    var alertBox = document.getElementById('alertBox');

    form.addEventListener('submit', function(e) {
      e.preventDefault();

      submitBtn.disabled = true;
      submitBtn.textContent = 'Sending...';
      alertBox.style.display = 'none';
      alertBox.className = 'alert';

      var formData = new FormData(form);
      var data = {};
      formData.forEach(function(value, key) {
        data[key] = value;
      });

      data.apiKey = 'YOUR_API_KEY_HERE';
      data.replyTo = '@';

      fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(data)
      })
      .then(function(response) { return response.json(); })
      .then(function(result) {
        if (result.success) {
          alertBox.textContent = 'Thank you! Your message has been sent successfully.';
          alertBox.className = 'alert alert-success';
          alertBox.style.display = 'block';
          form.reset();
        } else {
          throw new Error(result.error || 'Submission failed');
        }
      })
      .catch(function() {
        alertBox.textContent = 'Something went wrong. Please try again.';
        alertBox.className = 'alert alert-error';
        alertBox.style.display = 'block';
      })
      .finally(function() {
        submitBtn.disabled = false;
        submitBtn.textContent = 'Send Message';
      });
    });
  </script>
</body>
</html>
```

**Important**: Replace `YOUR_API_KEY_HERE` with your actual API key from the Static Forms dashboard.

## Step 3: Embed the Form in Google Sites

Now that you have the HTML code, follow these steps to add it to your Google Sites page:

1. Open your site in the [Google Sites editor](https://sites.google.com)
2. Navigate to the page where you want the contact form
3. In the right sidebar, click **Insert** (the panel with text, images, and other elements)
4. Scroll down and click **Embed** (the `<>` icon)
5. Select the **Embed code** tab
6. Paste the entire HTML code from Step 2 into the code box
7. Click **Next** to see a preview of your form
8. Click **Insert** to add it to the page
9. Resize the embed block by dragging its edges — a height of around **500-600 pixels** works well for this form
10. Click **Publish** in the top right to make your changes live

That's it! Your contact form is now live on your Google Sites page.

## Step 4: Test Your Form

Before sharing your site, test the form:

1. Visit your published Google Sites page
2. Fill in the name, email, and message fields
3. Click **Send Message**
4. Check your inbox for the submission email

If you do not receive the email, check the troubleshooting section below.

## Customizing Your Form

### Change the Color Scheme

To match your site's branding, update the CSS colors in the embedded code. The main values to change are:

```css
/* Primary button color */
button {
  background-color: #2563eb; /* Change to your brand color */
}
button:hover {
  background-color: #1d4ed8; /* Slightly darker shade */
}

/* Focus ring color */
input:focus,
textarea:focus {
  border-color: #2563eb; /* Match your brand color */
  box-shadow: 0 0 0 3px rgba(37, 99, 235, 0.1);
}
```

### Add More Fields

You can add any standard form fields. For example, to add a phone number field:

```html
<div class="form-group">
  <label for="phone">Phone Number</label>
  <input type="tel" id="phone" name="phone" />
</div>
```

Every field with a `name` is included in the email notification, so no prefix is needed.

### Set a Custom Email Subject

Add a hidden field to set a fixed subject line for all submissions:

```html
<input type="hidden" name="subject" value="New message from Google Sites" />
```

Or keep the visible subject field from the example above to let visitors choose their own subject.

### Redirect to a Thank-You Page

If you prefer to redirect visitors after submission instead of showing an inline message, you can use a simple form POST approach instead. Replace the `<form>` tag and remove the JavaScript:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Your form fields here -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="hidden" name="redirectTo" value="https://yoursite.google.com/thank-you" />
  <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off" />
  <button type="submit">Send Message</button>
</form>
```

Create a separate "Thank You" page on your Google Site and use its URL as the `redirectTo` value.

## Adding reCAPTCHA Spam Protection

For additional spam protection beyond the honeypot field, you can add Google reCAPTCHA. First, get your site key from the [Google reCAPTCHA Admin Console](https://www.google.com/recaptcha/admin), then configure your secret key in your [Static Forms CAPTCHA settings](https://www.staticforms.dev/app/forms).

Add the reCAPTCHA script and widget to your embedded HTML:

```html
<script src="https://www.google.com/recaptcha/api.js" async defer></script>

<!-- Add inside the form, before the submit button -->
<div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
```

Then include the reCAPTCHA response in your JavaScript submission:

```javascript
var recaptchaResponse = document.querySelector('[name="g-recaptcha-response"]');
if (recaptchaResponse) {
  data['g-recaptcha-response'] = recaptchaResponse.value;
}
```

For a deeper dive, see our [understanding reCAPTCHA guide](/blog/understanding-recaptcha).

## Minimal Form Version

If you want the smallest possible form with no extra styling, here is a stripped-down version you can embed:

```html
<html>
<body style="font-family: Arial, sans-serif; padding: 16px;">
  <form action="https://api.staticforms.dev/submit" method="POST">
    <p><label>Name<br/><input type="text" name="name" required style="width:100%; padding:8px;" /></label></p>
    <p><label>Email<br/><input type="email" name="email" required style="width:100%; padding:8px;" /></label></p>
    <p><label>Message<br/><textarea name="message" required rows="4" style="width:100%; padding:8px;"></textarea></label></p>
    <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
    <input type="hidden" name="replyTo" value="@" />
    <input type="text" name="honeypot" style="display:none" />
    <p><button type="submit" style="padding:10px 20px; background:#2563eb; color:white; border:none; border-radius:4px; cursor:pointer;">Send</button></p>
  </form>
</body>
</html>
```

This version uses a standard form POST, so the page will redirect to a Static Forms confirmation page after submission. It is a good choice if you want something quick and simple.

## Troubleshooting Common Issues

### Form Does Not Appear on the Page

- ✅ Make sure you used the **Embed code** tab, not the **By URL** tab
- ✅ Check that you pasted the complete HTML including the `<html>`, `<head>`, and `<body>` tags
- ✅ Resize the embed block by dragging its edges — the default size may be too small to display the full form

### Not Receiving Email Notifications

- ✅ Verify your API key is correct — copy it again from the [dashboard](https://www.staticforms.dev/app/forms)
- ✅ Check your spam or junk folder
- ✅ Confirm your email address is verified in Static Forms
- ✅ Test with a different email address

### Form Submits but Shows an Error

- ✅ Open your browser's developer tools (F12) and check the Console tab for errors
- ✅ Make sure the API endpoint is correct: `https://api.staticforms.dev/submit`
- ✅ Verify the `Content-Type` header is set to `application/json` when using JavaScript submission

### Embed Block Is Too Small

Google Sites embed blocks have a default size that may cut off your form. To fix this:

1. Click on the embed block in the editor
2. Drag the bottom edge to increase the height
3. A height of 500-600 pixels is usually enough for a standard contact form
4. Publish your site again to see the updated size

## Best Practices

1. **Keep it short** — only ask for the information you actually need. Name, email, and message are usually enough.
2. **Use the honeypot field** — it is a simple, invisible spam protection that does not inconvenience your visitors
3. **Test before publishing** — always submit a test message to confirm everything works
4. **Check mobile layout** — visit your published site on a phone to make sure the form is readable and usable
5. **Use a clear call to action** — tell visitors what will happen when they submit the form

For more on labels, validation timing and mobile layout, see these [form UX best practices](/blog/form-ux-best-practices).

## Conclusion

Adding a contact form to Google Sites does not require any backend code or complex setup. With Static Forms, you can embed a fully functional, professional-looking contact form in just a few minutes. Your visitors get a smooth experience, and you receive submissions directly in your inbox with built-in spam protection.

Ready to add a contact form to your Google Sites website? [Sign up for Static Forms](https://www.staticforms.dev) and get started with 250 free submissions every 30 days.

For more integration guides, check out our tutorials for [GitHub Pages](/blog/github-pages-contact-form-tutorial), [Astro](/blog/astro-contact-form-tutorial), and [Next.js](/blog/using-staticforms-with-nextjs).

---

## How to Add a Contact Form to Your Astro Website

Source: https://www.staticforms.dev/blog/astro-contact-form-tutorial  
Date: 2026-02-28  
Author: Static Forms Team

Astro is a modern web framework that generates fast, static HTML by default. While this is great for performance, it means your site has no built-in way to process form submissions. You need a form backend service to handle the server-side work — receiving data, sending emails, and protecting against spam.

In this tutorial, you will learn how to add a fully functional contact form to your Astro website using Static Forms. We will cover two approaches: a simple HTML form and a more interactive JavaScript-powered version.

> **Prefer a working project?** The [complete Astro example](https://github.com/static-forms/static-forms-examples/tree/main/apps/astro-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## Prerequisites

Before you begin, make sure you have:

- An Astro project set up and running
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## Approach 1: Simple HTML Form

The simplest way to add a contact form to Astro is with a plain HTML form. No JavaScript required — the form submits directly to the Static Forms endpoint.

Create a new page at `src/pages/contact.astro`:

```astro
---
// src/pages/contact.astro
import Layout from '../layouts/Layout.astro';
---

<Layout title="Contact Us">
  <main>
    <h1>Contact Us</h1>
    <p>Send us a message and we will get back to you shortly.</p>

    <form action="https://api.staticforms.dev/submit" method="POST">
      <label for="name">Name</label>
      <input type="text" id="name" name="name" required />

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

      <label for="message">Message</label>
      <textarea id="message" name="message" rows="5" required></textarea>

      <!-- Static Forms configuration -->
      <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
      <input type="hidden" name="replyTo" value="@" />
      <input type="text" name="honeypot" style="display:none" />

      <button type="submit">Send Message</button>
    </form>
  </main>
</Layout>
```

Replace `YOUR_API_KEY_HERE` with your actual API key. The `replyTo` field set to `@` uses the submitter's email as the reply-to address. The hidden `honeypot` field provides basic bot protection.

This approach works immediately with zero client-side JavaScript. When a user submits the form, they are redirected to a Static Forms confirmation page. You can customize this by adding a `redirectTo` hidden field with your own thank-you page URL.

## Approach 2: Async Fetch with Client-Side JavaScript

For a smoother user experience without page redirects, you can use Astro's client-side scripting to submit the form via `fetch`:

```astro
---
// src/pages/contact.astro
import Layout from '../layouts/Layout.astro';
---

<Layout title="Contact Us">
  <main>
    <h1>Contact Us</h1>

    <div id="success" style="display:none; padding:16px; background:#d4edda; border-radius:4px; margin-bottom:16px;">
      Thank you! Your message has been sent.
    </div>
    <div id="error" style="display:none; padding:16px; background:#f8d7da; border-radius:4px; margin-bottom:16px;">
      Something went wrong. Please try again.
    </div>

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

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

      <label for="message">Message</label>
      <textarea id="message" name="message" rows="5" required></textarea>

      <input type="text" name="honeypot" style="display:none" />

      <button type="submit" id="submitBtn">Send Message</button>
    </form>
  </main>
</Layout>

<script>
  const form = document.getElementById('contactForm') as HTMLFormElement;
  const submitBtn = document.getElementById('submitBtn') as HTMLButtonElement;
  const successEl = document.getElementById('success')!;
  const errorEl = document.getElementById('error')!;

  form.addEventListener('submit', async (e) => {
    e.preventDefault();
    submitBtn.disabled = true;
    submitBtn.textContent = 'Sending...';
    successEl.style.display = 'none';
    errorEl.style.display = 'none';

    const formData = new FormData(form);
    const data = Object.fromEntries(formData);

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          ...data,
          apiKey: import.meta.env.PUBLIC_STATIC_FORMS_KEY,
          replyTo: '@',
        }),
      });

      const result = await response.json();

      if (result.success) {
        successEl.style.display = 'block';
        form.reset();
      } else {
        throw new Error(result.message);
      }
    } catch {
      errorEl.style.display = 'block';
    } finally {
      submitBtn.disabled = false;
      submitBtn.textContent = 'Send Message';
    }
  });
</script>
```

## Environment Variables

Instead of hardcoding your API key, store it in an environment variable. Create a `.env` file in your project root:

```
PUBLIC_STATIC_FORMS_KEY=your-api-key-here
```

Astro exposes variables prefixed with `PUBLIC_` to client-side code via `import.meta.env`. This keeps your key out of source control while still making it available in the browser. Note that form API keys are safe to expose client-side since they are tied to your verified email address.

## Adding reCAPTCHA Spam Protection

For stronger spam protection, add reCAPTCHA to your form. First, get your site key from the [Google reCAPTCHA Admin Console](https://www.google.com/recaptcha/admin), then configure your secret key in your [Static Forms CAPTCHA settings](https://www.staticforms.dev/app/forms).

Add the reCAPTCHA script to your layout's `<head>` and include the widget in your form:

```html
<!-- In your layout head -->
<script src="https://www.google.com/recaptcha/api.js" async defer></script>

<!-- In your form, before the submit button -->
<div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
```

When submitting via JavaScript, include the reCAPTCHA response token in your request body:

```javascript
const recaptchaResponse = document.querySelector('[name="g-recaptcha-response"]').value;
// Add g-recaptcha-response: recaptchaResponse to your POST body
```

For a deeper dive into reCAPTCHA, see our [understanding reCAPTCHA guide](/blog/understanding-recaptcha).

## Astro-Specific Documentation

For more detailed Astro integration instructions, including component examples and advanced configuration, check out our [Astro documentation page](/docs/astro).

## Next Steps

You now have a working contact form on your Astro site. Static Forms handles email delivery, spam protection, and submission storage so you can focus on building your site.

From the Starter plan ($6/month, or $4/month billed annually), you also get access to file uploads, webhooks, AI Reply, and auto-responders. Custom email templates are available from Pro. [Sign up for Static Forms](https://www.staticforms.dev) to get started with 250 free submissions every 30 days.

---

## The Complete Guide to Contact Forms on JAMstack Sites

Source: https://www.staticforms.dev/blog/jamstack-contact-form  
Date: 2026-02-28  
Author: Static Forms Team

JAMstack (JavaScript, APIs, Markup) is an architecture where websites are pre-built as static files and served from a CDN. Frameworks like Next.js, Gatsby, Hugo, Jekyll, Astro, and Nuxt all follow this pattern to deliver fast, secure websites. The tradeoff is that there is no server running to process form submissions, send emails, or store data.

This means every JAMstack site that needs a contact form faces the same question: how do you handle form submissions without a backend?

> **Using a framework?** The [Static Forms examples repo](https://github.com/static-forms/static-forms-examples) has a ready-to-deploy contact form for 13 frameworks, including Next.js, Nuxt, React, Vue, SvelteKit, Astro, Angular, React Router, SolidStart, Qwik, Gatsby, Eleventy and plain HTML. Each one has a one-click Deploy to Vercel button.

## Your Options for JAMstack Forms

### Serverless Functions

You can write your own serverless function (AWS Lambda, Vercel Functions, Netlify Functions) to process submissions. This gives you full control but requires:

- Writing and maintaining backend code
- Setting up an email service (SES, SendGrid, etc.)
- Implementing spam protection yourself
- Managing environment variables and deployment
- Monitoring for failures

For a simple contact form, this is a lot of infrastructure to build and maintain.

### Form Backend Services

A form backend service provides an API endpoint that handles everything for you: receiving submissions, sending emails, filtering spam, and storing data. You point your HTML form at the service's URL and it takes care of the rest.

This is the approach we recommend for most JAMstack sites. It works with any framework, any hosting provider, and requires zero backend code.

## Why Static Forms for JAMstack

The [Static Forms form backend](/) is designed specifically for this use case. Here is why it works well with JAMstack:

- **Zero backend code** — Add an action URL to your form and you are done
- **Works with any host** — Vercel, Netlify, GitHub Pages, Cloudflare Pages, AWS S3, or any CDN
- **Works with any framework** — HTML forms are universal across all JAMstack frameworks
- **Free tier** - 250 submissions every 30 days at no cost
- **Spam protection** — reCAPTCHA v2 on every plan, plus reCAPTCHA v3 (invisible) and Altcha (privacy-first CAPTCHA) from the Starter plan up
- **Free tools** - Submission dashboard and CSV export
- **Paid features** - File uploads, webhooks, and auto-responders from the Starter plan up ($6/month, or $4/month billed annually)

## Universal HTML Form

This form works with every JAMstack framework because it uses standard HTML:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <label for="name">Name</label>
  <input type="text" id="name" name="name" required />

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

  <label for="message">Message</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <!-- Static Forms configuration -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="text" name="honeypot" style="display:none" />

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

Replace `YOUR_API_KEY_HERE` with your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms). This form will work on any static site — just paste it into your HTML.

For a JavaScript-powered version with inline success/error messages (no page redirect), submit via `fetch` instead:

```javascript
const response = await fetch('https://api.staticforms.dev/submit', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    apiKey: 'YOUR_API_KEY_HERE',
    name: formData.name,
    email: formData.email,
    message: formData.message,
    replyTo: '@',
  }),
});

const result = await response.json();
if (result.success) {
  // Show success message
}
```

## Framework-Specific Notes

The HTML form above works everywhere, but each framework has its own conventions for components and environment variables. Here are quick pointers for the most popular JAMstack frameworks:

### Next.js

Use a React component with `useState` for form state and `fetch` for submission. Store your API key in `NEXT_PUBLIC_STATIC_FORMS_KEY`. See our full [Next.js integration guide](/docs/nextjs).

### Gatsby

Gatsby sites can use the same React component approach as Next.js. We have a dedicated tutorial: [Using Static Forms with Gatsby](/blog/using-staticforms-with-gatsby).

### Astro

Astro generates static HTML by default, so the plain HTML form works perfectly. For client-side interactivity, use an Astro `<script>` tag. See our [Astro documentation](/docs/astro).

### Nuxt

Use a Vue component with Composition API or Options API. Store your key in `NUXT_PUBLIC_STATIC_FORMS_KEY` and access it via `useRuntimeConfig()`. See our [Nuxt.js guide](/blog/using-staticforms-with-nuxtjs).

### Hugo

Hugo generates static HTML, so use the plain HTML form directly in your templates. Place the form in a partial (`layouts/partials/contact-form.html`) and include it in any page.

### Jekyll

Similar to Hugo, use the HTML form directly in your Liquid templates. Add it to a layout or include file (`_includes/contact-form.html`).

## Features That Matter for JAMstack

When choosing a form backend for your JAMstack site, consider these features:

### Spam Protection

Bots target every form on the internet. Static Forms gives you three layers of protection:

1. **Honeypot field** (free) — A hidden field that catches basic bots
2. **reCAPTCHA v2/v3** (v3 from Starter) — Google's bot detection, including an invisible option
3. **Altcha** (from Starter) — A privacy-first CAPTCHA that works without external tracking, ideal for GDPR compliance

### File Uploads

Accept file attachments (PDFs, images, documents) directly through your form. Files are included in the email notification and stored in your dashboard. Available from the Starter plan ($6/month, or $4/month billed annually).

### Webhooks

Trigger external services when a form is submitted. Send data to Slack, Zapier, your CRM, or any service that accepts HTTP requests. Available from the Starter plan; Google Sheets, Notion, Airtable and Mailchimp sync are on Pro.

### Auto-Responders

Automatically send a confirmation email to the person who submitted the form. Customize the subject and body to match your brand. Available from the Starter plan up.

## Get Started

Adding a contact form to your JAMstack site takes less than five minutes with Static Forms. Paste the HTML form into your site, add your API key, and you are receiving submissions immediately.

[Sign up for Static Forms](https://www.staticforms.dev) to get your free API key and start with 250 submissions every 30 days. No credit card required.

For more integration examples, check out our tutorials for [React](/blog/react-contact-form-email-tutorial), [Next.js](/blog/using-staticforms-with-nextjs), [Gatsby](/blog/using-staticforms-with-gatsby), and [Nuxt.js](/blog/using-staticforms-with-nuxtjs).

---

## How to Build a Beautiful Contact Form with Tailwind CSS

Source: https://www.staticforms.dev/blog/tailwind-contact-form  
Date: 2026-02-28  
Author: Static Forms Team

Tailwind CSS makes it easy to build professional-looking forms without writing custom CSS. Its utility-first approach gives you full control over spacing, colors, typography, and responsive behavior directly in your HTML. Combined with Static Forms for the backend, you can have a beautiful, working contact form in minutes.

In this guide, we will build a Tailwind-styled contact form from scratch, add polish with focus states and hover effects, create a dark mode variant, and wire it up to Static Forms for email delivery.

## Basic Contact Form

Here is a clean, minimal contact form styled with Tailwind CSS:

```html
<form action="https://api.staticforms.dev/submit" method="POST" class="max-w-lg mx-auto p-8">
  <h2 class="text-2xl font-bold text-gray-900 mb-6">Contact Us</h2>

  <div class="mb-4">
    <label for="name" class="block text-sm font-medium text-gray-700 mb-1">Name</label>
    <input
      type="text"
      id="name"
      name="name"
      required
      class="w-full px-4 py-2 border border-gray-300 rounded-lg text-gray-900 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
    />
  </div>

  <div class="mb-4">
    <label for="email" class="block text-sm font-medium text-gray-700 mb-1">Email</label>
    <input
      type="email"
      id="email"
      name="email"
      required
      class="w-full px-4 py-2 border border-gray-300 rounded-lg text-gray-900 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
    />
  </div>

  <div class="mb-6">
    <label for="message" class="block text-sm font-medium text-gray-700 mb-1">Message</label>
    <textarea
      id="message"
      name="message"
      rows="4"
      required
      class="w-full px-4 py-2 border border-gray-300 rounded-lg text-gray-900 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent resize-y"
    ></textarea>
  </div>

  <!-- Static Forms configuration -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
  <input type="hidden" name="replyTo" value="@" />
  <input type="text" name="honeypot" class="hidden" />

  <button
    type="submit"
    class="w-full bg-blue-600 text-white py-2 px-4 rounded-lg font-medium hover:bg-blue-700 transition-colors"
  >
    Send Message
  </button>
</form>
```

Replace `YOUR_API_KEY_HERE` with your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms). This form submits directly to Static Forms and delivers the message to your inbox.

## Polished Version with Enhanced States

Let's improve the form with better visual feedback, a card layout, and error state styling:

```html
<div class="min-h-screen bg-gray-50 flex items-center justify-center p-4">
  <form
    action="https://api.staticforms.dev/submit"
    method="POST"
    class="w-full max-w-md bg-white rounded-2xl shadow-lg p-8 space-y-5"
  >
    <div>
      <h2 class="text-2xl font-bold text-gray-900">Get in Touch</h2>
      <p class="text-gray-500 mt-1">We would love to hear from you.</p>
    </div>

    <div>
      <label for="name" class="block text-sm font-medium text-gray-700 mb-1">Name</label>
      <input
        type="text"
        id="name"
        name="name"
        required
        placeholder="Jane Doe"
        class="w-full px-4 py-2.5 border border-gray-300 rounded-lg text-gray-900 placeholder-gray-400
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 transition-colors
               invalid:border-red-500 invalid:focus:ring-red-500"
      />
    </div>

    <div>
      <label for="email" class="block text-sm font-medium text-gray-700 mb-1">Email</label>
      <input
        type="email"
        id="email"
        name="email"
        required
        placeholder="jane@example.com"
        class="w-full px-4 py-2.5 border border-gray-300 rounded-lg text-gray-900 placeholder-gray-400
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 transition-colors
               invalid:border-red-500 invalid:focus:ring-red-500"
      />
    </div>

    <div>
      <label for="subject" class="block text-sm font-medium text-gray-700 mb-1">Subject</label>
      <input
        type="text"
        id="subject"
        name="subject"
        placeholder="What is this about?"
        class="w-full px-4 py-2.5 border border-gray-300 rounded-lg text-gray-900 placeholder-gray-400
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 transition-colors"
      />
    </div>

    <div>
      <label for="message" class="block text-sm font-medium text-gray-700 mb-1">Message</label>
      <textarea
        id="message"
        name="message"
        rows="4"
        required
        placeholder="Tell us what you need..."
        class="w-full px-4 py-2.5 border border-gray-300 rounded-lg text-gray-900 placeholder-gray-400
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 transition-colors resize-y
               invalid:border-red-500 invalid:focus:ring-red-500"
      ></textarea>
    </div>

    <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
    <input type="hidden" name="replyTo" value="@" />
    <input type="text" name="honeypot" class="hidden" />

    <button
      type="submit"
      class="w-full bg-blue-600 text-white py-2.5 px-4 rounded-lg font-medium
             hover:bg-blue-700 active:bg-blue-800
             focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2
             transition-colors cursor-pointer
             disabled:bg-gray-400 disabled:cursor-not-allowed"
    >
      Send Message
    </button>
  </form>
</div>
```

Key details in this version:

- **Hover states** on inputs (`hover:border-gray-400`) give subtle feedback when users mouse over fields
- **Focus rings** (`focus:ring-2 focus:ring-blue-500`) clearly indicate the active field
- **Validation styling** (`invalid:border-red-500`) highlights fields with errors using native HTML validation
- **Active state** on the button (`active:bg-blue-800`) provides click feedback
- **Disabled state** (`disabled:bg-gray-400`) for when the form is submitting

## Dark Mode Variant

Tailwind's `dark:` modifier makes it straightforward to add dark mode support. Wrap the same form with dark mode classes:

```html
<div class="min-h-screen bg-gray-50 dark:bg-gray-900 flex items-center justify-center p-4">
  <form
    action="https://api.staticforms.dev/submit"
    method="POST"
    class="w-full max-w-md bg-white dark:bg-gray-800 rounded-2xl shadow-lg p-8 space-y-5"
  >
    <div>
      <h2 class="text-2xl font-bold text-gray-900 dark:text-white">Get in Touch</h2>
      <p class="text-gray-500 dark:text-gray-400 mt-1">We would love to hear from you.</p>
    </div>

    <div>
      <label for="name" class="block text-sm font-medium text-gray-700 dark:text-gray-300 mb-1">Name</label>
      <input
        type="text"
        id="name"
        name="name"
        required
        placeholder="Jane Doe"
        class="w-full px-4 py-2.5 border border-gray-300 dark:border-gray-600 rounded-lg
               text-gray-900 dark:text-white bg-white dark:bg-gray-700
               placeholder-gray-400 dark:placeholder-gray-500
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 dark:hover:border-gray-500 transition-colors"
      />
    </div>

    <div>
      <label for="email" class="block text-sm font-medium text-gray-700 dark:text-gray-300 mb-1">Email</label>
      <input
        type="email"
        id="email"
        name="email"
        required
        placeholder="jane@example.com"
        class="w-full px-4 py-2.5 border border-gray-300 dark:border-gray-600 rounded-lg
               text-gray-900 dark:text-white bg-white dark:bg-gray-700
               placeholder-gray-400 dark:placeholder-gray-500
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 dark:hover:border-gray-500 transition-colors"
      />
    </div>

    <div>
      <label for="message" class="block text-sm font-medium text-gray-700 dark:text-gray-300 mb-1">Message</label>
      <textarea
        id="message"
        name="message"
        rows="4"
        required
        placeholder="Tell us what you need..."
        class="w-full px-4 py-2.5 border border-gray-300 dark:border-gray-600 rounded-lg
               text-gray-900 dark:text-white bg-white dark:bg-gray-700
               placeholder-gray-400 dark:placeholder-gray-500
               focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent
               hover:border-gray-400 dark:hover:border-gray-500 transition-colors resize-y"
      ></textarea>
    </div>

    <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE" />
    <input type="hidden" name="replyTo" value="@" />
    <input type="text" name="honeypot" class="hidden" />

    <button
      type="submit"
      class="w-full bg-blue-600 text-white py-2.5 px-4 rounded-lg font-medium
             hover:bg-blue-700 active:bg-blue-800
             focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2
             dark:focus:ring-offset-gray-800
             transition-colors cursor-pointer"
    >
      Send Message
    </button>
  </form>
</div>
```

The dark mode classes adjust backgrounds (`dark:bg-gray-800`), text colors (`dark:text-white`), borders (`dark:border-gray-600`), and the focus ring offset color to match the dark background.

Make sure your Tailwind config has dark mode enabled. In `tailwind.config.js`, set `darkMode: 'class'` or `darkMode: 'media'` depending on whether you want manual toggle or system preference.

## Connecting to Static Forms

All the examples above use the standard Static Forms HTML integration. Replace `YOUR_API_KEY_HERE` with your API key and the form is ready to send emails. For JavaScript-powered submissions with loading states and inline success messages, see our [getting started guide](/blog/getting-started-with-static-forms).

## Wrapping Up

Tailwind CSS and Static Forms are a natural pairing for developers who want good-looking, functional forms without the overhead of a CSS framework or a custom backend. Copy any of the examples above, drop in your API key, and you have a production-ready contact form.

Ready to get started? [Sign up for Static Forms](https://www.staticforms.dev) and get 250 free submissions every 30 days.

---

## Vue Contact Form Tutorial - Send Email Without a Backend

Source: https://www.staticforms.dev/blog/vue-contact-form-tutorial  
Date: 2026-02-28  
Author: Static Forms Team

Building a contact form in Vue.js usually means setting up a backend server to handle submissions and send emails. With Static Forms, you can skip the backend entirely. Your Vue component sends form data to the Static Forms API, which handles email delivery, spam protection, and submission storage for you.

In this tutorial, we will build a complete contact form using Vue 3's Composition API, handle loading and error states, and briefly cover the Vue 2 Options API approach.

> **Prefer a working project?** The [complete Vue example](https://github.com/static-forms/static-forms-examples/tree/main/apps/vue-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## Prerequisites

- A Vue 3 project (Vite, Nuxt, or Vue CLI)
- A Static Forms account — [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## Vue 3 Composition API Contact Form

Create a `ContactForm.vue` component:

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

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

const loading = ref(false)
const success = ref(false)
const error = ref('')

async function handleSubmit() {
  loading.value = true
  success.value = false
  error.value = ''

  try {
    const response = await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        apiKey: import.meta.env.VITE_STATIC_FORMS_KEY,
        name: form.name,
        email: form.email,
        subject: form.subject,
        message: form.message,
        honeypot: form.honeypot,
        replyTo: '@',
      }),
    })

    const result = await response.json()

    if (result.success) {
      success.value = true
      form.name = ''
      form.email = ''
      form.subject = ''
      form.message = ''
    } else {
      throw new Error(result.message || 'Submission failed')
    }
  } catch (err) {
    error.value = 'Something went wrong. Please try again.'
  } finally {
    loading.value = false
  }
}
</script>

<template>
  <div class="contact-form-wrapper">
    <h2>Contact Us</h2>

    <div v-if="success" class="alert alert-success">
      Thank you! Your message has been sent successfully.
    </div>

    <div v-if="error" class="alert alert-error">
      {{ error }}
    </div>

    <form v-if="!success" @submit.prevent="handleSubmit">
      <div class="form-group">
        <label for="name">Name *</label>
        <input
          id="name"
          v-model="form.name"
          type="text"
          required
          placeholder="Your name"
        />
      </div>

      <div class="form-group">
        <label for="email">Email *</label>
        <input
          id="email"
          v-model="form.email"
          type="email"
          required
          placeholder="you@example.com"
        />
      </div>

      <div class="form-group">
        <label for="subject">Subject</label>
        <input
          id="subject"
          v-model="form.subject"
          type="text"
          placeholder="What is this about?"
        />
      </div>

      <div class="form-group">
        <label for="message">Message *</label>
        <textarea
          id="message"
          v-model="form.message"
          rows="5"
          required
          placeholder="Your message..."
        ></textarea>
      </div>

      <!-- Honeypot field for spam protection -->
      <input v-model="form.honeypot" type="text" style="display: none" />

      <button type="submit" :disabled="loading">
        {{ loading ? 'Sending...' : 'Send Message' }}
      </button>
    </form>
  </div>
</template>

<style scoped>
.contact-form-wrapper {
  max-width: 500px;
  margin: 0 auto;
  padding: 2rem;
}

.form-group {
  margin-bottom: 1rem;
}

label {
  display: block;
  margin-bottom: 0.25rem;
  font-weight: 500;
}

input[type="text"],
input[type="email"],
textarea {
  width: 100%;
  padding: 0.5rem 0.75rem;
  border: 1px solid #d1d5db;
  border-radius: 0.375rem;
  font-size: 1rem;
  box-sizing: border-box;
}

input:focus,
textarea:focus {
  outline: none;
  border-color: #3b82f6;
  box-shadow: 0 0 0 2px rgba(59, 130, 246, 0.3);
}

button {
  width: 100%;
  padding: 0.625rem 1rem;
  background-color: #3b82f6;
  color: white;
  border: none;
  border-radius: 0.375rem;
  font-size: 1rem;
  cursor: pointer;
}

button:hover {
  background-color: #2563eb;
}

button:disabled {
  background-color: #9ca3af;
  cursor: not-allowed;
}

.alert {
  padding: 1rem;
  border-radius: 0.375rem;
  margin-bottom: 1rem;
}

.alert-success {
  background-color: #d1fae5;
  color: #065f46;
}

.alert-error {
  background-color: #fee2e2;
  color: #991b1b;
}
</style>
```

### How It Works

1. **Reactive form state** is managed with `reactive()`, which tracks all field values
2. **`handleSubmit`** sends a JSON POST request to the Static Forms endpoint with your API key and form data
3. **Loading state** disables the button and shows "Sending..." while the request is in flight
4. **Success state** hides the form and displays a confirmation message
5. **Error handling** catches network or API failures and shows an error message
6. **Honeypot field** is hidden from users but catches bots that auto-fill all fields

### Environment Variables

Store your API key in a `.env` file:

```
VITE_STATIC_FORMS_KEY=your-api-key-here
```

Vite exposes variables prefixed with `VITE_` to the client. If you are using Nuxt, use `NUXT_PUBLIC_STATIC_FORMS_KEY` instead and access it via `useRuntimeConfig().public`.

## Vue 2 Options API Version

If you are working with Vue 2, here is a condensed version using the Options API:

```vue
<script>
export default {
  data() {
    return {
      form: { name: '', email: '', subject: '', message: '', honeypot: '' },
      loading: false,
      success: false,
      error: '',
    }
  },
  methods: {
    async handleSubmit() {
      this.loading = true
      this.error = ''

      try {
        const response = await fetch('https://api.staticforms.dev/submit', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({
            apiKey: process.env.VUE_APP_STATIC_FORMS_KEY,
            ...this.form,
            replyTo: '@',
          }),
        })

        const result = await response.json()
        if (result.success) {
          this.success = true
          this.form = { name: '', email: '', subject: '', message: '', honeypot: '' }
        } else {
          throw new Error(result.message)
        }
      } catch {
        this.error = 'Something went wrong. Please try again.'
      } finally {
        this.loading = false
      }
    },
  },
}
</script>
```

The template is the same as the Vue 3 version. The main difference is that data is returned from a `data()` function and the submit handler is defined in `methods`.

## Adding reCAPTCHA

For stronger spam protection beyond the honeypot, you can add reCAPTCHA to your form. Install a Vue reCAPTCHA package, get your site key from [Google reCAPTCHA](https://www.google.com/recaptcha/admin), and configure your secret key in your [Static Forms CAPTCHA settings](https://www.staticforms.dev/app/forms).

Include the `g-recaptcha-response` token in your submission body and Static Forms will verify it server-side.

For a detailed reCAPTCHA walkthrough, see our [understanding reCAPTCHA guide](/blog/understanding-recaptcha).

## Using with Nuxt

If you are building with Nuxt, check out our dedicated [Nuxt.js integration guide](/blog/using-staticforms-with-nuxtjs) for Nuxt-specific setup instructions and best practices.

## Get Started

You now have everything you need to add a working contact form to your Vue application. Static Forms handles email delivery, spam protection, and submission storage so you do not need to build or maintain a backend.

[Sign up for Static Forms](https://www.staticforms.dev) to get your API key and start receiving form submissions for free.

---

## Formspree vs Static Forms: Which Is Better in 2026?

Source: https://www.staticforms.dev/blog/formspree-vs-static-forms-comparison  
Date: 2026-01-13  
Author: Static Forms Team

Choosing the right form backend service can significantly impact your website's functionality, user experience, and your budget. Formspree and Static Forms are two popular solutions for handling form submissions on static websites, but they have important differences in pricing, features, and implementation.

In this comprehensive comparison, we'll examine both services across critical factors including ease of setup, features, spam protection, pricing, and platform compatibility. Whether you're building a personal portfolio, a business website, or a large-scale application, this guide will help you make an informed decision.

We make Static Forms, so treat this as our take. Formspree figures were checked against its public plans page in October 2026.

## Quick Comparison Overview

| Feature | Formspree | Static Forms |
|---------|-----------|--------------|
| **Free Tier** | 50 submissions/month | 250 submissions every 30 days |
| **Entry Paid Plan** | $10/mo billed yearly, $15 monthly (Personal: 200) | $4/mo billed annually, $6 monthly (Starter: 3,000) |
| **Setup Difficulty** | Very easy | Very easy |
| **Platform Support** | Any platform | Any platform |
| **AJAX/JSON Support** | ✅ Yes | ✅ Yes |
| **Spam Protection** | Formshield ML filtering, reCAPTCHA, honeypot (Business) | Honeypot, reCAPTCHA, Turnstile, hCaptcha, Altcha |
| **File Uploads** | ✅ Yes (Personal) | ✅ Yes (Starter) |
| **Webhooks** | ✅ Yes (Professional) | ✅ Yes (Starter) |
| **Autoresponders** | ✅ Yes (Professional) | ✅ Yes (Starter) |
| **Form Rules / Conditional Routing** | ✅ Yes (Business) | ✅ Yes (Pro, $9/mo monthly or $7.50/mo billed annually) |
| **AI-Powered Auto-Reply** | Not listed | ✅ Yes (Starter) |
| **Custom Email Domain** | ✅ Yes (Business) | ✅ Yes (Pro) |
| **Privacy-First CAPTCHA** | Not listed | ✅ Yes (Altcha, from Starter) |

## Is Formspree Free?

Yes, with limits. Formspree's free plan is meant "for testing and development" and allows **50 submissions per month**, with a 30-day submission archive. It includes AJAX forms, reCAPTCHA, Formshield spam filtering, and email, Discord, Slack, Telegram, and WhatsApp notifications. File uploads, webhooks, autoresponses, and most productivity integrations need a paid plan.

Static Forms' free plan includes **250 submissions every 30 days**, one form, honeypot and reCAPTCHA v2 spam protection, and automatic CleanTalk filtering. If you are looking for a free Formspree alternative, that is the main difference: five times Formspree's free allowance before you pay anything. See our [Formspree alternative](/alternatives/formspree) page for a quick feature table.

## Pricing Breakdown

### Formspree Pricing

Prices below are per month billed yearly, with the monthly-billing price in brackets.

**Free Plan, $0:**
- 50 submissions per month
- 30-day submission archive
- AJAX/JSON support, reCAPTCHA, Formshield spam filtering
- Email plus Discord, Slack, Telegram, and WhatsApp notifications

**Personal Plan, $10/month ($15 monthly):**
- 200 submissions per month
- File uploads with 1 GB of storage
- Custom "Thank You" page and multiple recipient emails
- Google Sheets, Notion, Airtable, Trello, GitHub, and other basic plugins

**Professional Plan, $20/month ($30 monthly):**
- 2,000 submissions per month
- File uploads with 5 GB of storage, one extra team member
- Autoresponses, API access, and advanced spam control
- Webhooks, Zapier, and premium plugins such as HubSpot and Mailchimp

**Business Plan, $60/month ($90 monthly):**
- 20,000 submissions per month
- File uploads with 10 GB of storage
- Rules engine, custom email templates, and custom email domains
- Custom honeypot, custom spam rules, and priority support

### Static Forms Pricing

**Free Plan:**
- 250 submissions every 30 days
- 1 form
- Email notifications
- Custom fields and custom redirects
- Honeypot + reCAPTCHA v2
- AJAX/JSON support

**Starter Plan - $6/month ($48/year, i.e. $4/month billed annually):**
- 3,000 submissions per month
- Unlimited forms
- Everything in Free
- AI-powered auto-reply
- reCAPTCHA v3, Cloudflare Turnstile, hCaptcha, and privacy-first Altcha
- Webhooks plus Slack, Telegram, and Discord
- File uploads (up to 4.5MB per submission, 1 GB stored)
- Auto-responder emails
- Unlimited submission history and retention by default
- Priority email support
- Hard caps at 3,000 submissions — no surprise overage charges

**Pro Plan - $9/month ($90/year, i.e. $7.50/month billed annually):**
- 25,000 submissions per month
- Everything in Starter
- 5 GB of persistent file storage
- Google Sheets, Notion, Airtable, and Mailchimp sync
- Form rules: conditional routing, subject/reply-to overrides, integration fan-out (10 per form)
- Custom sending domain and branding removal
- CC emails (up to 5 verified addresses)
- Custom HTML email templates
- Unlimited submission history and retention by default; optional shorter retention per form
- Opt-in overage billing beyond your quota

### Price Comparison for Common Use Cases

Using each service's price billed yearly:

| Use Case | Formspree | Static Forms |
|----------|-----------|--------------|
| **Personal portfolio** (under 50/mo) | $0 | $0 |
| **Small business** (1,000/mo) | $20/mo (Professional) | $4/mo (Starter, yearly) |
| **Growing business** (5,000/mo) | $60/mo (Business) | $7.50/mo (Pro, yearly) |

**Verdict:** for the same volume, Static Forms costs less at every tier in this table: 250 free submissions every 30 days, 3,000 for $4/month billed annually, and 25,000 for $7.50/month billed annually.

## Setup and Implementation

### Formspree Setup

Create a form in your Formspree account, then point your HTML form at its endpoint:

**HTML form**
```html
<form action="https://formspree.io/f/YOUR_FORM_ID" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>
```

**AJAX/JavaScript** (set the `Accept` header to `application/json`)
```javascript
fetch('https://formspree.io/f/YOUR_FORM_ID', {
  method: 'POST',
  body: JSON.stringify({ email, message }),
  headers: { 'Content-Type': 'application/json', Accept: 'application/json' }
})
```

Formspree also publishes an official React package (`@formspree/react`), covered below.

### Static Forms Setup

Create a free account, copy your API key, and add it to the form as a hidden field:

**HTML Setup:**
```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <button type="submit">Send</button>
</form>
```

**AJAX/JavaScript (Available on all plans):**
```javascript
fetch('https://api.staticforms.dev/submit', {
  method: 'POST',
  body: JSON.stringify({
    email,
    message,
    apiKey: 'YOUR_API_KEY'
  }),
  headers: { 'Content-Type': 'application/json' }
})
```

Don't want to write the markup by hand? The free [HTML form generator](/tools/form-generator) builds a contact form in plain HTML, React, or Next.js with your API key placeholder already in place.

**Verdict:** Both are easy to set up. Static Forms' free tier includes one form and five times Formspree's free submissions.

## Spam Protection Comparison

### Formspree Spam Protection

- **All plans:** Formshield machine-learning spam filtering, reCAPTCHA (default or your own key), domain restriction
- **Professional and up:** advanced spam control (adjustable filter sensitivity, category blocking)
- **Business and up:** custom honeypot field and custom spam rules

### Static Forms Spam Protection

**Free Plan:**
- Honeypot fields
- Google reCAPTCHA v2
- CleanTalk server-side filtering
- Rate limiting

**Starter Plan and above (from $4/month billed annually):**
- Everything in Free
- Google reCAPTCHA v3 (invisible)
- Cloudflare Turnstile and hCaptcha
- Altcha CAPTCHA (privacy-first, no tracking cookies)

**Configuration:**
```html
<!-- reCAPTCHA on free plan -->
<form action="https://api.staticforms.dev/submit" method="POST">
  <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <!-- Other fields -->
</form>
```

For privacy-conscious projects, Static Forms offers [Altcha CAPTCHA](/blog/implementing-altcha-captcha-html-website) which doesn't track users or use cookies.

**Verdict:** Formspree's Formshield filter covers every plan. Static Forms gives you more CAPTCHA choices, including privacy-first Altcha, from the Starter plan.

## Feature Comparison

### Email Notifications

**Formspree:**
- ✅ Submission emails on every plan
- ✅ Multiple recipient emails (Personal)
- ✅ Autoresponses (Professional)
- ✅ Custom email templates and custom email domains (Business)

**Static Forms:**
- ✅ Customizable notification emails
- ✅ Multiple recipient emails (free)
- ✅ Custom reply-to addresses (free)
- ✅ Auto-responder emails (Starter)
- ✅ CC recipients, custom sending domain, and custom HTML templates (Pro)

### File Uploads

**Formspree:**
- From the Personal plan ($10/mo billed yearly), with 1 GB, 5 GB, or 10 GB of storage by plan
- Each file can be up to 25MB
- Files are stored and linked in submission emails rather than attached

**Static Forms:**
- Available from the Starter plan ($6/mo, or $4/mo billed annually)
- 4.5MB limit per submission, counting every file and field, with 1 GB of persistent storage (5 GB on Pro)
- Multiple file support, sharing that limit
- Common file types supported (PDF, DOC, DOCX, images)

**Example:**
```html
<!-- Requires the Starter plan or above -->
<form action="https://api.staticforms.dev/submit" method="POST" enctype="multipart/form-data">
  <input type="file" name="attachment" accept=".pdf,.doc,.jpg,.png">
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <button type="submit">Upload</button>
</form>
```

**Verdict:** Both need a paid plan for uploads. Formspree allows larger files (25MB each); Static Forms includes uploads with 3,000 submissions a month on Starter, against Formspree Personal's 200.

### Webhooks & Integrations

**Formspree:**
- Discord, Slack, Telegram, and WhatsApp on every plan
- Google Sheets, Notion, Airtable, Trello, GitHub, Linear, and Asana from Personal
- Webhooks, Zapier, CRMs, and newsletter tools from Professional ($20/mo billed yearly)

**Static Forms:**
- Webhooks, Slack, Telegram, and Discord from the Starter plan ($4/mo billed annually)
- Google Sheets, Notion, Airtable, and Mailchimp on Pro ($7.50/mo billed annually)
- Zapier, Make, and n8n connections
- Flexible JSON payload to any HTTP endpoint

**Verdict:** Formspree has the longer plugin catalogue and puts chat notifications on its free plan. Static Forms gets you webhooks for less: Starter versus Formspree's Professional.

### Form Rules & Conditional Routing

Both services can act conditionally on a submission instead of sending every entry to the same inbox, but they gate it very differently.

**Formspree:**
- [Rules engine](https://help.formspree.io/articles/advanced-features/form-rules/) on the Business plan ($60/mo billed yearly)
- Not available on Free, Personal, or Professional

**Static Forms:**
- [Form rules](/docs/forms/rules) on Pro ($7.50/month billed annually), up to 10 rules per form
- Agency raises the cap to 25 rules per form and adds country, page URL, referrer, day-of-week, hour-of-day, attachment, UTM, and regex conditions
- Each rule combines conditions (ALL or ANY) with actions: route to an additional verified recipient, set the subject or reply-to, redirect the visitor, post to Slack/Discord/Telegram, add a row to Google Sheets/Airtable/Notion, call a webhook, skip the default email, or mark as spam
- Rules run top to bottom after spam filtering and before delivery, and a dry-run tester shows the per-condition trace before you save
- Rule recipients must be verified. Multiple recipients share one notification with visible CC addresses and count individually toward email quotas.
- Default-email suppression is explicit: matching rules can add recipients to normal delivery, or choose all notification recipients. Suppressing the default email does not suppress integrations.

**Verdict:** Static Forms includes conditional routing on Pro ($7.50/month billed annually, $9 monthly). Formspree lists its rules engine on Business; see its [current plans](https://formspree.io/plans).

### AI-Powered Auto-Reply

Static Forms has an **AI Reply** feature; Formspree's plans page doesn't list anything comparable.

**Static Forms AI Reply:**
- Top up workspace AI credits and enable AI Reply on a paid form; no AI provider API key is needed
- Upload your knowledge base content
- AI drafts a contextual reply to each submission
- Useful for support triage, FAQ answers, and lead follow-up
- Available from the Starter plan ($6/mo, or $4/mo billed annually)

**Formspree:**
- Template autoresponses from the Professional plan
- No AI-generated responses listed

Learn more about [AI Reply implementation](/docs/ai-reply).

### Custom Redirects

**Both services** support custom redirects after form submission:

**Formspree:** set a custom "Thank You" page URL per form (Personal and up).

**Static Forms:**
```html
<input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you">
```

## Framework Support

### React Integration

**Formspree** provides an official React package:
```bash
npm install @formspree/react
```

```jsx
import { useForm } from '@formspree/react';

function ContactForm() {
  const [state, handleSubmit] = useForm("YOUR_FORM_ID");

  return (
    <form onSubmit={handleSubmit}>
      <input type="email" name="email" />
      <button type="submit">Submit</button>
    </form>
  );
}
```

**Static Forms** works with standard fetch API (works in any framework):
```jsx
// Works in React, Vue, Angular, Svelte, etc.
const handleSubmit = async (e) => {
  e.preventDefault();
  const response = await fetch('https://api.staticforms.dev/submit', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ ...formData, apiKey })
  });
};
```

See our detailed guides:
- [React contact form tutorial](/blog/react-contact-form-email-tutorial)
- [Next.js integration](/blog/using-staticforms-with-nextjs)
- [Gatsby integration](/blog/using-staticforms-with-gatsby)

**Verdict:** Formspree's React package is convenient. Static Forms' plain fetch call works the same in every framework.

## Privacy

Static Forms offers [Altcha](/blog/implementing-altcha-captcha-html-website) from the Starter plan up, a CAPTCHA that works without third-party tracking cookies, and lets you choose US or EU data residency for your account. If GDPR is a deciding factor, check each provider's DPA and sub-processor list before you commit.

## Migration Between Services

### From Formspree to Static Forms

**Step 1:** Update form action
```html
<!-- Before -->
<form action="https://formspree.io/f/YOUR_FORM_ID">

<!-- After -->
<form action="https://api.staticforms.dev/submit">
```

**Step 2:** Add API key
```html
<input type="hidden" name="apiKey" value="YOUR_API_KEY">
```

**Step 3:** Update field names if needed
- `_replyto` → `replyTo`
- `_subject` → `subject`
- Set your thank-you page with a hidden `redirectTo` field

**Done!** Migration takes minutes.

## Use Case Recommendations

### Choose Formspree If:

✅ You want the official React package
✅ You want chat notifications (Slack, Discord, Telegram) on a free plan
✅ You need its larger plugin catalogue, such as CRM and support-desk plugins
✅ You need larger per-file uploads (25MB per file)
✅ You're already familiar with Formspree

### Choose Static Forms If:

✅ You want more free submissions (250 every 30 days vs 50 a month)
✅ Budget is important (from $4/mo for 3,000 submissions, or $7.50/mo for 25,000, both billed annually, vs Formspree's $10/mo billed yearly for 200)
✅ You want webhooks and autoresponders (Starter and up) without paying for a $20/mo plan
✅ You want conditional routing rules without paying for a $60/mo plan
✅ You want privacy-first CAPTCHA (Altcha, Starter and up)
✅ You want AI-drafted replies to submissions

## Real User Scenarios

Prices are per month billed yearly.

### Scenario 1: Personal Portfolio
**Need:** Simple contact form, ~20 submissions/month

**Formspree:** Free plan (50/month)
**Static Forms:** Free plan (250 every 30 days)
**Winner:** Tie for this volume

### Scenario 2: Freelancer Website
**Need:** Contact form + file uploads, ~100 submissions/month

**Formspree:** Personal plan, $10/mo
**Static Forms:** Starter plan, $4/mo billed annually
**Winner:** Static Forms costs less and includes 3,000 submissions instead of 200

### Scenario 3: Small Business
**Need:** Webhooks and autoresponders, 500 submissions/month

**Formspree:** Professional plan, $20/mo (webhooks and autoresponses start here)
**Static Forms:** Starter plan, $4/mo billed annually (includes 3,000 submissions)
**Winner:** Static Forms

### Scenario 4: Agency/Multiple Sites
**Need:** High volume, conditional routing, integrations

**Formspree:** Business plan, $60/mo (20,000 submissions)
**Static Forms:** Pro plan, $7.50/mo billed annually (25,000 submissions)
**Winner:** Static Forms

## Pricing Calculator

Prices for both services are per month billed yearly; monthly billing costs more.

| Monthly Submissions | Formspree Cost | Static Forms Cost |
|---------------------|----------------|-------------------|
| 0-50 | Free | Free |
| 51-200 | $10/mo (Personal) | Free up to 250 |
| 201-250 | $20/mo (Professional) | Free |
| 251-2,000 | $20/mo (Professional) | $4/mo (Starter, yearly) |
| 2,001-3,000 | $60/mo (Business) | $4/mo (Starter, yearly) |
| 3,001-20,000 | $60/mo (Business) | $7.50/mo (Pro, yearly) |
| 20,001-25,000 | Custom plan | $7.50/mo (Pro, yearly) |
| 25,001-30,000 | Custom plan | $16/mo (Agency, yearly) |

Static Forms Free counts 250 submissions every 30 days from signup, not per calendar month.

## Final Verdict

### Formspree Strengths:
- Official React integration package
- Chat notifications on the free plan and a large plugin catalogue
- Formshield ML spam filtering on every plan
- Larger per-file upload limit (25MB)

### Static Forms Strengths:
- Five times the free submissions (250 every 30 days vs 50 a month)
- Lower prices at every volume in the calculator above
- Webhooks, autoresponders, and file uploads from the Starter plan ($4/mo billed annually)
- **Form rules** on the Pro tier ($7.50/mo billed annually; Formspree lists them on Business)
- AI Reply and privacy-first Altcha CAPTCHA (Starter and up)

## Conclusion

For most sites, **Static Forms is the better value**: more free submissions, lower prices at every volume, and webhooks and autoresponders (Starter) and form rules (Pro) on cheaper plans.

**Choose Formspree** if you specifically need its React package, its plugin catalogue, or larger file uploads.

**Choose Static Forms** if you want:
- Better value (250 free submissions, then $4/mo for 3,000 or $7.50/mo for 25,000, billed annually)
- Webhooks and autoresponders from Starter
- [Form rules](/docs/forms/rules) on Pro
- **AI-powered auto-reply** and privacy-first Altcha CAPTCHA

Ready to get started? [Sign up for Static Forms](https://www.staticforms.dev) and start with the free tier (250 submissions every 30 days). Move up to Starter ($6/mo monthly, or $4/mo billed annually) for file uploads, AI Reply, webhooks, and 3,000 submissions, or Pro ($9/mo monthly, or $7.50/mo billed annually) for 25,000 submissions plus form rules and every integration.

Comparing services with similar names? [Static Forms vs StaticForm](/alternatives/staticform) covers StaticForm (staticform.app), a separate form backend that is easy to confuse with us.

For implementation guides, check out:
- [HTML form tutorial](/blog/html-form-send-email-without-server)
- [React integration](/blog/react-contact-form-email-tutorial)
- [GitHub Pages guide](/blog/github-pages-contact-form-tutorial)
- [Next.js tutorial](/blog/using-staticforms-with-nextjs)

---

## How to Build an Application Form with HTML & JavaScript (2026)

Source: https://www.staticforms.dev/blog/how-to-build-application-form  
Date: 2026-01-13  
Author: Static Forms Team

Building an application form is essential for businesses looking to collect structured information from job applicants, program participants, or membership candidates. Unlike simple contact forms, application forms require careful planning for multiple fields, file uploads (like resumes or portfolios), validation, and professional data handling.

In this comprehensive guide, you'll learn how to create production-ready application forms that handle file uploads, validate user input, and deliver submissions directly to your email—all without managing backend infrastructure or databases.

Whether you're creating a job application form, event registration, membership signup, or program application, this tutorial provides everything you need to implement a professional solution in minutes.

## What You'll Build

By the end of this tutorial, you'll have a complete application form with:

- ✅ Professional multi-field layout (name, email, phone, position, etc.)
- ✅ File upload capability for resumes, cover letters, and portfolios
- ✅ Form validation with helpful error messages
- ✅ Loading states and user feedback
- ✅ Email notifications with file attachments
- ✅ Spam protection (honeypot + optional reCAPTCHA)
- ✅ Responsive, accessible design
- ✅ React and Next.js versions included

## What is an Application Form?

An application form is a structured web form that collects detailed information from individuals applying for jobs, programs, memberships, or services. Unlike simple contact forms that might only capture name and message, application forms typically include:

### Common Application Form Use Cases

**Job Applications**
- Collecting resumes, cover letters, and portfolios
- Gathering work experience and qualifications
- Receiving references and contact information

**Program Registrations**
- Educational program applications
- Training course enrollments
- Certification programs

**Membership Applications**
- Organization memberships
- Club enrollments
- Subscription registrations

**Grant & Funding Applications**
- Scholarship applications
- Grant proposals
- Funding requests

## Essential Fields for Application Forms

A professional application form should include these core fields:

### Basic Information
- **Full Name** - First and last name
- **Email Address** - Primary contact method
- **Phone Number** - Secondary contact option
- **Location** - City, state, or country

### Position-Specific Fields
- **Position/Program** - What they're applying for
- **Cover Letter** - Why they're interested
- **Resume/CV Upload** - File upload for credentials
- **Portfolio** - Additional work samples (optional)

### Experience & Qualifications
- **Work Experience** - Previous roles or relevant background
- **Education** - Degrees or certifications
- **Skills** - Relevant competencies
- **References** - Contact information for references (optional)

### Additional Fields
- **Start Date** - When they're available
- **Additional Information** - Anything else they want to share
- **How did you hear about us?** - Marketing attribution

## Step 1: Create a Basic HTML Application Form

Let's start with a complete HTML application form with all essential fields:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Job Application Form</title>
  <style>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    body {
      font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, sans-serif;
      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
      padding: 40px 20px;
      min-height: 100vh;
    }

    .form-container {
      max-width: 700px;
      margin: 0 auto;
      background: white;
      border-radius: 12px;
      box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3);
      padding: 40px;
    }

    .form-header {
      text-align: center;
      margin-bottom: 30px;
    }

    .form-header h1 {
      color: #333;
      font-size: 28px;
      margin-bottom: 10px;
    }

    .form-header p {
      color: #666;
      font-size: 16px;
    }

    .form-group {
      margin-bottom: 24px;
    }

    label {
      display: block;
      font-weight: 600;
      color: #333;
      margin-bottom: 8px;
      font-size: 14px;
    }

    .required {
      color: #e74c3c;
      margin-left: 4px;
    }

    input[type="text"],
    input[type="email"],
    input[type="tel"],
    input[type="date"],
    input[type="file"],
    select,
    textarea {
      width: 100%;
      padding: 12px 16px;
      border: 2px solid #e1e8ed;
      border-radius: 8px;
      font-size: 15px;
      font-family: inherit;
      transition: border-color 0.3s, box-shadow 0.3s;
    }

    input[type="file"] {
      padding: 10px;
      cursor: pointer;
    }

    input:focus,
    select:focus,
    textarea:focus {
      outline: none;
      border-color: #667eea;
      box-shadow: 0 0 0 3px rgba(102, 126, 234, 0.1);
    }

    textarea {
      resize: vertical;
      min-height: 120px;
    }

    .file-info {
      font-size: 12px;
      color: #666;
      margin-top: 6px;
    }

    .form-row {
      display: grid;
      grid-template-columns: 1fr 1fr;
      gap: 20px;
    }

    @media (max-width: 600px) {
      .form-row {
        grid-template-columns: 1fr;
      }
    }

    button[type="submit"] {
      width: 100%;
      padding: 14px;
      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
      color: white;
      border: none;
      border-radius: 8px;
      font-size: 16px;
      font-weight: 600;
      cursor: pointer;
      transition: transform 0.2s, box-shadow 0.2s;
    }

    button[type="submit"]:hover {
      transform: translateY(-2px);
      box-shadow: 0 10px 25px rgba(102, 126, 234, 0.3);
    }

    button[type="submit"]:disabled {
      opacity: 0.6;
      cursor: not-allowed;
      transform: none;
    }

    .alert {
      padding: 16px;
      border-radius: 8px;
      margin-bottom: 24px;
      font-size: 14px;
    }

    .alert-success {
      background: #d4edda;
      border: 1px solid #c3e6cb;
      color: #155724;
    }

    .alert-error {
      background: #f8d7da;
      border: 1px solid #f5c6cb;
      color: #721c24;
    }

    .hidden {
      display: none !important;
    }

    /* Honeypot field - hidden from users */
    .hp-field {
      position: absolute;
      left: -9999px;
      width: 1px;
      height: 1px;
    }
  </style>
</head>
<body>
  <div class="form-container">
    <div class="form-header">
      <h1>Job Application Form</h1>
      <p>We're excited to learn more about you! Please complete all required fields.</p>
    </div>

    <div id="successMessage" class="alert alert-success hidden">
      ✅ Thank you for your application! We've received your information and will review it shortly. You'll hear from us within 5-7 business days.
    </div>

    <div id="errorMessage" class="alert alert-error hidden">
      ❌ Oops! Something went wrong. Please check your information and try again.
    </div>

    <form id="applicationForm" enctype="multipart/form-data">
      <!-- Honeypot field for spam protection -->
      <input type="text" name="_honey" class="hp-field" tabindex="-1" autocomplete="off">

      <div class="form-row">
        <div class="form-group">
          <label for="firstName">
            First Name <span class="required">*</span>
          </label>
          <input
            type="text"
            id="firstName"
            name="firstName"
            required
            placeholder="John"
          >
        </div>

        <div class="form-group">
          <label for="lastName">
            Last Name <span class="required">*</span>
          </label>
          <input
            type="text"
            id="lastName"
            name="lastName"
            required
            placeholder="Doe"
          >
        </div>
      </div>

      <div class="form-group">
        <label for="email">
          Email Address <span class="required">*</span>
        </label>
        <input
          type="email"
          id="email"
          name="email"
          required
          placeholder="john.doe@example.com"
        >
      </div>

      <div class="form-group">
        <label for="phone">
          Phone Number <span class="required">*</span>
        </label>
        <input
          type="tel"
          id="phone"
          name="phone"
          required
          placeholder="+1 (555) 123-4567"
        >
      </div>

      <div class="form-group">
        <label for="position">
          Position Applying For <span class="required">*</span>
        </label>
        <select id="position" name="position" required>
          <option value="">Select a position...</option>
          <option value="software-engineer">Software Engineer</option>
          <option value="product-manager">Product Manager</option>
          <option value="designer">UX/UI Designer</option>
          <option value="data-scientist">Data Scientist</option>
          <option value="marketing-manager">Marketing Manager</option>
          <option value="other">Other</option>
        </select>
      </div>

      <div class="form-group">
        <label for="resume">
          Resume / CV <span class="required">*</span>
        </label>
        <input
          type="file"
          id="resume"
          name="resume"
          accept=".pdf,.doc,.docx"
          required
        >
        <div class="file-info">Accepted formats: PDF, DOC, DOCX (Max 4MB)</div>
      </div>

      <div class="form-group">
        <label for="coverLetter">
          Cover Letter / Why are you interested? <span class="required">*</span>
        </label>
        <textarea
          id="coverLetter"
          name="coverLetter"
          required
          placeholder="Tell us why you're interested in this position and what makes you a great fit..."
        ></textarea>
      </div>

      <div class="form-group">
        <label for="experience">
          Years of Experience <span class="required">*</span>
        </label>
        <select id="experience" name="experience" required>
          <option value="">Select...</option>
          <option value="0-1">0-1 years</option>
          <option value="1-3">1-3 years</option>
          <option value="3-5">3-5 years</option>
          <option value="5-10">5-10 years</option>
          <option value="10+">10+ years</option>
        </select>
      </div>

      <div class="form-group">
        <label for="startDate">
          Available Start Date <span class="required">*</span>
        </label>
        <input
          type="date"
          id="startDate"
          name="startDate"
          required
        >
      </div>

      <div class="form-group">
        <label for="linkedin">
          LinkedIn Profile (Optional)
        </label>
        <input
          type="text"
          id="linkedin"
          name="linkedin"
          placeholder="https://www.linkedin.com/in/yourprofile"
        >
      </div>

      <div class="form-group">
        <label for="portfolio">
          Portfolio / Website (Optional)
        </label>
        <input
          type="text"
          id="portfolio"
          name="portfolio"
          placeholder="https://yourportfolio.com"
        >
      </div>

      <div class="form-group">
        <label for="additionalInfo">
          Additional Information (Optional)
        </label>
        <textarea
          id="additionalInfo"
          name="additionalInfo"
          placeholder="Anything else you'd like us to know..."
        ></textarea>
      </div>

      <button type="submit" id="submitBtn">
        Submit Application
      </button>
    </form>
  </div>

  <script>
    const form = document.getElementById('applicationForm');
    const submitBtn = document.getElementById('submitBtn');
    const successMessage = document.getElementById('successMessage');
    const errorMessage = document.getElementById('errorMessage');

    form.addEventListener('submit', async (e) => {
      e.preventDefault();

      // Hide previous messages
      successMessage.classList.add('hidden');
      errorMessage.classList.add('hidden');

      // Disable submit button
      submitBtn.disabled = true;
      submitBtn.textContent = 'Submitting...';

      try {
        // Create FormData object to handle file uploads
        const formData = new FormData(form);

        // Add Static Forms API key
        formData.append('apiKey', 'YOUR_API_KEY_HERE'); // Replace with your API key
        formData.append('replyTo', formData.get('email'));
        formData.append('subject', `Job Application: ${formData.get('position')}`);

        const response = await fetch('https://api.staticforms.dev/submit', {
          method: 'POST',
          body: formData // Don't set Content-Type header - browser will set it with boundary
        });

        const result = await response.json();

        if (result.success) {
          successMessage.classList.remove('hidden');
          form.reset();

          // Scroll to success message
          successMessage.scrollIntoView({ behavior: 'smooth', block: 'center' });
        } else {
          throw new Error('Submission failed');
        }
      } catch (error) {
        errorMessage.classList.remove('hidden');
        console.error('Error:', error);

        // Scroll to error message
        errorMessage.scrollIntoView({ behavior: 'smooth', block: 'center' });
      } finally {
        // Re-enable submit button
        submitBtn.disabled = false;
        submitBtn.textContent = 'Submit Application';
      }
    });
  </script>
</body>
</html>
```

This complete HTML application form includes:
- All essential fields for job applications
- Built-in validation
- File upload for resumes
- Professional styling
- Spam protection (honeypot field)
- Success and error messages

## Step 2: Adding File Upload Handling

File uploads are crucial for application forms. Here's what you need to know:

### Important File Upload Requirements

1. **Form enctype**: Must be set to `multipart/form-data`
```html
<form enctype="multipart/form-data">
```

2. **File input with restrictions**:
```html
<input
  type="file"
  name="resume"
  accept=".pdf,.doc,.docx"
  required
>
```

3. **FormData in JavaScript**: Don't use JSON for file uploads
```javascript
const formData = new FormData(form);
// Don't set Content-Type header manually
```

### File Size Limits

File uploads are available from the Starter plan up ($6/month, or $4/month billed annually):
- **Maximum submission size**: 4.5MB in total, counting every file plus the other fields. A larger submission is refused with HTTP 413 before Static Forms processes it, so check the size in the browser (4MB leaves room for the fields)
- **Multiple files**: Supported, but they share that limit
- **File types**: Use the `accept` attribute for client-side filtering; the server doesn't check file types

## Step 3: Form Validation Best Practices

Implement proper validation to improve user experience:

### HTML5 Validation

Use built-in HTML5 validation attributes:
```html
<!-- Email validation -->
<input type="email" required>

<!-- Phone number validation -->
<input type="tel" pattern="[0-9\s\-\+\(\)]+" required>

<!-- File type validation -->
<input type="file" accept=".pdf,.doc,.docx" required>

<!-- Date validation (restrict to future dates only) -->
<input type="date" required>
```

### Custom JavaScript Validation

Add more sophisticated validation:
```javascript
function validateForm(formData) {
  const email = formData.get('email');
  const phone = formData.get('phone');
  const file = formData.get('resume');

  // Validate email format
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailRegex.test(email)) {
    alert('Please enter a valid email address');
    return false;
  }

  // The whole submission must stay under 4.5MB; 4MB leaves room for the other fields
  if (file && file.size > 4 * 1024 * 1024) {
    alert('File size must be less than 4MB');
    return false;
  }

  // Validate file type
  const allowedTypes = ['application/pdf', 'application/msword',
    'application/vnd.openxmlformats-officedocument.wordprocessingml.document'];
  if (file && !allowedTypes.includes(file.type)) {
    alert('Only PDF, DOC, and DOCX files are allowed');
    return false;
  }

  return true;
}
```

## Step 4: React Application Form Component

For React applications, here's a complete component with hooks:

```jsx
import React, { useState } from 'react';
import './ApplicationForm.css';

function ApplicationForm() {
  const [formData, setFormData] = useState({
    firstName: '',
    lastName: '',
    email: '',
    phone: '',
    position: '',
    coverLetter: '',
    experience: '',
    startDate: '',
    linkedin: '',
    portfolio: '',
    additionalInfo: '',
  });

  const [resume, setResume] = useState(null);
  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData(prev => ({
      ...prev,
      [name]: value
    }));
  };

  const handleFileChange = (e) => {
    const file = e.target.files[0];

    // Validate file size (4MB, under the 4.5MB submission limit)
    if (file && file.size > 4 * 1024 * 1024) {
      alert('File size must be less than 4MB');
      e.target.value = '';
      return;
    }

    setResume(file);
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const submitData = new FormData();

      // Add all form fields
      Object.keys(formData).forEach(key => {
        submitData.append(key, formData[key]);
      });

      // Add file
      if (resume) {
        submitData.append('resume', resume);
      }

      // Add Static Forms fields
      submitData.append('apiKey', 'YOUR_API_KEY_HERE');
      submitData.append('replyTo', formData.email);
      submitData.append('subject', `Job Application: ${formData.position}`);

      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: submitData,
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });

        // Reset form
        setFormData({
          firstName: '',
          lastName: '',
          email: '',
          phone: '',
          position: '',
          coverLetter: '',
          experience: '',
          startDate: '',
          linkedin: '',
          portfolio: '',
          additionalInfo: '',
        });
        setResume(null);

        // Reset file input
        document.getElementById('resume').value = '';
      } else {
        throw new Error('Submission failed');
      }
    } catch (error) {
      setStatus({ submitting: false, submitted: false, error: true });
      console.error('Error:', error);
    }
  };

  return (
    <div className="form-container">
      <div className="form-header">
        <h1>Job Application Form</h1>
        <p>We're excited to learn more about you! Please complete all required fields.</p>
      </div>

      {status.submitted && (
        <div className="alert alert-success">
          ✅ Thank you for your application! We've received your information and will review it shortly.
        </div>
      )}

      {status.error && (
        <div className="alert alert-error">
          ❌ Oops! Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit}>
        <div className="form-row">
          <div className="form-group">
            <label htmlFor="firstName">
              First Name <span className="required">*</span>
            </label>
            <input
              type="text"
              id="firstName"
              name="firstName"
              value={formData.firstName}
              onChange={handleChange}
              required
              placeholder="John"
            />
          </div>

          <div className="form-group">
            <label htmlFor="lastName">
              Last Name <span className="required">*</span>
            </label>
            <input
              type="text"
              id="lastName"
              name="lastName"
              value={formData.lastName}
              onChange={handleChange}
              required
              placeholder="Doe"
            />
          </div>
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email Address <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            required
            placeholder="john.doe@example.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="phone">
            Phone Number <span className="required">*</span>
          </label>
          <input
            type="tel"
            id="phone"
            name="phone"
            value={formData.phone}
            onChange={handleChange}
            required
            placeholder="+1 (555) 123-4567"
          />
        </div>

        <div className="form-group">
          <label htmlFor="position">
            Position Applying For <span className="required">*</span>
          </label>
          <select
            id="position"
            name="position"
            value={formData.position}
            onChange={handleChange}
            required
          >
            <option value="">Select a position...</option>
            <option value="software-engineer">Software Engineer</option>
            <option value="product-manager">Product Manager</option>
            <option value="designer">UX/UI Designer</option>
            <option value="data-scientist">Data Scientist</option>
            <option value="marketing-manager">Marketing Manager</option>
            <option value="other">Other</option>
          </select>
        </div>

        <div className="form-group">
          <label htmlFor="resume">
            Resume / CV <span className="required">*</span>
          </label>
          <input
            type="file"
            id="resume"
            name="resume"
            accept=".pdf,.doc,.docx"
            onChange={handleFileChange}
            required
          />
          <div className="file-info">Accepted formats: PDF, DOC, DOCX (Max 4MB)</div>
        </div>

        <div className="form-group">
          <label htmlFor="coverLetter">
            Cover Letter / Why are you interested? <span className="required">*</span>
          </label>
          <textarea
            id="coverLetter"
            name="coverLetter"
            value={formData.coverLetter}
            onChange={handleChange}
            required
            placeholder="Tell us why you're interested in this position..."
          />
        </div>

        <div className="form-group">
          <label htmlFor="experience">
            Years of Experience <span className="required">*</span>
          </label>
          <select
            id="experience"
            name="experience"
            value={formData.experience}
            onChange={handleChange}
            required
          >
            <option value="">Select...</option>
            <option value="0-1">0-1 years</option>
            <option value="1-3">1-3 years</option>
            <option value="3-5">3-5 years</option>
            <option value="5-10">5-10 years</option>
            <option value="10+">10+ years</option>
          </select>
        </div>

        <div className="form-group">
          <label htmlFor="startDate">
            Available Start Date <span className="required">*</span>
          </label>
          <input
            type="date"
            id="startDate"
            name="startDate"
            value={formData.startDate}
            onChange={handleChange}
            required
          />
        </div>

        <div className="form-group">
          <label htmlFor="linkedin">LinkedIn Profile (Optional)</label>
          <input
            type="text"
            id="linkedin"
            name="linkedin"
            value={formData.linkedin}
            onChange={handleChange}
            placeholder="https://www.linkedin.com/in/yourprofile"
          />
        </div>

        <div className="form-group">
          <label htmlFor="portfolio">Portfolio / Website (Optional)</label>
          <input
            type="text"
            id="portfolio"
            name="portfolio"
            value={formData.portfolio}
            onChange={handleChange}
            placeholder="https://yourportfolio.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="additionalInfo">Additional Information (Optional)</label>
          <textarea
            id="additionalInfo"
            name="additionalInfo"
            value={formData.additionalInfo}
            onChange={handleChange}
            placeholder="Anything else you'd like us to know..."
          />
        </div>

        <button type="submit" disabled={status.submitting}>
          {status.submitting ? 'Submitting...' : 'Submit Application'}
        </button>
      </form>
    </div>
  );
}

export default ApplicationForm;
```

## Step 5: Next.js Application Form with App Router

For Next.js 13+ with App Router, create a client component:

```tsx
'use client';

import { useState, FormEvent } from 'react';

export default function ApplicationForm() {
  const [status, setStatus] = useState<{
    submitting: boolean;
    submitted: boolean;
    error: boolean;
  }>({
    submitting: false,
    submitted: false,
    error: false,
  });

  async function handleSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const form = event.currentTarget;
      const formData = new FormData(form);

      // Add Static Forms fields
      formData.append('apiKey', process.env.NEXT_PUBLIC_STATICFORMS_KEY!);
      formData.append('replyTo', formData.get('email') as string);
      formData.append('subject', `Job Application: ${formData.get('position')}`);

      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: formData,
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        form.reset();
      } else {
        throw new Error('Submission failed');
      }
    } catch (error) {
      setStatus({ submitting: false, submitted: false, error: true });
      console.error('Error:', error);
    }
  }

  return (
    <div className="max-w-3xl mx-auto p-6">
      <div className="text-center mb-8">
        <h1 className="text-3xl font-bold mb-2">Job Application Form</h1>
        <p className="text-gray-600">
          We're excited to learn more about you! Please complete all required fields.
        </p>
      </div>

      {status.submitted && (
        <div className="mb-6 p-4 bg-green-50 border border-green-200 rounded-lg text-green-800">
          ✅ Thank you for your application! We'll review it and get back to you soon.
        </div>
      )}

      {status.error && (
        <div className="mb-6 p-4 bg-red-50 border border-red-200 rounded-lg text-red-800">
          ❌ Oops! Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit} className="space-y-6">
        <div className="grid grid-cols-1 md:grid-cols-2 gap-6">
          <div>
            <label htmlFor="firstName" className="block text-sm font-medium mb-2">
              First Name <span className="text-red-500">*</span>
            </label>
            <input
              type="text"
              id="firstName"
              name="firstName"
              required
              className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
              placeholder="John"
            />
          </div>

          <div>
            <label htmlFor="lastName" className="block text-sm font-medium mb-2">
              Last Name <span className="text-red-500">*</span>
            </label>
            <input
              type="text"
              id="lastName"
              name="lastName"
              required
              className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
              placeholder="Doe"
            />
          </div>
        </div>

        <div>
          <label htmlFor="email" className="block text-sm font-medium mb-2">
            Email Address <span className="text-red-500">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
            placeholder="john.doe@example.com"
          />
        </div>

        <div>
          <label htmlFor="phone" className="block text-sm font-medium mb-2">
            Phone Number <span className="text-red-500">*</span>
          </label>
          <input
            type="tel"
            id="phone"
            name="phone"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
            placeholder="+1 (555) 123-4567"
          />
        </div>

        <div>
          <label htmlFor="position" className="block text-sm font-medium mb-2">
            Position Applying For <span className="text-red-500">*</span>
          </label>
          <select
            id="position"
            name="position"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
          >
            <option value="">Select a position...</option>
            <option value="software-engineer">Software Engineer</option>
            <option value="product-manager">Product Manager</option>
            <option value="designer">UX/UI Designer</option>
            <option value="data-scientist">Data Scientist</option>
            <option value="marketing-manager">Marketing Manager</option>
            <option value="other">Other</option>
          </select>
        </div>

        <div>
          <label htmlFor="resume" className="block text-sm font-medium mb-2">
            Resume / CV <span className="text-red-500">*</span>
          </label>
          <input
            type="file"
            id="resume"
            name="resume"
            accept=".pdf,.doc,.docx"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg"
          />
          <p className="text-xs text-gray-500 mt-1">
            Accepted formats: PDF, DOC, DOCX (Max 4MB)
          </p>
        </div>

        <div>
          <label htmlFor="coverLetter" className="block text-sm font-medium mb-2">
            Cover Letter / Why are you interested? <span className="text-red-500">*</span>
          </label>
          <textarea
            id="coverLetter"
            name="coverLetter"
            required
            rows={6}
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
            placeholder="Tell us why you're interested in this position..."
          />
        </div>

        <div>
          <label htmlFor="experience" className="block text-sm font-medium mb-2">
            Years of Experience <span className="text-red-500">*</span>
          </label>
          <select
            id="experience"
            name="experience"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
          >
            <option value="">Select...</option>
            <option value="0-1">0-1 years</option>
            <option value="1-3">1-3 years</option>
            <option value="3-5">3-5 years</option>
            <option value="5-10">5-10 years</option>
            <option value="10+">10+ years</option>
          </select>
        </div>

        <div>
          <label htmlFor="startDate" className="block text-sm font-medium mb-2">
            Available Start Date <span className="text-red-500">*</span>
          </label>
          <input
            type="date"
            id="startDate"
            name="startDate"
            required
            className="w-full px-4 py-2 border border-gray-300 rounded-lg focus:ring-2 focus:ring-blue-500"
          />
        </div>

        <button
          type="submit"
          disabled={status.submitting}
          className="w-full py-3 px-6 bg-blue-600 hover:bg-blue-700 text-white font-medium rounded-lg disabled:opacity-50 disabled:cursor-not-allowed transition-colors"
        >
          {status.submitting ? 'Submitting...' : 'Submit Application'}
        </button>
      </form>
    </div>
  );
}
```

## Step 6: Getting Your Static Forms API Key

To use Static Forms with your application form:

1. **Sign up for free** at [Static Forms](https://www.staticforms.dev)
2. **Create a new form** in your dashboard
3. **Copy your API key**
4. **Replace** `YOUR_API_KEY_HERE` in the code examples above

### Environment Variables (Recommended)

For production apps, use environment variables:

**Next.js (.env.local)**:
```bash
NEXT_PUBLIC_STATICFORMS_KEY=your_actual_api_key_here
```

**React (.env)**:
```bash
REACT_APP_STATICFORMS_KEY=your_actual_api_key_here
```

Then use:
```javascript
process.env.NEXT_PUBLIC_STATICFORMS_KEY  // Next.js
process.env.REACT_APP_STATICFORMS_KEY    // React
```

## Step 7: Spam Protection for Application Forms

Application forms are prime targets for spam. Implement these protection methods:

### 1. Honeypot Field (Built-in)

Add a hidden field that bots will fill but humans won't see:
```html
<input
  type="text"
  name="_honey"
  style="position: absolute; left: -9999px;"
  tabindex="-1"
  autocomplete="off"
>
```

Static Forms automatically rejects submissions where the honeypot field is filled.

### 2. reCAPTCHA v3

For additional protection, add Google reCAPTCHA v3 (available from the Starter plan up):

```html
<script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>

<script>
async function submitWithRecaptcha(formData) {
  const token = await grecaptcha.execute('YOUR_SITE_KEY', {
    action: 'submit_application'
  });

  formData.set('g-recaptcha-response', token);

  // Submit form
  const response = await fetch('https://api.staticforms.dev/submit', {
    method: 'POST',
    body: formData
  });
}
</script>
```

### 3. Altcha (Privacy-First Alternative)

Altcha is a privacy-focused CAPTCHA alternative, available from the Starter plan up:

```html
<script type="module" src="https://cdn.jsdelivr.net/npm/altcha/dist/altcha.min.js"></script>

<form>
  <!-- Your form fields -->

  <altcha-widget
    challengeurl="https://api.staticforms.dev/altcha/challenge"
    apikey="YOUR_API_KEY"
  ></altcha-widget>

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

## Advanced Features

### Multi-Step Application Forms

Break long forms into steps for better UX:

```javascript
const [step, setStep] = useState(1);
const totalSteps = 3;

function nextStep() {
  if (step < totalSteps) setStep(step + 1);
}

function prevStep() {
  if (step > 1) setStep(step - 1);
}

return (
  <form>
    {/* Progress indicator */}
    <div className="progress">
      Step {step} of {totalSteps}
    </div>

    {/* Step 1: Personal Info */}
    {step === 1 && (
      <div>
        <input name="firstName" placeholder="First Name" />
        <input name="lastName" placeholder="Last Name" />
        <input name="email" type="email" placeholder="Email" />
        <button type="button" onClick={nextStep}>Next</button>
      </div>
    )}

    {/* Step 2: Experience */}
    {step === 2 && (
      <div>
        <select name="position">...</select>
        <select name="experience">...</select>
        <textarea name="coverLetter"></textarea>
        <button type="button" onClick={prevStep}>Back</button>
        <button type="button" onClick={nextStep}>Next</button>
      </div>
    )}

    {/* Step 3: Documents & Submit */}
    {step === 3 && (
      <div>
        <input type="file" name="resume" />
        <input name="linkedin" placeholder="LinkedIn" />
        <button type="button" onClick={prevStep}>Back</button>
        <button type="submit">Submit Application</button>
      </div>
    )}
  </form>
);
```

### Webhook Integration for ATS

Connect your application form to Applicant Tracking Systems:

1. Enable webhooks in your Static Forms dashboard (Starter plan and up)
2. Add your ATS webhook URL
3. Map form fields to ATS fields
4. Receive real-time application notifications

### Auto-Responder Emails

Send automatic confirmation emails to applicants:

1. Enable auto-responders in dashboard
2. Customize email template
3. Include next steps and timeline
4. Build trust with applicants

## Common Issues & Troubleshooting

### File Upload Not Working

**Problem**: Files not being attached to emails

**Solution**:
1. Ensure `enctype="multipart/form-data"` on form
2. Use FormData() in JavaScript, not JSON
3. Don't set Content-Type header manually
4. Upgrade to a paid plan — file uploads are available from Starter ($6/month, or $4/month billed annually)

### Form Validation Failing

**Problem**: Form submits with invalid data

**Solution**:
1. Add HTML5 validation attributes (required, type="email", etc.)
2. Implement JavaScript validation before submit
3. Check the submission size limit (4.5MB for all files and fields together)
4. Validate file types

### Submissions Not Arriving

**Problem**: Form submits successfully but no email received

**Solution**:
1. Check spam folder
2. Verify API key is correct
3. Ensure email address in dashboard settings is correct
4. Check Static Forms dashboard for submission logs

## Best Practices Summary

✅ **Do:**
- Use clear, descriptive field labels
- Mark required fields with asterisks
- Provide helpful placeholder text
- Validate file sizes and types
- Show loading states during submission
- Display clear success/error messages
- Implement spam protection
- Make forms mobile-responsive
- Include privacy policy link
- Use auto-responders for better UX

❌ **Don't:**
- Ask for unnecessary information
- Use technical jargon in labels
- Make all fields required
- Skip error handling
- Forget file size limits
- Ignore accessibility
- Use intrusive CAPTCHAs
- Skip mobile testing

## Conclusion

You now have everything needed to build professional application forms with file uploads, validation, and spam protection. Whether you're creating job application forms, program registrations, or membership applications, these patterns will help you collect structured data efficiently.

Static Forms handles all the backend complexity—email delivery, file attachments (Starter and up), spam protection, and data storage—so you can focus on building great user experiences.

## Next Steps

- [Sign up for Static Forms](https://www.staticforms.dev) (free tier available)
- [Explore file upload documentation](/docs/file-uploads)
- [Learn about webhook integrations](/docs/webhooks)
- [Add AI-powered auto-replies](/docs/ai-reply)
- [Implement spam protection](/docs/spam-protection)

Ready to accept your first application? [Get started with Static Forms today](https://www.staticforms.dev) and start receiving applications in minutes.

---

## Netlify Forms vs Static Forms: Complete Comparison (2026)

Source: https://www.staticforms.dev/blog/netlify-forms-vs-static-forms-comparison  
Date: 2026-01-13  
Author: Static Forms Team

Netlify Forms and Static Forms both handle form submissions without server-side code, but they are built for different situations. Netlify Forms is part of Netlify's hosting platform; Static Forms is a form backend you can use from any host.

We make Static Forms, so treat this as our take. Netlify facts were checked against Netlify's pricing page and Forms documentation in October 2026. If you want the short version, see our [Netlify Forms alternative](/alternatives/netlify-forms) page.

> **Bottom line up front:** if your site is already on Netlify and you only need submissions emailed to you, Netlify Forms is hard to beat: on Netlify's current credit-based plans, Forms are free and unlimited. Static Forms is the better fit when you host elsewhere, might move hosts, or want autoresponders, AI replies, more CAPTCHA options, or built-in app integrations.

## Quick Overview

| Feature | Netlify Forms | Static Forms |
|---------|---------------|--------------|
| **Hosting Required** | Netlify only | Any hosting platform |
| **Form Pricing** | Free and unlimited on credit-based plans | Free for 250 submissions every 30 days; paid from $4/mo billed annually |
| **Setup Complexity** | Very simple (one attribute) | Simple (endpoint + API key) |
| **Automatic Spam Filtering** | Akismet | CleanTalk |
| **CAPTCHA Options** | reCAPTCHA 2, honeypot | reCAPTCHA v2 (Free); v3, Turnstile, hCaptcha, Altcha (Starter) |
| **Notifications** | Email, webhooks, Slack | Email (Free); webhooks, Slack, Discord, Telegram (Starter) |
| **Autoresponders** | Not documented | ✅ Yes (Starter) |
| **AI-Powered Auto-Reply** | Not documented | ✅ Yes (Starter) |
| **File Uploads** | ✅ Yes (8 MB per request) | ✅ Yes (Starter, 4.5MB per submission) |
| **Works Without Netlify** | ❌ No | ✅ Yes |

## Netlify Forms Pricing

Netlify moved to credit-based plans. Its Forms usage and billing docs state: "For credit-based plans, Forms are free and unlimited." What you pay for is the hosting plan your site is on:

- **Free:** $0, 300 credits a month
- **Personal:** $9/month, 1,000 credits a month
- **Pro:** $20/month with unlimited members, from 3,000 credits a month

Credits are spent on deploys, compute, bandwidth, and web requests, not on form submissions. Teams still on Netlify's legacy plans are metered per site on form submissions and file-upload storage, so check **Forms > Usage** in your Netlify dashboard if that applies to you.

## Static Forms Pricing

**Free Tier:**
- 250 submissions every 30 days
- 1 form
- Email notifications
- Honeypot + reCAPTCHA v2, CleanTalk filtering
- No file uploads (submissions with files are rejected on Free)

**Starter - $6/month ($48/year, i.e. $4/month billed annually):**
- 3,000 submissions per month
- Unlimited forms
- Everything in Free
- reCAPTCHA v3 (invisible), Turnstile, hCaptcha, Altcha
- Webhooks plus Slack, Telegram, and Discord
- File uploads with 1 GB of persistent storage
- AI Reply and auto-responder emails
- Unlimited submission history and retention by default
- Priority email support

**Pro - $9/month ($90/year):**
- 25,000 submissions per month
- Everything in Starter
- 5 GB of persistent file storage
- Google Sheets, Notion, Airtable, and Mailchimp sync
- Conditional form rules
- Custom sending domain and branding removal
- Unlimited submission history and retention by default; optional shorter retention per form
- Opt-in overage billing

**Verdict on price:** if you host on Netlify, Netlify Forms costs nothing extra. Static Forms costs nothing up to 250 submissions every 30 days on any host, and paid plans start at $4/month billed annually when you need more volume or features.

## Platform Flexibility

### Netlify Forms: Netlify Hosting Required

Netlify's build system finds forms by parsing your site's HTML at deploy time, so Netlify Forms only works on sites Netlify builds and hosts.

**Pros:**
- ✅ Seamless if you're already on Netlify
- ✅ Automatic form detection during builds
- ✅ No extra account or API key

**Cons:**
- ❌ Only works on Netlify hosting
- ❌ Switching hosts means replacing your form handling

**Example - Netlify Forms Setup:**
```html
<!-- Just add data-netlify="true" -->
<form name="contact" data-netlify="true">
  <input type="text" name="name">
  <input type="email" name="email">
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>
```

### Static Forms: Any Host

Static Forms works on Netlify, Vercel, GitHub Pages, Cloudflare Pages, traditional hosting, or your own servers.

**Example - Static Forms Setup:**
```html
<!-- Works anywhere HTML is served -->
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="text" name="name">
  <input type="email" name="email">
  <textarea name="message"></textarea>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <button type="submit">Send</button>
</form>
```

Prefer not to write the markup? The free [HTML form generator](/tools/form-generator) builds this form in HTML, React, or Next.js for you.

**Verdict:** on Netlify, Netlify Forms is the simpler setup. Anywhere else, or if you want to keep the option to move, Static Forms works without changes.

## Spam Protection

### Netlify Forms

- Every submission is filtered by Akismet; flagged submissions go to a separate spam list
- Optional honeypot field (`netlify-honeypot="bot-field"`)
- Optional reCAPTCHA 2 challenge, Netlify-provided or your own keys

```html
<form name="contact" data-netlify="true" netlify-honeypot="bot-field">
  <input type="hidden" name="bot-field">
  <!-- Other fields -->
</form>
```

### Static Forms

**Free:**
- Honeypot fields
- Google reCAPTCHA v2
- CleanTalk server-side filtering and rate limiting

**Starter and above:**
- Google reCAPTCHA v3 (invisible)
- Cloudflare Turnstile and hCaptcha
- Altcha CAPTCHA (privacy-first, no tracking cookies)

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="text" name="name">
  <input type="email" name="email">
  <textarea name="message"></textarea>

  <!-- Free reCAPTCHA -->
  <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>

  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  <button type="submit">Send</button>
</form>
```

For privacy-conscious projects, Static Forms offers [Altcha CAPTCHA](/blog/implementing-altcha-captcha-html-website) from the Starter plan up, which doesn't track users.

**Verdict:** both filter spam automatically. Static Forms offers more CAPTCHA choices from Starter.

## Features Deep Dive

### Notifications and Replies

**Netlify Forms:**
- Email notifications, sent from Netlify's address with the submitter as reply-to when your form has an `email` field
- Custom email subject lines
- Webhook and Slack notifications

**Static Forms:**
- Email notifications with custom reply-to and multiple recipients
- Auto-responder emails to the submitter (Starter)
- AI Reply, which drafts a reply from your own knowledge base (Starter)
- Custom sending domain (Pro)

Learn more in our [AI Reply documentation](/docs/ai-reply).

### File Uploads

**Netlify Forms:**
- Supported; files are linked from submission details, notifications, CSV exports, and the API
- The whole form request is limited to 8 MB, and uploads time out after 30 seconds

**Static Forms:**
- Supported from the Starter plan ($6/mo, or $4/mo billed annually)
- 4.5MB limit per submission, counting every file and field, with 1 GB of persistent storage (5 GB on Pro)
- Multiple file uploads supported, sharing that limit

Learn more in our [file upload tutorial](/blog/nextjs-contact-form-document-upload).

### Integrations

**Netlify Forms:** email, webhooks, and Slack, plus third-party services for anything else.

**Static Forms:** webhooks, Slack, Discord, and Telegram from Starter; Google Sheets, Notion, Airtable, and Mailchimp on Pro; Zapier, Make, and n8n connections.

### Submissions Dashboard

**Netlify Forms:** submissions live in the Netlify dashboard, with spam and verified lists, CSV export, and an API.

**Static Forms:** a dedicated forms dashboard with search, CSV export, and per-form settings.

## JavaScript/AJAX Support

### Netlify Forms

JavaScript-rendered forms (React, Vue, Gatsby, Nuxt) need a hidden HTML copy of the form so the build can detect it, and AJAX requests must include a `form-name` field:

```javascript
fetch('/', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({ 'form-name': 'contact', ...formData }).toString()
})
```

### Static Forms

```javascript
fetch('https://api.staticforms.dev/submit', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ ...formData, apiKey: 'YOUR_API_KEY' })
})
```

No hidden forms or build-time detection.

**Verdict:** for single-page apps, Static Forms needs less setup.

## Framework Guides

Static Forms works with any framework that can submit a form or call `fetch`:
- Gatsby ([tutorial](/blog/using-staticforms-with-gatsby))
- Next.js ([tutorial](/blog/using-staticforms-with-nextjs))
- Nuxt.js ([tutorial](/blog/using-staticforms-with-nuxtjs))
- React, Vue, Angular, Svelte, Hugo, Jekyll, Eleventy, Astro, and plain HTML

## Migration from Netlify Forms to Static Forms

**Step 1: Update your form**
```html
<!-- Before (Netlify Forms) -->
<form name="contact" data-netlify="true">

<!-- After (Static Forms) -->
<form action="https://api.staticforms.dev/submit" method="POST">
```

**Step 2: Add API key**
```html
<input type="hidden" name="apiKey" value="YOUR_API_KEY">
```

**Step 3: Remove Netlify-specific attributes**
```html
<!-- Remove these -->
data-netlify="true"
netlify-honeypot="bot-field"
```

**Step 4: Test thoroughly** before switching production traffic.

## Which Should You Choose?

### Choose Netlify Forms If:

✅ Your site is hosted on Netlify and will stay there
✅ Email, webhook, or Slack notifications are all you need
✅ You want form handling at no extra cost on a credit-based plan

### Choose Static Forms If:

✅ You host on Vercel, GitHub Pages, Cloudflare Pages, or anywhere else
✅ You want to keep the option to change hosts
✅ You want autoresponders or AI replies to submitters
✅ You want Turnstile, hCaptcha, or privacy-first Altcha (Starter and up)
✅ You want Google Sheets, Notion, Airtable, or Mailchimp without a third-party connector (Pro and up)
✅ You're building a single-page app and don't want hidden detection forms

## Conclusion

If you're on Netlify and your needs are simple, use Netlify Forms; it's free on current plans and the one-attribute setup is hard to beat.

If you want your forms to work regardless of where the site is hosted, or you need autoresponders, AI Reply, more CAPTCHA options, or built-in integrations, Static Forms is the better option. [Sign up for free](https://www.staticforms.dev) and start with 250 submissions every 30 days on any host.

Comparing services with similar names? [Static Forms vs StaticForm](/alternatives/staticform) covers StaticForm (staticform.app), a separate form backend that is easy to confuse with us.

For implementation guides, check out our tutorials for [GitHub Pages](/blog/github-pages-contact-form-tutorial), [Next.js](/blog/using-staticforms-with-nextjs), and [HTML forms](/blog/html-form-send-email-without-server).

---

## User Registration Form Tutorial: HTML, React & Vue (2026)

Source: https://www.staticforms.dev/blog/user-registration-form-tutorial  
Date: 2026-01-13  
Author: Static Forms Team

Creating a user registration form is one of the most common requirements for web applications. Whether you're building a SaaS platform, membership site, online community, or any application requiring user accounts, a well-designed registration form is your first touchpoint with new users.

In this comprehensive tutorial, you'll learn how to build secure, user-friendly registration forms with email verification, password validation, and GDPR compliance—all without managing backend infrastructure.

## What You'll Build

By the end of this tutorial, you'll have production-ready registration forms with:

- ✅ Email and password validation
- ✅ Password strength indicators
- ✅ Email verification workflow
- ✅ Terms & conditions agreement
- ✅ GDPR consent management
- ✅ Secure data handling
- ✅ Examples in HTML, React, and Vue.js
- ✅ Spam protection built-in

## Why User Registration Forms Matter

User registration forms serve as the gateway to your application. A well-designed registration form:

### Increases Conversion Rates
- Simplified forms reduce friction
- Clear error messages prevent abandonment
- Progressive disclosure keeps users engaged

### Ensures Data Quality
- Validation prevents fake or incorrect data
- Email verification confirms real users
- Strong passwords protect user accounts

### Builds Trust
- GDPR compliance shows respect for privacy
- Security measures demonstrate professionalism
- Transparent data usage builds confidence

### Prevents Fraud
- Email verification reduces fake accounts
- CAPTCHA protection blocks bots
- Rate limiting prevents abuse

## Essential Registration Form Fields

A well-designed registration form balances security with usability. Here are the essential fields:

### Required Fields

**Email Address**
- Primary identifier for the account
- Used for login and communication
- Must be validated and verified

**Password**
- Minimum 8-12 characters
- Mix of uppercase, lowercase, numbers, symbols
- Password strength indicator helps users

**Terms & Conditions Checkbox**
- Legal requirement in most jurisdictions
- Must be explicitly checked (not pre-checked)
- Link to full terms and privacy policy

### Optional but Recommended

**Full Name or Username**
- Personalizes the user experience
- Helps identify accounts
- Can be collected during registration or onboarding

**Password Confirmation**
- Prevents typos in passwords
- Improves user experience
- Reduces support requests

**Newsletter/Marketing Consent**
- Separate from terms & conditions
- Must be optional (GDPR requirement)
- Clear opt-in language

## HTML Registration Form Example

Let's start with a complete HTML registration form with validation:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>User Registration Form</title>
  <style>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    body {
      font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
      min-height: 100vh;
      display: flex;
      align-items: center;
      justify-content: center;
      padding: 20px;
    }

    .form-container {
      background: white;
      border-radius: 16px;
      box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3);
      padding: 40px;
      max-width: 500px;
      width: 100%;
    }

    .form-header {
      text-center;
      margin-bottom: 30px;
    }

    .form-header h1 {
      color: #333;
      font-size: 28px;
      margin-bottom: 8px;
    }

    .form-header p {
      color: #666;
      font-size: 15px;
    }

    .form-group {
      margin-bottom: 24px;
    }

    label {
      display: block;
      font-weight: 600;
      color: #333;
      margin-bottom: 8px;
      font-size: 14px;
    }

    .required {
      color: #e74c3c;
      margin-left: 4px;
    }

    input[type="text"],
    input[type="email"],
    input[type="password"] {
      width: 100%;
      padding: 12px 16px;
      border: 2px solid #e1e8ed;
      border-radius: 8px;
      font-size: 15px;
      font-family: inherit;
      transition: border-color 0.3s, box-shadow 0.3s;
    }

    input:focus {
      outline: none;
      border-color: #667eea;
      box-shadow: 0 0 0 3px rgba(102, 126, 234, 0.1);
    }

    input.error {
      border-color: #e74c3c;
    }

    .password-strength {
      height: 4px;
      background: #e1e8ed;
      border-radius: 2px;
      margin-top: 8px;
      overflow: hidden;
    }

    .password-strength-bar {
      height: 100%;
      transition: width 0.3s, background-color 0.3s;
      width: 0;
    }

    .password-strength-bar.weak {
      width: 33%;
      background-color: #e74c3c;
    }

    .password-strength-bar.medium {
      width: 66%;
      background-color: #f39c12;
    }

    .password-strength-bar.strong {
      width: 100%;
      background-color: #27ae60;
    }

    .password-hint {
      font-size: 12px;
      color: #666;
      margin-top: 6px;
    }

    .error-message {
      color: #e74c3c;
      font-size: 13px;
      margin-top: 6px;
      display: none;
    }

    .error-message.show {
      display: block;
    }

    .checkbox-group {
      display: flex;
      align-items: flex-start;
      gap: 8px;
      margin-bottom: 20px;
    }

    .checkbox-group input[type="checkbox"] {
      margin-top: 4px;
      width: 18px;
      height: 18px;
      cursor: pointer;
    }

    .checkbox-group label {
      margin: 0;
      font-weight: 400;
      font-size: 14px;
      cursor: pointer;
      user-select: none;
    }

    .checkbox-group a {
      color: #667eea;
      text-decoration: none;
    }

    .checkbox-group a:hover {
      text-decoration: underline;
    }

    button[type="submit"] {
      width: 100%;
      padding: 14px;
      background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
      color: white;
      border: none;
      border-radius: 8px;
      font-size: 16px;
      font-weight: 600;
      cursor: pointer;
      transition: transform 0.2s, box-shadow 0.2s;
    }

    button[type="submit"]:hover:not(:disabled) {
      transform: translateY(-2px);
      box-shadow: 0 10px 25px rgba(102, 126, 234, 0.3);
    }

    button[type="submit"]:disabled {
      opacity: 0.6;
      cursor: not-allowed;
    }

    .alert {
      padding: 16px;
      border-radius: 8px;
      margin-bottom: 24px;
      font-size: 14px;
    }

    .alert-success {
      background: #d4edda;
      border: 1px solid #c3e6cb;
      color: #155724;
    }

    .alert-error {
      background: #f8d7da;
      border: 1px solid #f5c6cb;
      color: #721c24;
    }

    .hidden {
      display: none !important;
    }

    .login-link {
      text-align: center;
      margin-top: 20px;
      color: #666;
      font-size: 14px;
    }

    .login-link a {
      color: #667eea;
      text-decoration: none;
      font-weight: 600;
    }

    .login-link a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <div class="form-container">
    <div class="form-header">
      <h1>Create Your Account</h1>
      <p>Join thousands of users already using our platform</p>
    </div>

    <div id="successMessage" class="alert alert-success hidden">
      ✅ Registration successful! Please check your email to verify your account.
    </div>

    <div id="errorMessage" class="alert alert-error hidden">
      ❌ Something went wrong. Please try again.
    </div>

    <form id="registrationForm">
      <div class="form-group">
        <label for="name">
          Full Name <span class="required">*</span>
        </label>
        <input
          type="text"
          id="name"
          name="name"
          required
          placeholder="John Doe"
        >
        <div class="error-message" id="nameError">Please enter your full name</div>
      </div>

      <div class="form-group">
        <label for="email">
          Email Address <span class="required">*</span>
        </label>
        <input
          type="email"
          id="email"
          name="email"
          required
          placeholder="john@example.com"
        >
        <div class="error-message" id="emailError">Please enter a valid email address</div>
      </div>

      <div class="form-group">
        <label for="password">
          Password <span class="required">*</span>
        </label>
        <input
          type="password"
          id="password"
          name="password"
          required
          placeholder="Create a strong password"
        >
        <div class="password-strength">
          <div class="password-strength-bar" id="strengthBar"></div>
        </div>
        <div class="password-hint">
          At least 8 characters with uppercase, lowercase, and numbers
        </div>
        <div class="error-message" id="passwordError">Password is too weak</div>
      </div>

      <div class="form-group">
        <label for="confirmPassword">
          Confirm Password <span class="required">*</span>
        </label>
        <input
          type="password"
          id="confirmPassword"
          name="confirmPassword"
          required
          placeholder="Re-enter your password"
        >
        <div class="error-message" id="confirmPasswordError">Passwords do not match</div>
      </div>

      <div class="checkbox-group">
        <input
          type="checkbox"
          id="terms"
          name="terms"
          required
        >
        <label for="terms">
          I agree to the <a href="/terms" target="_blank">Terms of Service</a> and <a href="/privacy" target="_blank">Privacy Policy</a> <span class="required">*</span>
        </label>
      </div>

      <div class="checkbox-group">
        <input
          type="checkbox"
          id="newsletter"
          name="newsletter"
        >
        <label for="newsletter">
          Send me product updates and occasional emails (optional)
        </label>
      </div>

      <button type="submit" id="submitBtn">
        Create Account
      </button>
    </form>

    <div class="login-link">
      Already have an account? <a href="/login">Sign in</a>
    </div>
  </div>

  <script>
    const form = document.getElementById('registrationForm');
    const passwordInput = document.getElementById('password');
    const confirmPasswordInput = document.getElementById('confirmPassword');
    const strengthBar = document.getElementById('strengthBar');
    const submitBtn = document.getElementById('submitBtn');
    const successMessage = document.getElementById('successMessage');
    const errorMessage = document.getElementById('errorMessage');

    // Password strength checker
    passwordInput.addEventListener('input', (e) => {
      const password = e.target.value;
      const strength = calculatePasswordStrength(password);

      strengthBar.className = 'password-strength-bar';

      if (strength === 0) {
        strengthBar.classList.remove('weak', 'medium', 'strong');
      } else if (strength <= 2) {
        strengthBar.classList.add('weak');
      } else if (strength <= 3) {
        strengthBar.classList.add('medium');
      } else {
        strengthBar.classList.add('strong');
      }
    });

    function calculatePasswordStrength(password) {
      let strength = 0;

      if (password.length >= 8) strength++;
      if (password.length >= 12) strength++;
      if (/[a-z]/.test(password) && /[A-Z]/.test(password)) strength++;
      if (/[0-9]/.test(password)) strength++;
      if (/[^a-zA-Z0-9]/.test(password)) strength++;

      return strength;
    }

    // Form validation
    form.addEventListener('submit', async (e) => {
      e.preventDefault();

      // Hide previous messages
      successMessage.classList.add('hidden');
      errorMessage.classList.add('hidden');

      // Clear previous errors
      document.querySelectorAll('.error-message').forEach(el => el.classList.remove('show'));
      document.querySelectorAll('input').forEach(el => el.classList.remove('error'));

      // Validate
      let isValid = true;

      // Name validation
      const name = document.getElementById('name').value.trim();
      if (name.length < 2) {
        showError('name', 'nameError');
        isValid = false;
      }

      // Email validation
      const email = document.getElementById('email').value;
      if (!validateEmail(email)) {
        showError('email', 'emailError');
        isValid = false;
      }

      // Password validation
      const password = passwordInput.value;
      if (calculatePasswordStrength(password) < 2) {
        showError('password', 'passwordError');
        isValid = false;
      }

      // Confirm password validation
      const confirmPassword = confirmPasswordInput.value;
      if (password !== confirmPassword) {
        showError('confirmPassword', 'confirmPasswordError');
        isValid = false;
      }

      // Terms validation
      if (!document.getElementById('terms').checked) {
        alert('Please accept the Terms of Service and Privacy Policy');
        isValid = false;
      }

      if (!isValid) return;

      // Disable submit button
      submitBtn.disabled = true;
      submitBtn.textContent = 'Creating Account...';

      try {
        const formData = new FormData(form);

        // Add Static Forms fields
        formData.append('apiKey', 'YOUR_API_KEY_HERE'); // Replace with your API key
        formData.append('subject', 'New User Registration');
        formData.append('replyTo', email);

        const response = await fetch('https://api.staticforms.dev/submit', {
          method: 'POST',
          body: formData
        });

        const result = await response.json();

        if (result.success) {
          successMessage.classList.remove('hidden');
          form.reset();
          strengthBar.className = 'password-strength-bar';

          // Scroll to success message
          successMessage.scrollIntoView({ behavior: 'smooth', block: 'center' });
        } else {
          throw new Error('Registration failed');
        }
      } catch (error) {
        errorMessage.classList.remove('hidden');
        console.error('Error:', error);
      } finally {
        submitBtn.disabled = false;
        submitBtn.textContent = 'Create Account';
      }
    });

    function showError(inputId, errorId) {
      document.getElementById(inputId).classList.add('error');
      document.getElementById(errorId).classList.add('show');
    }

    function validateEmail(email) {
      const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
      return re.test(email);
    }
  </script>
</body>
</html>
```

This complete HTML registration form includes:
- Real-time password strength indicator
- Form validation
- Professional styling
- Mobile-responsive design
- Clear error messages

## Adding Password Strength Validation

Strong password validation is critical for security. Here's a comprehensive validation function:

```javascript
function validatePasswordStrength(password) {
  const requirements = {
    minLength: password.length >= 8,
    maxLength: password.length <= 128,
    hasUppercase: /[A-Z]/.test(password),
    hasLowercase: /[a-z]/.test(password),
    hasNumber: /[0-9]/.test(password),
    hasSpecial: /[!@#$%^&*(),.?":{}|<>]/.test(password),
  };

  const score = Object.values(requirements).filter(Boolean).length;

  return {
    isValid: requirements.minLength && requirements.hasUppercase &&
             requirements.hasLowercase && requirements.hasNumber,
    score,
    requirements,
    strength: score <= 2 ? 'weak' : score <= 4 ? 'medium' : 'strong',
  };
}

// Usage
const validation = validatePasswordStrength('MyP@ssw0rd');
console.log(validation.isValid); // true
console.log(validation.strength); // 'strong'
```

### Best Practices for Password Validation

**Minimum Requirements:**
- At least 8 characters (12+ recommended)
- Mix of uppercase and lowercase letters
- At least one number
- At least one special character

**Avoid:**
- Maximum length restrictions (allow up to 128 characters)
- Overly complex rules that frustrate users
- Rejecting valid special characters
- Requiring frequent password changes

**Show Users:**
- Real-time password strength feedback
- Clear requirements before they start typing
- Specific feedback on what's missing

## Email Confirmation (Auto-Responder)

Static Forms can automatically send confirmation emails to users who register through your form. This provides immediate feedback and helps ensure they entered a valid email address.

To set up email confirmation:

1. Go to your Static Forms dashboard
2. Select your registration form
3. Enable the "Auto-Responder" feature
4. Customize your confirmation email template:

```text
Subject: Registration Received

Hi {name},

Thank you for registering! We've received your information and will be in touch soon.

Registration Details:
- Email: {email}
- Submitted: {timestamp}

Best regards,
The [Your App] Team
```

**Note:** Static Forms auto-responder sends a simple confirmation email. If you need advanced email verification workflows (with unique tokens, verification links, or backend validation), you'll need to implement a custom backend solution outside of Static Forms.

## React Registration Form Component

For React applications, here's a complete registration form with hooks:

```jsx
import React, { useState, useEffect } from 'react';
import './RegistrationForm.css';

function RegistrationForm() {
  const [formData, setFormData] = useState({
    name: '',
    email: '',
    password: '',
    confirmPassword: '',
    terms: false,
    newsletter: false,
  });

  const [errors, setErrors] = useState({});
  const [passwordStrength, setPasswordStrength] = useState(0);
  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  // Calculate password strength
  useEffect(() => {
    if (formData.password) {
      const strength = calculatePasswordStrength(formData.password);
      setPasswordStrength(strength);
    } else {
      setPasswordStrength(0);
    }
  }, [formData.password]);

  const calculatePasswordStrength = (password) => {
    let strength = 0;
    if (password.length >= 8) strength++;
    if (password.length >= 12) strength++;
    if (/[a-z]/.test(password) && /[A-Z]/.test(password)) strength++;
    if (/[0-9]/.test(password)) strength++;
    if (/[^a-zA-Z0-9]/.test(password)) strength++;
    return strength;
  };

  const validateForm = () => {
    const newErrors = {};

    if (formData.name.trim().length < 2) {
      newErrors.name = 'Please enter your full name';
    }

    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!emailRegex.test(formData.email)) {
      newErrors.email = 'Please enter a valid email address';
    }

    if (passwordStrength < 2) {
      newErrors.password = 'Password is too weak';
    }

    if (formData.password !== formData.confirmPassword) {
      newErrors.confirmPassword = 'Passwords do not match';
    }

    if (!formData.terms) {
      newErrors.terms = 'You must accept the terms and conditions';
    }

    setErrors(newErrors);
    return Object.keys(newErrors).length === 0;
  };

  const handleChange = (e) => {
    const { name, value, type, checked } = e.target;
    setFormData(prev => ({
      ...prev,
      [name]: type === 'checkbox' ? checked : value
    }));

    // Clear error when user starts typing
    if (errors[name]) {
      setErrors(prev => ({ ...prev, [name]: '' }));
    }
  };

  const handleSubmit = async (e) => {
    e.preventDefault();

    if (!validateForm()) return;

    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const submitData = new FormData();
      Object.keys(formData).forEach(key => {
        if (key !== 'confirmPassword') {
          submitData.append(key, formData[key]);
        }
      });

      submitData.append('apiKey', 'YOUR_API_KEY_HERE');
      submitData.append('subject', 'New User Registration');
      submitData.append('replyTo', formData.email);

      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: submitData,
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        setFormData({
          name: '',
          email: '',
          password: '',
          confirmPassword: '',
          terms: false,
          newsletter: false,
        });
      } else {
        throw new Error('Registration failed');
      }
    } catch (error) {
      setStatus({ submitting: false, submitted: false, error: true });
      console.error('Error:', error);
    }
  };

  const getStrengthClass = () => {
    if (passwordStrength === 0) return '';
    if (passwordStrength <= 2) return 'weak';
    if (passwordStrength <= 3) return 'medium';
    return 'strong';
  };

  return (
    <div className="registration-container">
      <div className="form-header">
        <h1>Create Your Account</h1>
        <p>Join thousands of users already using our platform</p>
      </div>

      {status.submitted && (
        <div className="alert alert-success">
          ✅ Registration successful! Please check your email to verify your account.
        </div>
      )}

      {status.error && (
        <div className="alert alert-error">
          ❌ Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit}>
        <div className="form-group">
          <label htmlFor="name">
            Full Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            className={errors.name ? 'error' : ''}
            required
            placeholder="John Doe"
          />
          {errors.name && <div className="error-message">{errors.name}</div>}
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email Address <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            className={errors.email ? 'error' : ''}
            required
            placeholder="john@example.com"
          />
          {errors.email && <div className="error-message">{errors.email}</div>}
        </div>

        <div className="form-group">
          <label htmlFor="password">
            Password <span className="required">*</span>
          </label>
          <input
            type="password"
            id="password"
            name="password"
            value={formData.password}
            onChange={handleChange}
            className={errors.password ? 'error' : ''}
            required
            placeholder="Create a strong password"
          />
          <div className="password-strength">
            <div className={`password-strength-bar ${getStrengthClass()}`}></div>
          </div>
          <div className="password-hint">
            At least 8 characters with uppercase, lowercase, and numbers
          </div>
          {errors.password && <div className="error-message">{errors.password}</div>}
        </div>

        <div className="form-group">
          <label htmlFor="confirmPassword">
            Confirm Password <span className="required">*</span>
          </label>
          <input
            type="password"
            id="confirmPassword"
            name="confirmPassword"
            value={formData.confirmPassword}
            onChange={handleChange}
            className={errors.confirmPassword ? 'error' : ''}
            required
            placeholder="Re-enter your password"
          />
          {errors.confirmPassword && <div className="error-message">{errors.confirmPassword}</div>}
        </div>

        <div className="checkbox-group">
          <input
            type="checkbox"
            id="terms"
            name="terms"
            checked={formData.terms}
            onChange={handleChange}
            required
          />
          <label htmlFor="terms">
            I agree to the <a href="/terms" target="_blank" rel="noopener noreferrer">Terms of Service</a> and <a href="/privacy" target="_blank" rel="noopener noreferrer">Privacy Policy</a> <span className="required">*</span>
          </label>
        </div>

        <div className="checkbox-group">
          <input
            type="checkbox"
            id="newsletter"
            name="newsletter"
            checked={formData.newsletter}
            onChange={handleChange}
          />
          <label htmlFor="newsletter">
            Send me product updates and occasional emails (optional)
          </label>
        </div>

        <button type="submit" disabled={status.submitting}>
          {status.submitting ? 'Creating Account...' : 'Create Account'}
        </button>
      </form>

      <div className="login-link">
        Already have an account? <a href="/login">Sign in</a>
      </div>
    </div>
  );
}

export default RegistrationForm;
```

## Vue.js Registration Form Example

For Vue.js applications (using Composition API):

```vue
<template>
  <div class="registration-container">
    <div class="form-header">
      <h1>Create Your Account</h1>
      <p>Join thousands of users already using our platform</p>
    </div>

    <div v-if="status.submitted" class="alert alert-success">
      ✅ Registration successful! Please check your email to verify your account.
    </div>

    <div v-if="status.error" class="alert alert-error">
      ❌ Something went wrong. Please try again.
    </div>

    <form @submit.prevent="handleSubmit">
      <div class="form-group">
        <label for="name">
          Full Name <span class="required">*</span>
        </label>
        <input
          type="text"
          id="name"
          v-model="formData.name"
          :class="{ error: errors.name }"
          required
          placeholder="John Doe"
        />
        <div v-if="errors.name" class="error-message">{{ errors.name }}</div>
      </div>

      <div class="form-group">
        <label for="email">
          Email Address <span class="required">*</span>
        </label>
        <input
          type="email"
          id="email"
          v-model="formData.email"
          :class="{ error: errors.email }"
          required
          placeholder="john@example.com"
        />
        <div v-if="errors.email" class="error-message">{{ errors.email }}</div>
      </div>

      <div class="form-group">
        <label for="password">
          Password <span class="required">*</span>
        </label>
        <input
          type="password"
          id="password"
          v-model="formData.password"
          :class="{ error: errors.password }"
          required
          placeholder="Create a strong password"
        />
        <div class="password-strength">
          <div
            class="password-strength-bar"
            :class="strengthClass"
          ></div>
        </div>
        <div class="password-hint">
          At least 8 characters with uppercase, lowercase, and numbers
        </div>
        <div v-if="errors.password" class="error-message">{{ errors.password }}</div>
      </div>

      <div class="form-group">
        <label for="confirmPassword">
          Confirm Password <span class="required">*</span>
        </label>
        <input
          type="password"
          id="confirmPassword"
          v-model="formData.confirmPassword"
          :class="{ error: errors.confirmPassword }"
          required
          placeholder="Re-enter your password"
        />
        <div v-if="errors.confirmPassword" class="error-message">{{ errors.confirmPassword }}</div>
      </div>

      <div class="checkbox-group">
        <input
          type="checkbox"
          id="terms"
          v-model="formData.terms"
          required
        />
        <label for="terms">
          I agree to the <a href="/terms" target="_blank">Terms of Service</a> and
          <a href="/privacy" target="_blank">Privacy Policy</a>
          <span class="required">*</span>
        </label>
      </div>

      <div class="checkbox-group">
        <input
          type="checkbox"
          id="newsletter"
          v-model="formData.newsletter"
        />
        <label for="newsletter">
          Send me product updates and occasional emails (optional)
        </label>
      </div>

      <button type="submit" :disabled="status.submitting">
        {{ status.submitting ? 'Creating Account...' : 'Create Account' }}
      </button>
    </form>

    <div class="login-link">
      Already have an account? <a href="/login">Sign in</a>
    </div>
  </div>
</template>

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

const formData = ref({
  name: '',
  email: '',
  password: '',
  confirmPassword: '',
  terms: false,
  newsletter: false,
});

const errors = ref({});
const passwordStrength = ref(0);
const status = ref({
  submitting: false,
  submitted: false,
  error: false,
});

// Calculate password strength
watch(() => formData.value.password, (newPassword) => {
  if (newPassword) {
    let strength = 0;
    if (newPassword.length >= 8) strength++;
    if (newPassword.length >= 12) strength++;
    if (/[a-z]/.test(newPassword) && /[A-Z]/.test(newPassword)) strength++;
    if (/[0-9]/.test(newPassword)) strength++;
    if (/[^a-zA-Z0-9]/.test(newPassword)) strength++;
    passwordStrength.value = strength;
  } else {
    passwordStrength.value = 0;
  }
});

const strengthClass = computed(() => {
  if (passwordStrength.value === 0) return '';
  if (passwordStrength.value <= 2) return 'weak';
  if (passwordStrength.value <= 3) return 'medium';
  return 'strong';
});

const validateForm = () => {
  const newErrors = {};

  if (formData.value.name.trim().length < 2) {
    newErrors.name = 'Please enter your full name';
  }

  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailRegex.test(formData.value.email)) {
    newErrors.email = 'Please enter a valid email address';
  }

  if (passwordStrength.value < 2) {
    newErrors.password = 'Password is too weak';
  }

  if (formData.value.password !== formData.value.confirmPassword) {
    newErrors.confirmPassword = 'Passwords do not match';
  }

  if (!formData.value.terms) {
    newErrors.terms = 'You must accept the terms and conditions';
  }

  errors.value = newErrors;
  return Object.keys(newErrors).length === 0;
};

const handleSubmit = async () => {
  if (!validateForm()) return;

  status.value = { submitting: true, submitted: false, error: false };

  try {
    const submitData = new FormData();
    Object.keys(formData.value).forEach(key => {
      if (key !== 'confirmPassword') {
        submitData.append(key, formData.value[key]);
      }
    });

    submitData.append('apiKey', 'YOUR_API_KEY_HERE');
    submitData.append('subject', 'New User Registration');
    submitData.append('replyTo', formData.value.email);

    const response = await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      body: submitData,
    });

    const result = await response.json();

    if (result.success) {
      status.value = { submitting: false, submitted: true, error: false };
      formData.value = {
        name: '',
        email: '',
        password: '',
        confirmPassword: '',
        terms: false,
        newsletter: false,
      };
    } else {
      throw new Error('Registration failed');
    }
  } catch (error) {
    status.value = { submitting: false, submitted: false, error: true };
    console.error('Error:', error);
  }
};
</script>
```

## Security Best Practices

### 1. Never Store Passwords in Plain Text
- Always hash passwords server-side
- Use bcrypt, Argon2, or similar
- Never send plain passwords via email

### 2. Implement Rate Limiting
- Limit registration attempts per IP
- Prevent automated bot registrations
- Use CAPTCHA for suspicious activity

### 3. Validate on Both Client and Server
- Client-side validation for UX
- Server-side validation for security
- Never trust client-side data

### 4. Use HTTPS Always
- Encrypt all data in transit
- Enable HSTS headers
- Use secure cookies

### 5. Implement CAPTCHA Protection

Add reCAPTCHA, or Altcha on the Starter plan and up, to prevent bot registrations:

```html
<!-- Altcha (privacy-first) -->
<script type="module" src="https://cdn.jsdelivr.net/npm/altcha/dist/altcha.min.js"></script>

<form>
  <!-- Your form fields -->

  <altcha-widget
    challengeurl="https://api.staticforms.dev/altcha/challenge"
    apikey="YOUR_API_KEY"
  ></altcha-widget>

  <button type="submit">Register</button>
</form>
```

## GDPR Compliance Considerations

When building registration forms for users in the EU, ensure GDPR compliance:

### 1. Clear Consent
- Separate consent for terms vs. marketing emails
- No pre-checked boxes for optional consents
- Clear, plain language explanations

### 2. Data Minimization
- Only collect necessary data
- Explain why each field is required
- Don't collect data "just in case"

### 3. Right to Access & Deletion
- Provide data export functionality
- Allow account deletion
- Honor deletion requests promptly

### 4. Privacy Policy
- Link to detailed privacy policy
- Explain data usage clearly
- List third parties with access

### 5. Secure Data Handling
- Encrypt data at rest and in transit
- Limit data access
- Regular security audits

## Getting Your Static Forms API Key

To use Static Forms with your registration form:

1. **Sign up for free** at [Static Forms](https://www.staticforms.dev)
2. **Create a new form** in your dashboard
3. **Copy your API key**
4. **Replace** `YOUR_API_KEY_HERE` in the code examples

### Using Environment Variables

**React/Next.js (.env.local)**:
```bash
NEXT_PUBLIC_STATICFORMS_KEY=your_api_key_here
```

**Vue.js (.env)**:
```bash
VUE_APP_STATICFORMS_KEY=your_api_key_here
```

Then use:
```javascript
process.env.NEXT_PUBLIC_STATICFORMS_KEY  // Next.js
process.env.VUE_APP_STATICFORMS_KEY      // Vue.js
```

## Common Issues & Solutions

### Password Validation Too Strict
**Problem**: Users struggle to create valid passwords

**Solution**:
- Show requirements clearly before they start
- Provide real-time feedback
- Allow paste functionality
- Consider passphrase support

### Email Verification Not Working
**Problem**: Users don't receive verification emails

**Solution**:
- Check spam folders
- Use recognizable sender name
- Send email immediately after registration
- Include resend option

### Terms Checkbox Not Visible
**Problem**: Users miss the terms checkbox

**Solution**:
- Make checkbox and label clearly visible
- Use adequate contrast
- Position prominently
- Block submission with clear error if unchecked

## Conclusion

You now have everything needed to build secure, user-friendly registration forms with email verification, password validation, and GDPR compliance. Whether you're using plain HTML, React, or Vue.js, these patterns will help you create professional registration experiences.

Static Forms handles all the backend complexity—email delivery, data storage, spam protection—so you can focus on building great user experiences.

## Next Steps

- [Sign up for Static Forms](https://www.staticforms.dev) (free tier available)
- [Learn about spam protection](/docs/spam-protection)
- [Configure auto-responders](/docs/auto-responders)
- [Build application forms](/blog/how-to-build-application-form)
- [Add Altcha CAPTCHA](/docs/altcha)

Ready to start collecting registrations? [Get started with Static Forms today](https://www.staticforms.dev) and have your registration form live in minutes.

---

## How to Add a Contact Form to GitHub Pages

Source: https://www.staticforms.dev/blog/github-pages-contact-form-tutorial  
Date: 2026-01-06  
Author: Static Forms Team

GitHub Pages is an excellent platform for hosting static websites - it's free, fast, and integrates seamlessly with your Git workflow. However, one common challenge developers face is adding a functional contact form since GitHub Pages doesn't support server-side processing. The good news? You can easily add a professional contact form to your GitHub Pages site without writing any backend code.

In this comprehensive guide, we'll show you how to implement a fully functional contact form on GitHub Pages using Static Forms, a form backend service that handles all the server-side logic for you. Your visitors will be able to send messages, and you'll receive them directly in your email inbox. Teaching this to a class? Our [guide for classrooms](/for/classrooms) has a 10-minute lesson plan and an instructor FAQ.

## Why GitHub Pages Needs a Form Solution

GitHub Pages serves only static files - HTML, CSS, and JavaScript. While this makes it incredibly fast and secure, it means you can't process form submissions directly. Traditional form handling requires:

- Server-side code to process submissions
- A database to store form data
- Email sending capabilities
- Spam protection mechanisms

Static Forms solves all of these challenges by providing a dedicated API endpoint that handles form submissions for you.

## Prerequisites

Before we begin, make sure you have:

- A GitHub Pages site (already deployed or ready to deploy)
- A Static Forms account - [sign up for free](https://www.staticforms.dev)
- Your API key from the [Static Forms dashboard](https://www.staticforms.dev/app/forms)

## Step 1: Create a Basic HTML Contact Form

Let's start with a simple contact form. Create a new file called `contact.html` in your GitHub Pages repository, or add this form to an existing page:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Us</title>
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
            max-width: 600px;
            margin: 50px auto;
            padding: 20px;
            background-color: #f5f5f5;
        }
        .contact-container {
            background: white;
            padding: 40px;
            border-radius: 8px;
            box-shadow: 0 2px 10px rgba(0,0,0,0.1);
        }
        h1 {
            color: #333;
            margin-bottom: 10px;
        }
        .subtitle {
            color: #666;
            margin-bottom: 30px;
        }
        .form-group {
            margin-bottom: 20px;
        }
        label {
            display: block;
            margin-bottom: 5px;
            color: #333;
            font-weight: 500;
        }
        input[type="text"],
        input[type="email"],
        textarea {
            width: 100%;
            padding: 12px;
            border: 1px solid #ddd;
            border-radius: 4px;
            font-size: 14px;
            box-sizing: border-box;
            transition: border-color 0.3s;
        }
        input:focus,
        textarea:focus {
            outline: none;
            border-color: #4A90E2;
        }
        textarea {
            resize: vertical;
            min-height: 120px;
        }
        button {
            background-color: #4A90E2;
            color: white;
            padding: 12px 30px;
            border: none;
            border-radius: 4px;
            font-size: 16px;
            cursor: pointer;
            transition: background-color 0.3s;
        }
        button:hover {
            background-color: #357ABD;
        }
        button:disabled {
            background-color: #ccc;
            cursor: not-allowed;
        }
        .alert {
            padding: 15px;
            border-radius: 4px;
            margin-bottom: 20px;
            display: none;
        }
        .alert.show {
            display: block;
        }
        .alert-success {
            background-color: #d4edda;
            color: #155724;
            border: 1px solid #c3e6cb;
        }
        .alert-error {
            background-color: #f8d7da;
            color: #721c24;
            border: 1px solid #f5c6cb;
        }
    </style>
</head>
<body>
    <div class="contact-container">
        <h1>Get in Touch</h1>
        <p class="subtitle">We'd love to hear from you. Send us a message and we'll respond as soon as possible.</p>

        <div id="alertBox" class="alert"></div>

        <form id="contactForm" action="https://api.staticforms.dev/submit" method="POST">
            <div class="form-group">
                <label for="name">Your Name *</label>
                <input type="text" id="name" name="name" required>
            </div>

            <div class="form-group">
                <label for="email">Your Email *</label>
                <input type="email" id="email" name="email" required>
            </div>

            <div class="form-group">
                <label for="subject">Subject</label>
                <input type="text" id="subject" name="subject" placeholder="What's this about?">
            </div>

            <div class="form-group">
                <label for="message">Message *</label>
                <textarea id="message" name="message" required placeholder="Tell us what's on your mind..."></textarea>
            </div>

            <!-- Static Forms Configuration -->
            <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
            <input type="hidden" name="replyTo" value="@">
            <input type="text" name="honeypot" style="display:none">

            <button type="submit" id="submitBtn">Send Message</button>
        </form>
    </div>

    <script>
        const form = document.getElementById('contactForm');
        const submitBtn = document.getElementById('submitBtn');
        const alertBox = document.getElementById('alertBox');

        form.addEventListener('submit', async function(e) {
            e.preventDefault();

            // Disable submit button
            submitBtn.disabled = true;
            submitBtn.textContent = 'Sending...';

            // Hide any previous alerts
            alertBox.classList.remove('show', 'alert-success', 'alert-error');

            try {
                const formData = new FormData(form);
                const data = Object.fromEntries(formData);

                const response = await fetch('https://api.staticforms.dev/submit', {
                    method: 'POST',
                    body: JSON.stringify(data),
                    headers: { 'Content-Type': 'application/json' }
                });

                const result = await response.json();

                if (result.success) {
                    // Show success message
                    alertBox.textContent = 'Thank you! Your message has been sent successfully. We\'ll get back to you soon.';
                    alertBox.classList.add('alert-success', 'show');

                    // Reset form
                    form.reset();
                } else {
                    throw new Error(result.message || 'Something went wrong');
                }
            } catch (error) {
                // Show error message
                alertBox.textContent = 'Oops! Something went wrong. Please try again.';
                alertBox.classList.add('alert-error', 'show');
            } finally {
                // Re-enable submit button
                submitBtn.disabled = false;
                submitBtn.textContent = 'Send Message';
            }
        });
    </script>
</body>
</html>
```

**Important**: Replace `YOUR_API_KEY_HERE` with your actual API key from your Static Forms dashboard.

## Step 2: Understanding the Form Configuration

Let's break down the key parts of the form:

### The Action Attribute
```html
<form action="https://api.staticforms.dev/submit" method="POST">
```
This points to the Static Forms API endpoint that will handle your submissions.

### Required Hidden Fields
```html
<input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
```
Your API key authenticates your form with Static Forms.

### Optional Configuration Fields
```html
<input type="hidden" name="replyTo" value="@">
```
The `@` value tells Static Forms to use the email address from the form's email field as the reply-to address, making it easy to respond to messages.

### Honeypot Spam Protection
```html
<input type="text" name="honeypot" style="display:none">
```
This hidden field catches bots that automatically fill out all form fields. Legitimate users won't see or fill this field.

## Step 3: Add reCAPTCHA Protection (Optional)

For additional spam protection, you can add Google reCAPTCHA. First, get your reCAPTCHA keys from the [Google reCAPTCHA Admin Console](https://www.google.com/recaptcha/admin).

Add the reCAPTCHA script to your `<head>`:

```html
<head>
    <!-- Other head elements -->
    <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>
```

Then add the reCAPTCHA widget to your form:

```html
<div class="form-group">
    <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
</div>
```

Don't forget to configure your reCAPTCHA secret key in your [Static Forms CAPTCHA settings](https://www.staticforms.dev/app/forms).

For more details on implementing reCAPTCHA, check out our [understanding reCAPTCHA guide](/blog/understanding-recaptcha).

## Step 4: Deploy to GitHub Pages

Now let's deploy your contact form to GitHub Pages:

1. **Commit your changes**:
```bash
git add contact.html
git commit -m "Add contact form with Static Forms integration"
```

2. **Push to GitHub**:
```bash
git push origin main
```

3. **Wait for deployment**: GitHub Pages automatically deploys your changes. This usually takes 1-2 minutes.

4. **Test your form**: Visit `https://yourusername.github.io/yourrepo/contact.html` and submit a test message.

## Step 5: Customize Your Form

### Custom Success Redirect

Instead of showing a success message on the same page, you can redirect users to a thank-you page:

```html
<input type="hidden" name="redirectTo" value="https://yourusername.github.io/yourrepo/thank-you.html">
```

Create a `thank-you.html` page:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Thank You</title>
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            min-height: 100vh;
            margin: 0;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
        }
        .thank-you-container {
            text-align: center;
            background: white;
            padding: 60px 40px;
            border-radius: 10px;
            box-shadow: 0 10px 40px rgba(0,0,0,0.2);
        }
        h1 {
            color: #333;
            margin-bottom: 20px;
        }
        p {
            color: #666;
            font-size: 18px;
            margin-bottom: 30px;
        }
        a {
            display: inline-block;
            padding: 12px 30px;
            background-color: #4A90E2;
            color: white;
            text-decoration: none;
            border-radius: 4px;
            transition: background-color 0.3s;
        }
        a:hover {
            background-color: #357ABD;
        }
    </style>
</head>
<body>
    <div class="thank-you-container">
        <h1>✅ Message Sent!</h1>
        <p>Thank you for contacting us. We'll get back to you as soon as possible.</p>
        <a href="/">Return to Home</a>
    </div>
</body>
</html>
```

### Custom Email Subject

Set a custom subject line for better organization:

```html
<input type="hidden" name="subject" value="New Contact from GitHub Pages Site">
```

Or use a visible subject field (as shown in the main example) to let users set their own subject.

## Advanced Features

### File Attachments

Allow users to upload files with their messages (available from the Starter plan up):

```html
<div class="form-group">
    <label for="attachment">Attach File (Optional)</label>
    <input type="file" id="attachment" name="attachment" accept=".pdf,.doc,.docx,.jpg,.png">
</div>
```

Note: File uploads require encoding the form as `multipart/form-data`. See our [file uploads guide](/blog/nextjs-contact-form-document-upload) for implementation details.

### Custom Fields

Add custom fields by prefixing the name with `$`:

```html
<div class="form-group">
    <label for="company">Company Name</label>
    <input type="text" id="company" name="$company">
</div>
```

### Webhook Integration

For advanced workflows, you can connect your form to other services using webhooks, available from the Starter plan up ($6/month, or $4/month billed annually). This allows you to:

- Send submissions to Slack, Telegram, or Discord
- Add contacts to your CRM
- Trigger automation workflows
- Sync submissions to Google Sheets, Notion, Airtable, or Mailchimp (Pro and Agency only)

Configure webhooks in your [Static Forms dashboard](https://www.staticforms.dev/app/forms).

## Complete Working Example

Here's a complete, copy-paste-ready contact form for GitHub Pages:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact - My GitHub Pages Site</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <nav>
        <a href="/">Home</a>
        <a href="/about.html">About</a>
        <a href="/contact.html">Contact</a>
    </nav>

    <main>
        <section class="contact-section">
            <h1>Contact Us</h1>
            <p>Have a question or want to work together? Drop us a message!</p>

            <form action="https://api.staticforms.dev/submit" method="POST" id="contactForm">
                <input type="text" name="name" placeholder="Your Name" required>
                <input type="email" name="email" placeholder="Your Email" required>
                <input type="text" name="subject" placeholder="Subject">
                <textarea name="message" placeholder="Your Message" required></textarea>

                <!-- Static Forms Configuration -->
                <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
                <input type="hidden" name="replyTo" value="@">
                <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">

                <button type="submit">Send Message</button>
            </form>
        </section>
    </main>
</body>
</html>
```

## Troubleshooting Common Issues

### Not Receiving Email Notifications

If you're not receiving form submissions:

- ✅ Verify your API key is correct in the form
- ✅ Check your spam/junk folder
- ✅ Confirm your email is verified in Static Forms
- ✅ Test with different email addresses

### Form Submission Fails

If submissions aren't working:

- ✅ Check the browser console for JavaScript errors
- ✅ Ensure the API endpoint URL is correct: `https://api.staticforms.dev/submit`
- ✅ Verify all required fields have the `required` attribute
- ✅ Make sure the honeypot field is properly hidden

### CORS Errors

If you see CORS-related errors:

- ✅ Use HTTPS for your GitHub Pages site (enable in repository settings)
- ✅ Ensure you're using JSON format when submitting via JavaScript
- ✅ Include proper `Content-Type` header: `application/json`

## Best Practices for GitHub Pages Forms

1. **Keep it simple** - Only ask for information you actually need
2. **Validate inputs** - Use HTML5 validation and JavaScript for better UX
3. **Provide feedback** - Show loading states and confirmation messages
4. **Mobile-friendly** - Ensure your form works well on all devices
5. **Test thoroughly** - Submit test forms before going live

## Conclusion

Adding a contact form to your GitHub Pages site doesn't have to be complicated. With Static Forms, you can implement a professional contact form in minutes without any backend code or complex infrastructure.

Your form will handle submissions reliably, protect against spam with built-in security features, and deliver messages straight to your inbox - all while keeping your GitHub Pages site completely static.

Ready to add a contact form to your GitHub Pages site? [Sign up for Static Forms](https://www.staticforms.dev) and get started today with our free tier!

For more integration examples, check out our guides for [Next.js](/blog/using-staticforms-with-nextjs), [Gatsby](/blog/using-staticforms-with-gatsby), and [Nuxt.js](/blog/using-staticforms-with-nuxtjs).

---

## HTML Form That Sends Email Without Server (2026)

Source: https://www.staticforms.dev/blog/html-form-send-email-without-server  
Date: 2026-01-06  
Author: Static Forms Team

One of the most common questions beginners ask is: "How can I create an HTML form that sends emails without a server?" The traditional answer involves PHP scripts, Node.js backends, or complex server configurations. But in 2026, there's a much simpler solution that doesn't require any server-side programming knowledge.

In this comprehensive guide, you'll learn how to create a fully functional HTML contact form that sends emails directly to your inbox using Static Forms - a free form backend service. No PHP, no Node.js, no server setup required. Just pure HTML and a few lines of JavaScript for better user experience.

Whether you're building your first website, creating a portfolio, or adding a contact form to a landing page, this guide will walk you through everything step by step. If you teach HTML, see [Static Forms for classrooms](/for/classrooms) for a lesson plan built on the same form.

> **Prefer a working project?** The [complete HTML example](https://github.com/static-forms/static-forms-examples/tree/main/apps/html-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## Why Traditional Methods Are Complicated

Before we dive into the simple solution, let's understand why this used to be difficult:

### The Old Way: PHP Mail Scripts
```php
// This requires a PHP-enabled server
<?php
mail($_POST['email'], 'Subject', $_POST['message']);
?>
```
**Problems**: Requires PHP hosting, vulnerable to spam, often blocked by servers, needs SMTP configuration.

### The Old Way: Node.js Backend
```javascript
// This requires running a Node.js server
const nodemailer = require('nodemailer');
// ...dozens of lines of configuration
```
**Problems**: Requires server hosting, complex setup, ongoing maintenance, security concerns.

### The Simple Modern Way
```html
<!-- Just point your form to a form backend service -->
<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Your form fields -->
</form>
```
**Benefits**: ✅ No server required, ✅ No coding knowledge needed, ✅ Works immediately, ✅ Built-in spam protection.

## What You'll Need

Before we start, make sure you have:

- A text editor (VS Code, Sublime Text, or even Notepad)
- A Static Forms account - [sign up free here](https://www.staticforms.dev)
- Your API key from the [dashboard](https://www.staticforms.dev/app/forms)
- A web browser for testing

That's it! No server, no hosting requirements, no complex installations.

## Step 1: Create Your Basic HTML Form

Let's start with the simplest possible contact form. Create a new file called `contact.html`:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form</title>
</head>
<body>
    <h1>Contact Us</h1>

    <form action="https://api.staticforms.dev/submit" method="POST">
        <label for="name">Name:</label>
        <input type="text" id="name" name="name" required>
        <br><br>

        <label for="email">Email:</label>
        <input type="email" id="email" name="email" required>
        <br><br>

        <label for="message">Message:</label>
        <textarea id="message" name="message" required></textarea>
        <br><br>

        <!-- Replace YOUR_API_KEY_HERE with your actual API key -->
        <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">

        <button type="submit">Send Email</button>
    </form>
</body>
</html>
```

**That's it!** Open this file in your browser and test it. When someone submits the form, you'll receive the message in your email inbox.

### How It Works

1. The `action` attribute points to Static Forms' API endpoint
2. The `method="POST"` sends the data securely
3. The hidden `apiKey` field tells Static Forms where to send the email
4. Your form fields (`name`, `email`, `message`) are included in the email

## Step 2: Style Your Form

Let's make it look professional with some CSS:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form - Send Email</title>
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            min-height: 100vh;
            display: flex;
            justify-content: center;
            align-items: center;
            padding: 20px;
        }

        .container {
            background: white;
            padding: 40px;
            border-radius: 10px;
            box-shadow: 0 10px 40px rgba(0,0,0,0.2);
            max-width: 500px;
            width: 100%;
        }

        h1 {
            color: #333;
            margin-bottom: 10px;
            font-size: 28px;
        }

        .subtitle {
            color: #666;
            margin-bottom: 30px;
            font-size: 14px;
        }

        .form-group {
            margin-bottom: 20px;
        }

        label {
            display: block;
            margin-bottom: 8px;
            color: #333;
            font-weight: 600;
            font-size: 14px;
        }

        input[type="text"],
        input[type="email"],
        textarea {
            width: 100%;
            padding: 12px 15px;
            border: 2px solid #e0e0e0;
            border-radius: 5px;
            font-size: 14px;
            font-family: inherit;
            transition: border-color 0.3s;
        }

        input:focus,
        textarea:focus {
            outline: none;
            border-color: #667eea;
        }

        textarea {
            resize: vertical;
            min-height: 120px;
        }

        button {
            width: 100%;
            padding: 14px;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            color: white;
            border: none;
            border-radius: 5px;
            font-size: 16px;
            font-weight: 600;
            cursor: pointer;
            transition: transform 0.2s, box-shadow 0.2s;
        }

        button:hover {
            transform: translateY(-2px);
            box-shadow: 0 5px 15px rgba(102, 126, 234, 0.4);
        }

        button:active {
            transform: translateY(0);
        }

        .required {
            color: #e74c3c;
        }
    </style>
</head>
<body>
    <div class="container">
        <h1>Get in Touch</h1>
        <p class="subtitle">Fill out the form below and we'll get back to you shortly.</p>

        <form action="https://api.staticforms.dev/submit" method="POST">
            <div class="form-group">
                <label for="name">Your Name <span class="required">*</span></label>
                <input type="text" id="name" name="name" placeholder="John Doe" required>
            </div>

            <div class="form-group">
                <label for="email">Your Email <span class="required">*</span></label>
                <input type="email" id="email" name="email" placeholder="john@example.com" required>
            </div>

            <div class="form-group">
                <label for="message">Your Message <span class="required">*</span></label>
                <textarea id="message" name="message" placeholder="Tell us what's on your mind..." required></textarea>
            </div>

            <!-- Configuration -->
            <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
            <input type="hidden" name="replyTo" value="@">

            <button type="submit">Send Email</button>
        </form>
    </div>
</body>
</html>
```

Now your form looks professional and modern! 🎨

## Step 3: Add User Feedback with JavaScript

Let's enhance the user experience by showing a success message without leaving the page:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form - Send Email</title>
    <style>
        /* Include all the CSS from Step 2 */
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            min-height: 100vh;
            display: flex;
            justify-content: center;
            align-items: center;
            padding: 20px;
        }

        .container {
            background: white;
            padding: 40px;
            border-radius: 10px;
            box-shadow: 0 10px 40px rgba(0,0,0,0.2);
            max-width: 500px;
            width: 100%;
        }

        h1 {
            color: #333;
            margin-bottom: 10px;
            font-size: 28px;
        }

        .subtitle {
            color: #666;
            margin-bottom: 30px;
            font-size: 14px;
        }

        .form-group {
            margin-bottom: 20px;
        }

        label {
            display: block;
            margin-bottom: 8px;
            color: #333;
            font-weight: 600;
            font-size: 14px;
        }

        input[type="text"],
        input[type="email"],
        textarea {
            width: 100%;
            padding: 12px 15px;
            border: 2px solid #e0e0e0;
            border-radius: 5px;
            font-size: 14px;
            font-family: inherit;
            transition: border-color 0.3s;
        }

        input:focus,
        textarea:focus {
            outline: none;
            border-color: #667eea;
        }

        textarea {
            resize: vertical;
            min-height: 120px;
        }

        button {
            width: 100%;
            padding: 14px;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            color: white;
            border: none;
            border-radius: 5px;
            font-size: 16px;
            font-weight: 600;
            cursor: pointer;
            transition: transform 0.2s, box-shadow 0.2s;
        }

        button:hover {
            transform: translateY(-2px);
            box-shadow: 0 5px 15px rgba(102, 126, 234, 0.4);
        }

        button:active {
            transform: translateY(0);
        }

        button:disabled {
            background: #ccc;
            cursor: not-allowed;
            transform: none;
        }

        .required {
            color: #e74c3c;
        }

        /* Alert styles */
        .alert {
            padding: 15px;
            border-radius: 5px;
            margin-bottom: 20px;
            display: none;
            animation: slideIn 0.3s ease;
        }

        .alert.show {
            display: block;
        }

        .alert-success {
            background-color: #d4edda;
            color: #155724;
            border: 1px solid #c3e6cb;
        }

        .alert-error {
            background-color: #f8d7da;
            color: #721c24;
            border: 1px solid #f5c6cb;
        }

        @keyframes slideIn {
            from {
                opacity: 0;
                transform: translateY(-10px);
            }
            to {
                opacity: 1;
                transform: translateY(0);
            }
        }
    </style>
</head>
<body>
    <div class="container">
        <h1>Get in Touch</h1>
        <p class="subtitle">Fill out the form below and we'll get back to you shortly.</p>

        <!-- Alert message -->
        <div id="alertMessage" class="alert"></div>

        <form id="contactForm">
            <div class="form-group">
                <label for="name">Your Name <span class="required">*</span></label>
                <input type="text" id="name" name="name" placeholder="John Doe" required>
            </div>

            <div class="form-group">
                <label for="email">Your Email <span class="required">*</span></label>
                <input type="email" id="email" name="email" placeholder="john@example.com" required>
            </div>

            <div class="form-group">
                <label for="message">Your Message <span class="required">*</span></label>
                <textarea id="message" name="message" placeholder="Tell us what's on your mind..." required></textarea>
            </div>

            <!-- Configuration (these won't be visible to users) -->
            <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
            <input type="hidden" name="replyTo" value="@">
            <input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">

            <button type="submit" id="submitButton">Send Email</button>
        </form>
    </div>

    <script>
        const form = document.getElementById('contactForm');
        const submitButton = document.getElementById('submitButton');
        const alertMessage = document.getElementById('alertMessage');

        form.addEventListener('submit', async function(e) {
            e.preventDefault();

            // Show loading state
            submitButton.disabled = true;
            submitButton.textContent = 'Sending...';

            // Hide previous alerts
            alertMessage.classList.remove('show', 'alert-success', 'alert-error');

            // Get form data
            const formData = new FormData(form);
            const data = Object.fromEntries(formData);

            try {
                // Send to Static Forms
                const response = await fetch('https://api.staticforms.dev/submit', {
                    method: 'POST',
                    body: JSON.stringify(data),
                    headers: {
                        'Content-Type': 'application/json'
                    }
                });

                const result = await response.json();

                if (result.success) {
                    // Show success message
                    alertMessage.textContent = '✅ Success! Your message has been sent. We\'ll get back to you soon!';
                    alertMessage.classList.add('alert-success', 'show');

                    // Reset the form
                    form.reset();
                } else {
                    throw new Error(result.message || 'Failed to send message');
                }
            } catch (error) {
                // Show error message
                alertMessage.textContent = '❌ Oops! Something went wrong. Please try again.';
                alertMessage.classList.add('alert-error', 'show');
                console.error('Form submission error:', error);
            } finally {
                // Reset button
                submitButton.disabled = false;
                submitButton.textContent = 'Send Email';
            }
        });
    </script>
</body>
</html>
```

**Perfect!** Now your form provides instant feedback when emails are sent. ✅

## Step 4: Add Spam Protection

Protect your form from spam with these built-in features:

### Honeypot Field (Already Included)
```html
<input type="text" name="honeypot" style="display:none" tabindex="-1" autocomplete="off">
```
This invisible field catches bots. Human users won't see it, but bots will fill it out, identifying themselves.

### Add reCAPTCHA for Extra Protection

Include Google reCAPTCHA for stronger spam protection:

1. Get your reCAPTCHA keys from [Google reCAPTCHA Admin](https://www.google.com/recaptcha/admin)

2. Add the script to your `<head>`:
```html
<script src="https://www.google.com/recaptcha/api.js" async defer></script>
```

3. Add the widget to your form:
```html
<div class="form-group">
    <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
</div>
```

4. Configure the secret key in your [Static Forms settings](https://www.staticforms.dev/app/forms)

For a complete reCAPTCHA guide, see our [understanding reCAPTCHA tutorial](/blog/understanding-recaptcha).

## Advanced Features

### Custom Email Subject Line

Set a custom subject for better email organization:

```html
<input type="hidden" name="subject" value="New Contact from Website">
```

Or let users set their own subject:

```html
<div class="form-group">
    <label for="subject">Subject</label>
    <input type="text" id="subject" name="subject" placeholder="What's this about?">
</div>
```

### Reply-To Configuration

The `replyTo` field determines where replies go:

```html
<!-- Use the sender's email as reply-to -->
<input type="hidden" name="replyTo" value="@">

<!-- Use a specific email -->
<input type="hidden" name="replyTo" value="support@yourcompany.com">
```

### Redirect After Submission

Send users to a thank-you page instead of showing a message:

```html
<input type="hidden" name="redirectTo" value="https://yourwebsite.com/thank-you.html">
```

### File Attachments

Allow users to upload files (available from the Starter plan up):

```html
<div class="form-group">
    <label for="attachment">Attach File (Optional)</label>
    <input type="file" id="attachment" name="attachment" accept=".pdf,.doc,.docx,.jpg,.png">
</div>
```

Note: File uploads require additional setup. See our [file upload tutorial](/blog/nextjs-contact-form-document-upload) for details.

## Common Questions

### Do I need to install anything on my server?

No! Static Forms handles everything. You just need to add HTML to your website.

### Will this work on any hosting provider?

Yes! It works on:
- ✅ GitHub Pages
- ✅ Netlify
- ✅ Vercel
- ✅ Traditional hosting (cPanel, etc.)
- ✅ Any hosting that serves HTML files

### Is it really free?

Yes! Static Forms offers a generous free tier perfect for personal websites and small businesses. Premium features are available for larger projects.

### How do I prevent spam?

Use the built-in honeypot field (included in our examples) and optionally add reCAPTCHA for extra protection.

### Can I customize the email content?

The email will include all form fields. You can customize which fields appear by adding or removing form inputs.

### What if I need more advanced features?

Paid Static Forms plans start at $6/month (or $4/month billed annually) on Starter, which adds:
- Webhook integrations (send data to other services)
- Higher submission limits
- File upload support
- Altcha CAPTCHA (privacy-focused alternative to reCAPTCHA)
- AI Reply and auto-responder emails
- Priority email support

Pro adds Google Sheets, Notion, Airtable and Mailchimp sync, conditional form rules, a custom sending domain, and 25,000 submissions a month.

## Troubleshooting

### Emails not arriving?

- ✅ Check your spam/junk folder
- ✅ Verify your API key is correct
- ✅ Confirm your email is verified with Static Forms
- ✅ Check the browser console for errors

### Form not submitting?

- ✅ Make sure you replaced `YOUR_API_KEY_HERE` with your actual API key
- ✅ Check that the form action URL is correct: `https://api.staticforms.dev/submit`
- ✅ Verify required fields are filled out
- ✅ Look for JavaScript errors in the browser console

### Getting a CORS error?

- ✅ Use the JavaScript fetch method (as shown in Step 3)
- ✅ Include the `Content-Type: application/json` header
- ✅ Make sure you're sending JSON data, not FormData

## Complete Copy-Paste Solution

Here's the complete, production-ready code you can copy and paste:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form</title>
    <style>
        body{font-family:Arial,sans-serif;background:#f4f4f4;padding:20px}
        .container{max-width:500px;margin:0 auto;background:white;padding:30px;border-radius:8px;box-shadow:0 2px 10px rgba(0,0,0,0.1)}
        h1{color:#333;margin-bottom:20px}
        .form-group{margin-bottom:15px}
        label{display:block;margin-bottom:5px;color:#333;font-weight:600}
        input,textarea{width:100%;padding:10px;border:1px solid #ddd;border-radius:4px;font-size:14px}
        textarea{min-height:100px;resize:vertical}
        button{width:100%;padding:12px;background:#4A90E2;color:white;border:none;border-radius:4px;font-size:16px;cursor:pointer}
        button:hover{background:#357ABD}
        button:disabled{background:#ccc;cursor:not-allowed}
        .alert{padding:10px;border-radius:4px;margin-bottom:15px;display:none}
        .alert.show{display:block}
        .alert-success{background:#d4edda;color:#155724}
        .alert-error{background:#f8d7da;color:#721c24}
    </style>
</head>
<body>
    <div class="container">
        <h1>Contact Us</h1>
        <div id="alert" class="alert"></div>
        <form id="form">
            <div class="form-group">
                <label>Name *</label>
                <input type="text" name="name" required>
            </div>
            <div class="form-group">
                <label>Email *</label>
                <input type="email" name="email" required>
            </div>
            <div class="form-group">
                <label>Message *</label>
                <textarea name="message" required></textarea>
            </div>
            <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
            <input type="hidden" name="replyTo" value="@">
            <input type="text" name="honeypot" style="display:none">
            <button type="submit" id="btn">Send Email</button>
        </form>
    </div>
    <script>
        const f=document.getElementById('form'),b=document.getElementById('btn'),a=document.getElementById('alert');
        f.addEventListener('submit',async e=>{
            e.preventDefault();
            b.disabled=true;
            b.textContent='Sending...';
            a.className='alert';
            try{
                const r=await fetch('https://api.staticforms.dev/submit',{
                    method:'POST',
                    body:JSON.stringify(Object.fromEntries(new FormData(f))),
                    headers:{'Content-Type':'application/json'}
                });
                const j=await r.json();
                if(j.success){
                    a.textContent='✅ Message sent successfully!';
                    a.className='alert alert-success show';
                    f.reset();
                }else throw new Error();
            }catch(e){
                a.textContent='❌ Error sending message. Please try again.';
                a.className='alert alert-error show';
            }finally{
                b.disabled=false;
                b.textContent='Send Email';
            }
        });
    </script>
</body>
</html>
```

**Just replace `YOUR_API_KEY_HERE` and you're done!**

## Conclusion

Creating an HTML form that sends emails without a server is now incredibly simple. With Static Forms, you can:

- ✅ Set up a working contact form in under 5 minutes
- ✅ Receive emails directly in your inbox
- ✅ No PHP, Node.js, or server configuration needed
- ✅ Built-in spam protection
- ✅ Works on any hosting platform
- ✅ Completely free for personal use

Whether you're a beginner building your first website or an experienced developer looking for a simple solution, Static Forms eliminates the complexity of form handling.

Ready to add email functionality to your HTML forms? [Sign up for Static Forms](https://www.staticforms.dev) and start receiving submissions in minutes!

For more tutorials, check out our guides on [GitHub Pages integration](/blog/github-pages-contact-form-tutorial), [Next.js forms](/blog/using-staticforms-with-nextjs), and [Gatsby forms](/blog/using-staticforms-with-gatsby).

---

## React Contact Form with Email (No Backend Required)

Source: https://www.staticforms.dev/blog/react-contact-form-email-tutorial  
Date: 2026-01-06  
Author: Static Forms Team

Building a contact form in React is straightforward, but sending those form submissions to your email typically requires backend infrastructure. What if you could handle form submissions and receive emails without setting up a Node.js server, configuring SMTP, or managing databases?

In this comprehensive tutorial, you'll learn how to create a production-ready React contact form that sends emails directly to your inbox using Static Forms - no backend code required. We'll use modern React patterns including hooks, implement form validation, add loading states, and include spam protection.

Whether you're building a portfolio, a business website, or any React application that needs a contact form, this guide provides everything you need to implement email functionality in minutes.

> **Prefer a working project?** The [complete React example](https://github.com/static-forms/static-forms-examples/tree/main/apps/react-example) (plus a [React Router version](https://github.com/static-forms/static-forms-examples/tree/main/apps/react-router-example)) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## What You'll Build

By the end of this tutorial, you'll have a React contact form with:

- ✅ Modern React hooks (useState, useCallback)
- ✅ Form validation with error messages
- ✅ Loading states and user feedback
- ✅ Email notifications to your inbox
- ✅ Spam protection (honeypot + optional reCAPTCHA)
- ✅ Responsive design
- ✅ Accessible markup

## Prerequisites

Before starting, make sure you have:

- Basic knowledge of React and JavaScript
- Node.js and npm installed
- A React app created (via Create React App, Vite, or similar)
- A Static Forms account - [sign up free](https://www.staticforms.dev)
- Your API key from the [dashboard](https://www.staticforms.dev/app/forms)

## Step 1: Create the Basic Contact Form Component

Let's start by creating a new component called `ContactForm.js`:

```jsx
import React, { useState } from 'react';
import './ContactForm.css';

function ContactForm() {
  const [formData, setFormData] = useState({
    name: '',
    email: '',
    subject: '',
    message: '',
  });

  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData(prev => ({
      ...prev,
      [name]: value
    }));
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          ...formData,
          apiKey: 'YOUR_API_KEY_HERE', // Replace with your API key
          replyTo: formData.email,
        }),
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        setFormData({ name: '', email: '', subject: '', message: '' });
      } else {
        throw new Error('Form submission failed');
      }
    } catch (error) {
      setStatus({ submitting: false, submitted: false, error: true });
    }
  };

  return (
    <div className="contact-form-container">
      <h2>Get in Touch</h2>
      <p className="subtitle">
        Have a question or want to work together? Send us a message!
      </p>

      {status.submitted && (
        <div className="alert alert-success">
          ✅ Thank you! Your message has been sent successfully. We'll get back to you soon.
        </div>
      )}

      {status.error && (
        <div className="alert alert-error">
          ❌ Oops! Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form">
        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            required
            placeholder="Your name"
          />
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            required
            placeholder="your.email@example.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="subject">Subject</label>
          <input
            type="text"
            id="subject"
            name="subject"
            value={formData.subject}
            onChange={handleChange}
            placeholder="What's this about?"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            required
            rows="5"
            placeholder="Tell us what's on your mind..."
          />
        </div>

        <button
          type="submit"
          disabled={status.submitting}
          className="submit-button"
        >
          {status.submitting ? 'Sending...' : 'Send Message'}
        </button>
      </form>
    </div>
  );
}

export default ContactForm;
```

## Step 2: Add Styling

Create `ContactForm.css` for a professional look:

```css
.contact-form-container {
  max-width: 600px;
  margin: 0 auto;
  padding: 40px 20px;
}

.contact-form-container h2 {
  color: #333;
  margin-bottom: 10px;
  font-size: 28px;
}

.subtitle {
  color: #666;
  margin-bottom: 30px;
  font-size: 16px;
}

.contact-form {
  background: #fff;
  padding: 30px;
  border-radius: 8px;
  box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
}

.form-group {
  margin-bottom: 20px;
}

.form-group label {
  display: block;
  margin-bottom: 8px;
  color: #333;
  font-weight: 600;
  font-size: 14px;
}

.required {
  color: #e74c3c;
}

.form-group input,
.form-group textarea {
  width: 100%;
  padding: 12px 15px;
  border: 2px solid #e0e0e0;
  border-radius: 5px;
  font-size: 14px;
  font-family: inherit;
  transition: border-color 0.3s;
}

.form-group input:focus,
.form-group textarea:focus {
  outline: none;
  border-color: #4A90E2;
}

.form-group textarea {
  resize: vertical;
  min-height: 120px;
}

.submit-button {
  width: 100%;
  padding: 14px;
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  color: white;
  border: none;
  border-radius: 5px;
  font-size: 16px;
  font-weight: 600;
  cursor: pointer;
  transition: transform 0.2s, box-shadow 0.2s;
}

.submit-button:hover:not(:disabled) {
  transform: translateY(-2px);
  box-shadow: 0 5px 15px rgba(102, 126, 234, 0.4);
}

.submit-button:disabled {
  background: #ccc;
  cursor: not-allowed;
  transform: none;
}

.alert {
  padding: 15px;
  border-radius: 5px;
  margin-bottom: 20px;
  animation: slideIn 0.3s ease;
}

.alert-success {
  background-color: #d4edda;
  color: #155724;
  border: 1px solid #c3e6cb;
}

.alert-error {
  background-color: #f8d7da;
  color: #721c24;
  border: 1px solid #f5c6cb;
}

@keyframes slideIn {
  from {
    opacity: 0;
    transform: translateY(-10px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

@media (max-width: 768px) {
  .contact-form {
    padding: 20px;
  }

  .contact-form-container h2 {
    font-size: 24px;
  }
}
```

## Step 3: Add Form Validation

Let's enhance the component with client-side validation:

```jsx
import React, { useState } from 'react';
import './ContactForm.css';

function ContactForm() {
  const [formData, setFormData] = useState({
    name: '',
    email: '',
    subject: '',
    message: '',
  });

  const [errors, setErrors] = useState({});

  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  // Validation function
  const validateForm = () => {
    const newErrors = {};

    if (!formData.name.trim()) {
      newErrors.name = 'Name is required';
    } else if (formData.name.trim().length < 2) {
      newErrors.name = 'Name must be at least 2 characters';
    }

    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!formData.email.trim()) {
      newErrors.email = 'Email is required';
    } else if (!emailRegex.test(formData.email)) {
      newErrors.email = 'Please enter a valid email address';
    }

    if (!formData.message.trim()) {
      newErrors.message = 'Message is required';
    } else if (formData.message.trim().length < 10) {
      newErrors.message = 'Message must be at least 10 characters';
    }

    setErrors(newErrors);
    return Object.keys(newErrors).length === 0;
  };

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData(prev => ({
      ...prev,
      [name]: value
    }));

    // Clear error for this field when user starts typing
    if (errors[name]) {
      setErrors(prev => ({
        ...prev,
        [name]: ''
      }));
    }
  };

  const handleSubmit = async (e) => {
    e.preventDefault();

    // Validate before submitting
    if (!validateForm()) {
      return;
    }

    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          ...formData,
          apiKey: 'YOUR_API_KEY_HERE', // Replace with your API key
          replyTo: formData.email,
          honeypot: '', // Spam protection
        }),
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        setFormData({ name: '', email: '', subject: '', message: '' });

        // Clear success message after 5 seconds
        setTimeout(() => {
          setStatus(prev => ({ ...prev, submitted: false }));
        }, 5000);
      } else {
        throw new Error('Form submission failed');
      }
    } catch (error) {
      console.error('Submission error:', error);
      setStatus({ submitting: false, submitted: false, error: true });
    }
  };

  return (
    <div className="contact-form-container">
      <h2>Get in Touch</h2>
      <p className="subtitle">
        Have a question or want to work together? Send us a message!
      </p>

      {status.submitted && (
        <div className="alert alert-success">
          ✅ Thank you! Your message has been sent successfully. We'll get back to you soon.
        </div>
      )}

      {status.error && (
        <div className="alert alert-error">
          ❌ Oops! Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form" noValidate>
        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            className={errors.name ? 'error' : ''}
            placeholder="Your name"
          />
          {errors.name && <span className="error-message">{errors.name}</span>}
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            className={errors.email ? 'error' : ''}
            placeholder="your.email@example.com"
          />
          {errors.email && <span className="error-message">{errors.email}</span>}
        </div>

        <div className="form-group">
          <label htmlFor="subject">Subject</label>
          <input
            type="text"
            id="subject"
            name="subject"
            value={formData.subject}
            onChange={handleChange}
            placeholder="What's this about?"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            className={errors.message ? 'error' : ''}
            rows="5"
            placeholder="Tell us what's on your mind..."
          />
          {errors.message && <span className="error-message">{errors.message}</span>}
        </div>

        <button
          type="submit"
          disabled={status.submitting}
          className="submit-button"
        >
          {status.submitting ? 'Sending...' : 'Send Message'}
        </button>
      </form>
    </div>
  );
}

export default ContactForm;
```

Add error styling to your CSS:

```css
/* Add to ContactForm.css */

.form-group input.error,
.form-group textarea.error {
  border-color: #e74c3c;
}

.error-message {
  display: block;
  color: #e74c3c;
  font-size: 12px;
  margin-top: 5px;
}
```

## Step 4: Add reCAPTCHA Protection

For production applications, add spam protection with reCAPTCHA. First, install the React reCAPTCHA package:

```bash
npm install react-google-recaptcha
```

Update your component:

```jsx
import React, { useState, useRef } from 'react';
import ReCAPTCHA from 'react-google-recaptcha';
import './ContactForm.css';

function ContactForm() {
  const recaptchaRef = useRef();

  const [formData, setFormData] = useState({
    name: '',
    email: '',
    subject: '',
    message: '',
  });

  const [errors, setErrors] = useState({});
  const [recaptchaToken, setRecaptchaToken] = useState('');

  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  const validateForm = () => {
    const newErrors = {};

    if (!formData.name.trim()) {
      newErrors.name = 'Name is required';
    }

    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!formData.email.trim()) {
      newErrors.email = 'Email is required';
    } else if (!emailRegex.test(formData.email)) {
      newErrors.email = 'Please enter a valid email address';
    }

    if (!formData.message.trim()) {
      newErrors.message = 'Message is required';
    }

    setErrors(newErrors);
    return Object.keys(newErrors).length === 0;
  };

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData(prev => ({ ...prev, [name]: value }));

    if (errors[name]) {
      setErrors(prev => ({ ...prev, [name]: '' }));
    }
  };

  const handleRecaptchaChange = (token) => {
    setRecaptchaToken(token);
  };

  const handleSubmit = async (e) => {
    e.preventDefault();

    if (!validateForm()) {
      return;
    }

    if (!recaptchaToken) {
      setErrors(prev => ({
        ...prev,
        recaptcha: 'Please complete the reCAPTCHA'
      }));
      return;
    }

    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          ...formData,
          apiKey: 'YOUR_API_KEY_HERE',
          replyTo: formData.email,
          'g-recaptcha-response': recaptchaToken,
        }),
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        setFormData({ name: '', email: '', subject: '', message: '' });
        setRecaptchaToken('');

        if (recaptchaRef.current) {
          recaptchaRef.current.reset();
        }
      } else {
        throw new Error('Form submission failed');
      }
    } catch (error) {
      console.error('Submission error:', error);
      setStatus({ submitting: false, submitted: false, error: true });
    }
  };

  return (
    <div className="contact-form-container">
      <h2>Get in Touch</h2>
      <p className="subtitle">
        Have a question or want to work together? Send us a message!
      </p>

      {status.submitted && (
        <div className="alert alert-success">
          ✅ Thank you! Your message has been sent successfully.
        </div>
      )}

      {status.error && (
        <div className="alert alert-error">
          ❌ Something went wrong. Please try again.
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form" noValidate>
        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            className={errors.name ? 'error' : ''}
            placeholder="Your name"
          />
          {errors.name && <span className="error-message">{errors.name}</span>}
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            className={errors.email ? 'error' : ''}
            placeholder="your.email@example.com"
          />
          {errors.email && <span className="error-message">{errors.email}</span>}
        </div>

        <div className="form-group">
          <label htmlFor="subject">Subject</label>
          <input
            type="text"
            id="subject"
            name="subject"
            value={formData.subject}
            onChange={handleChange}
            placeholder="What's this about?"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            className={errors.message ? 'error' : ''}
            rows="5"
            placeholder="Tell us what's on your mind..."
          />
          {errors.message && <span className="error-message">{errors.message}</span>}
        </div>

        <div className="form-group">
          <ReCAPTCHA
            ref={recaptchaRef}
            sitekey="YOUR_RECAPTCHA_SITE_KEY"
            onChange={handleRecaptchaChange}
          />
          {errors.recaptcha && (
            <span className="error-message">{errors.recaptcha}</span>
          )}
        </div>

        <button
          type="submit"
          disabled={status.submitting}
          className="submit-button"
        >
          {status.submitting ? 'Sending...' : 'Send Message'}
        </button>
      </form>
    </div>
  );
}

export default ContactForm;
```

Don't forget to configure your reCAPTCHA secret key in your [Static Forms settings](https://www.staticforms.dev/app/forms).

Learn more in our [reCAPTCHA integration guide](/blog/understanding-recaptcha).

## Step 5: Use Environment Variables

For security, store your API keys in environment variables. Create a `.env` file in your project root:

```
REACT_APP_STATICFORMS_API_KEY=your_api_key_here
REACT_APP_RECAPTCHA_SITE_KEY=your_recaptcha_site_key_here
```

Update your component to use environment variables:

```jsx
// In your component
apiKey: process.env.REACT_APP_STATICFORMS_API_KEY,

// For reCAPTCHA
<ReCAPTCHA
  sitekey={process.env.REACT_APP_RECAPTCHA_SITE_KEY}
  onChange={handleRecaptchaChange}
/>
```

**Important**: Variables must start with `REACT_APP_` to be accessible in Create React App.

## Step 6: Add to Your App

Import and use the component in your main app:

```jsx
// App.js
import React from 'react';
import ContactForm from './components/ContactForm';
import './App.css';

function App() {
  return (
    <div className="App">
      <header>
        <h1>My Portfolio</h1>
        <nav>
          <a href="#home">Home</a>
          <a href="#about">About</a>
          <a href="#contact">Contact</a>
        </nav>
      </header>

      <main>
        <section id="contact">
          <ContactForm />
        </section>
      </main>

      <footer>
        <p>&copy; 2026 Your Name. All rights reserved.</p>
      </footer>
    </div>
  );
}

export default App;
```

## Advanced Features

### Custom Hook for Form Handling

Create a reusable custom hook:

```jsx
// hooks/useContactForm.js
import { useState, useCallback } from 'react';

export const useContactForm = (initialState, apiKey) => {
  const [formData, setFormData] = useState(initialState);
  const [errors, setErrors] = useState({});
  const [status, setStatus] = useState({
    submitting: false,
    submitted: false,
    error: false,
  });

  const handleChange = useCallback((e) => {
    const { name, value } = e.target;
    setFormData(prev => ({ ...prev, [name]: value }));
    if (errors[name]) {
      setErrors(prev => ({ ...prev, [name]: '' }));
    }
  }, [errors]);

  const submitForm = useCallback(async (data) => {
    setStatus({ submitting: true, submitted: false, error: false });

    try {
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          ...data,
          apiKey,
          replyTo: data.email,
        }),
      });

      const result = await response.json();

      if (result.success) {
        setStatus({ submitting: false, submitted: true, error: false });
        setFormData(initialState);
        return { success: true };
      } else {
        throw new Error('Submission failed');
      }
    } catch (error) {
      setStatus({ submitting: false, submitted: false, error: true });
      return { success: false, error };
    }
  }, [apiKey, initialState]);

  return {
    formData,
    errors,
    status,
    setErrors,
    handleChange,
    submitForm,
  };
};
```

Use the custom hook:

```jsx
import { useContactForm } from './hooks/useContactForm';

function ContactForm() {
  const {
    formData,
    errors,
    status,
    setErrors,
    handleChange,
    submitForm,
  } = useContactForm(
    { name: '', email: '', subject: '', message: '' },
    process.env.REACT_APP_STATICFORMS_API_KEY
  );

  const handleSubmit = async (e) => {
    e.preventDefault();
    // Validation logic here
    await submitForm(formData);
  };

  // Rest of the component
}
```

### TypeScript Version

For TypeScript projects, add type definitions:

```typescript
// ContactForm.tsx
import React, { useState, FormEvent, ChangeEvent } from 'react';

interface FormData {
  name: string;
  email: string;
  subject: string;
  message: string;
}

interface FormErrors {
  name?: string;
  email?: string;
  message?: string;
  recaptcha?: string;
}

interface FormStatus {
  submitting: boolean;
  submitted: boolean;
  error: boolean;
}

const ContactForm: React.FC = () => {
  const [formData, setFormData] = useState<FormData>({
    name: '',
    email: '',
    subject: '',
    message: '',
  });

  const [errors, setErrors] = useState<FormErrors>({});
  const [status, setStatus] = useState<FormStatus>({
    submitting: false,
    submitted: false,
    error: false,
  });

  const handleChange = (
    e: ChangeEvent<HTMLInputElement | HTMLTextAreaElement>
  ) => {
    const { name, value } = e.target;
    setFormData(prev => ({ ...prev, [name]: value }));
  };

  const handleSubmit = async (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    // Form submission logic
  };

  return (
    // JSX here
  );
};

export default ContactForm;
```

## Troubleshooting

### Common Issues

**Form not submitting:**
- Check that your API key is correct
- Verify the API endpoint URL
- Check browser console for errors
- Ensure Content-Type header is set to `application/json`

**Not receiving emails:**
- Verify your API key in the dashboard
- Check your spam folder
- Confirm your email is verified with Static Forms

**CORS errors:**
- Make sure you're using the correct API endpoint
- Verify you're sending JSON, not FormData
- Check that headers are properly set

## Production Checklist

Before deploying to production:

- ✅ Replace `YOUR_API_KEY_HERE` with environment variable
- ✅ Add reCAPTCHA for spam protection
- ✅ Test form on different devices and browsers
- ✅ Implement proper error handling
- ✅ Add loading states for better UX
- ✅ Verify email notifications are working
- ✅ Test with various input scenarios
- ✅ Add analytics tracking (optional)

## Conclusion

You now have a production-ready React contact form that sends emails without any backend infrastructure. This solution:

- ✅ Works with any React application (CRA, Vite, Next.js, etc.)
- ✅ Provides excellent user experience with validation and feedback
- ✅ Includes spam protection
- ✅ Sends emails reliably to your inbox
- ✅ Requires no server maintenance

Static Forms handles all the complexity of email delivery, spam filtering, and infrastructure management, allowing you to focus on building great React applications.

Ready to add email functionality to your React app? [Sign up for Static Forms](https://www.staticforms.dev) and start receiving form submissions in minutes!

For framework-specific guides, check out our tutorials for [Next.js](/blog/using-staticforms-with-nextjs), [Gatsby](/blog/using-staticforms-with-gatsby), and [HTML forms](/blog/html-form-send-email-without-server).

---

## We've Moved to staticforms.dev - Here's Why

Source: https://www.staticforms.dev/blog/domain-change-xyz-to-dev  
Date: 2025-12-27  
Author: Static Forms Team

We're excited to announce that Static Forms has officially moved to a new home at **staticforms.dev**! Our previous domain, staticforms.xyz, is being retired. In this post, we'll explain why we made this change and what it means for you.

## Why We Changed Our Domain

### The .xyz Spam Problem

When we launched Static Forms, the .xyz domain extension was trendy and affordable. However, over time, we noticed a significant issue: **many email providers and spam filters treat .xyz domains with suspicion**.

Here's why this matters:

- ✅ **Email Deliverability Issues**: Emails from .xyz domains are more likely to end up in spam folders
- ✅ **Corporate Firewalls**: Many companies block or flag .xyz domains by default
- ✅ **Lower Trust Perception**: Users and businesses often view .xyz domains as less trustworthy
- ✅ **Spam Association**: The .xyz TLD has unfortunately become associated with spam and phishing campaigns due to its low cost and minimal registration requirements

### Why .dev Is Better

The .dev domain extension offers several advantages:

1. **Developer-Focused**: The .dev TLD is specifically designed for developers and tech companies, making it a perfect fit for Static Forms
2. **HTTPS Required**: All .dev domains require HTTPS by default, signaling enhanced security
3. **Higher Trust**: The .dev extension is viewed more favorably by email providers and security systems
4. **Professional Image**: It better reflects our commitment to serving the developer community

## What This Means for You

### Your Forms Still Work

**Good news: You don't need to change anything immediately.** We've set up proper redirects from the old domain to the new one:

- `staticforms.xyz` → `staticforms.dev`
- `api.staticforms.xyz` → `api.staticforms.dev`

All your existing forms will continue to work without any modifications.

### What We Recommend

While everything continues to work automatically, we **strongly recommend** updating your forms to use the new domain:

**Old endpoint:**
```html
<form action="https://api.staticforms.xyz/submit" method="POST">
```

**New endpoint:**
```html
<form action="https://api.staticforms.dev/submit" method="POST">
```

### Update Your Bookmarks

If you've bookmarked the Static Forms dashboard or documentation, please update them:

- Dashboard: [https://www.staticforms.dev/app/forms](https://www.staticforms.dev/app/forms)
- Settings: [https://www.staticforms.dev/app/account](https://www.staticforms.dev/app/account)
- Documentation: [https://www.staticforms.dev/docs](https://www.staticforms.dev/docs)

### Sender Email Address Change

The email address that sends your form notifications will also change:

- **Old sender**: `noreply@staticforms.xyz`
- **New sender**: `noreply@staticforms.dev`

If you have any email filters or rules set up for Static Forms notifications, please update them to recognize emails from our new domain.

## Improved Email Deliverability

One of the biggest benefits you'll notice is **improved email deliverability**. With our new .dev domain:

- Form submission notifications are less likely to be flagged as spam
- Your users will have a better experience receiving confirmation emails
- Corporate clients can receive emails without firewall issues

## Questions?

If you have any questions or concerns about this change, please don't hesitate to reach out to our support team. We're here to help make this transition as smooth as possible.

Thank you for being part of the Static Forms community. We're excited about this new chapter and the improved experience it brings to all our users!

---

**Need help updating your forms?** Check out our [getting started guide](/blog/getting-started-with-static-forms) for step-by-step instructions on setting up forms with the new domain.

---

## Introducing reCAPTCHA v3 for Paid Plans

Source: https://www.staticforms.dev/blog/recaptcha-v3-for-pro-users  
Date: 2025-11-12  
Author: Static Forms Team

We're excited to announce that **reCAPTCHA v3** is available on every Static Forms paid plan, starting with Starter at $6/month (or $4/month billed annually)! This powerful invisible CAPTCHA solution provides superior spam protection without requiring any user interaction.

## What is reCAPTCHA v3?

reCAPTCHA v3 is Google's latest CAPTCHA technology that analyzes user behavior in the background and assigns a score from 0.0 (likely a bot) to 1.0 (likely a human). Unlike v2, there are no checkboxes to click or images to identify - it works completely invisibly!

### Key Benefits

- **Invisible Protection**: No user interaction required - completely frictionless experience
- **Score-Based Detection**: Uses advanced algorithms to detect bots based on behavior
- **Customizable Thresholds**: Set your own minimum score for form submissions
- **Better Conversion**: No frustrating CAPTCHA challenges means more completed forms
- **Paid Plans**: Available from the Starter plan ($6/month, or $4/month billed annually) up

## Comparing v2 and v3

| Feature | reCAPTCHA v2 | reCAPTCHA v3 (Paid Plans) |
|---------|--------------|-------------------|
| User Interaction | ✓ Required | ✗ None |
| Visibility | Visible checkbox | Invisible |
| Scoring | Pass/Fail | 0.0 - 1.0 score |
| Customization | Limited | Adjustable threshold |
| User Experience | Some friction | Completely seamless |
| Availability | All tiers | Starter plan and above |

## Setting Up reCAPTCHA v3

### Step 1: Get Your reCAPTCHA v3 Keys

1. Visit the [Google reCAPTCHA Admin Console](https://www.google.com/recaptcha/admin)
2. Click the "+" icon to register a new site
3. Select **reCAPTCHA v3** as the type
4. Add your domain(s)
5. Copy your **Site Key** and **Secret Key**

### Step 2: Configure in Static Forms

1. Log into your [Static Forms dashboard](https://www.staticforms.dev/app/forms)
2. Navigate to [CAPTCHA Settings](https://www.staticforms.dev/app/forms)
3. Select the **reCAPTCHA** tab
4. Choose **v3 Invisible** (paid plans only)
5. Enter your Secret Key
6. Set your minimum score threshold (recommended: 0.5)
7. Save your settings

### Step 3: Implement in Your Form

#### HTML Form Example

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Contact Form with reCAPTCHA v3</title>
    <!-- Load reCAPTCHA v3 -->
    <script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>
</head>
<body>
    <form id="contact-form" action="https://api.staticforms.dev/submit" method="POST">
        <input type="text" name="name" placeholder="Name" required>
        <input type="email" name="email" placeholder="Email" required>
        <textarea name="message" placeholder="Message" required></textarea>
        
        <!-- Hidden fields -->
        <input type="hidden" name="apiKey" value="YOUR_API_KEY">
        <input type="hidden" name="recaptchaToken" id="recaptchaToken">
        
        <button type="submit">Send</button>
    </form>

    <script>
        const RECAPTCHA_SITE_KEY = 'YOUR_SITE_KEY';
        
        document.getElementById('contact-form').addEventListener('submit', async (e) => {
            e.preventDefault();
            
            // Get reCAPTCHA token
            const token = await grecaptcha.execute(RECAPTCHA_SITE_KEY, { 
                action: 'submit' 
            });
            
            // Add token to form
            document.getElementById('recaptchaToken').value = token;
            
            // Submit form
            const formData = new FormData(e.target);
            const response = await fetch(e.target.action, {
                method: 'POST',
                body: formData
            });
            
            if (response.ok) {
                alert('Form submitted successfully!');
                e.target.reset();
            }
        });
    </script>
</body>
</html>
```

#### Next.js Example

```typescript
'use client';

import { useState, useEffect } from 'react';

declare global {
  interface Window {
    grecaptcha: {
      execute: (siteKey: string, options: { action: string }) => Promise<string>;
    };
  }
}

export default function ContactForm() {
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    // Load reCAPTCHA v3 script
    const script = document.createElement('script');
    script.src = `https://www.google.com/recaptcha/api.js?render=${process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY}`;
    document.head.appendChild(script);
  }, []);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    setIsLoading(true);

    try {
      // Get reCAPTCHA token
      const token = await window.grecaptcha.execute(
        process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY!,
        { action: 'submit' }
      );

      const formData = new FormData(e.currentTarget);
      formData.set('apiKey', process.env.NEXT_PUBLIC_STATIC_FORMS_API_KEY!);
      formData.set('recaptchaToken', token);

      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: formData,
      });

      if (response.ok) {
        alert('Form submitted successfully!');
        e.currentTarget.reset();
      } else {
        const error = await response.json();
        throw new Error(error.error || 'Submission failed');
      }
    } catch (error) {
      console.error('Error:', error);
      alert('Failed to submit form');
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="text" name="name" placeholder="Name" required />
      <input type="email" name="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <button type="submit" disabled={isLoading}>
        {isLoading ? 'Sending...' : 'Send'}
      </button>
    </form>
  );
}
```

## Understanding Score Thresholds

reCAPTCHA v3 returns a score between 0.0 and 1.0 for each request:

- **1.0**: Very likely a legitimate human interaction
- **0.5**: Medium risk (recommended default threshold)
- **0.0**: Very likely a bot or malicious activity

### Choosing Your Threshold

In your Static Forms dashboard, you can set the minimum acceptable score:

- **0.3 - 0.4**: More lenient - fewer false positives, but may allow some spam
- **0.5**: Balanced - recommended for most use cases
- **0.6 - 0.7**: More strict - better spam protection, but may block some legitimate users
- **0.8+**: Very strict - may cause false positives for legitimate users

**Recommendation**: Start with 0.5 and adjust based on your spam levels and user feedback.

## Advanced Tips

### Always call `grecaptcha.execute()` at submit time, not at page load

reCAPTCHA v3 tokens are valid for **only 120 seconds** from issuance. If you call `grecaptcha.execute()` when the page loads and stash the token until the user submits, you'll see intermittent "verification failed" errors when users take their time, attach a large file, or submit over a slow network — Google rejects the stale token with `timeout-or-duplicate`.

The code samples above call `grecaptcha.execute()` **inside** the submit handler, so the token is seconds old by the time Static Forms verifies it. Use this pattern as your default — even on simple text-only forms — to eliminate a class of intermittent failures with no real downside.

If your client-side code needs to detect this specific failure and retry with a fresh token, Static Forms returns a stable `code` field on the JSON error body:

- `captcha_required` — no token was sent
- `captcha_expired_or_reused` — token aged out or was already redeemed; refresh and retry
- `captcha_failed` — rejected for another reason (wrong secret, bad signature, score below threshold)

### Custom Actions

You can specify different actions for different forms:

```javascript
const token = await grecaptcha.execute(SITE_KEY, { action: 'contact_form' });
```

This helps you analyze scores for different form types in the reCAPTCHA admin console.

### Error Handling

Always handle potential errors gracefully:

```javascript
try {
  const token = await grecaptcha.execute(SITE_KEY, { action: 'submit' });
  // Submit form...
} catch (error) {
  console.error('reCAPTCHA error:', error);
  // Optionally show error to user or retry
}
```

### Testing in Development

reCAPTCHA v3 works in localhost for testing. Make sure to register `localhost` as a domain in your reCAPTCHA admin console.

## Monitoring and Analytics

Google provides detailed analytics in the reCAPTCHA admin console:

1. View score distribution across your forms
2. Analyze suspicious requests
3. Monitor detection accuracy
4. Adjust thresholds based on real data

## Troubleshooting

### Form Rejections

If legitimate users are being blocked:

1. Check your score threshold - try lowering it
2. Review the reCAPTCHA console for score patterns
3. Ensure the reCAPTCHA script loads before form submission

### Token Errors

- Tokens expire after 2 minutes - generate a new token for each submission
- Don't reuse tokens across multiple requests
- Ensure your domain is registered in the reCAPTCHA console

## Migration from v2 to v3

Already using reCAPTCHA v2? Here's how to upgrade:

1. Generate new v3 keys in the reCAPTCHA console
2. Update your Static Forms settings to v3
3. Replace v2 checkbox with v3 token generation code
4. Test thoroughly with various score thresholds
5. Monitor analytics for the first few days

## Why Paid Plans?

reCAPTCHA v3 requires sophisticated score-based analysis and additional infrastructure to process and validate scores effectively. By making this a paid feature, we can:

- Provide reliable, high-performance verification
- Offer customizable score thresholds
- Include detailed analytics and monitoring
- Ensure the best possible user experience

## Get Started Today

Ready to upgrade your form protection with invisible reCAPTCHA v3?

1. [Upgrade to a paid plan](https://www.staticforms.dev/pricing) — Starter and above
2. Follow our [setup guide](https://www.staticforms.dev/docs/spam-protection)

Have questions? [Contact our support team](https://www.staticforms.dev/contact) - we're here to help!

## Summary

reCAPTCHA v3 offers:

- ✓ Invisible, frictionless user experience
- ✓ Score-based bot detection
- ✓ Customizable security thresholds
- ✓ Better conversion rates
- ✓ Easy implementation

Upgrade to a paid plan today and give your forms the protection they deserve, without compromising user experience!

---

## Using Static Forms with Gatsby: Complete Integration Guide

Source: https://www.staticforms.dev/blog/using-staticforms-with-gatsby  
Date: 2025-10-25  
Author: Static Forms Team

Building a static site with Gatsby doesn't mean you have to sacrifice form functionality. Static Forms makes it easy to add contact forms and other data collection features to your Gatsby site without writing backend code or managing servers.

In this guide, we'll walk through integrating Static Forms with Gatsby, including basic setup and spam protection with reCAPTCHA or privacy-first Altcha CAPTCHA (Altcha needs the Starter plan or above).

> **Prefer a working project?** The [complete Gatsby example](https://github.com/static-forms/static-forms-examples/tree/main/apps/gatsby-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## Why Static Forms for Gatsby?

Gatsby generates static HTML at build time with no server to process forms. Static Forms bridges this gap with:

- ✅ **No Backend Required**: Handle forms without servers or serverless functions
- ✅ **Instant Setup**: Add your API key and start receiving submissions
- ✅ **Email Notifications**: Get submissions delivered to your inbox
- ✅ **Spam Protection**: Honeypot, reCAPTCHA, and Altcha CAPTCHA (from the Starter plan up) options
- ✅ **File Uploads**: Accept attachments up to specified limits (from the Starter plan up)
- ✅ **Webhook Integration**: Connect to external services (from the Starter plan up)

## Prerequisites

- A Gatsby site (version 4.x or 5.x)
- A Static Forms account ([sign up here](https://www.staticforms.dev))
- Your API key from your [dashboard](https://www.staticforms.dev/app/forms)

## Basic Contact Form

Create a contact form component in your Gatsby project:

```jsx
// src/components/contact-form.js
import React, { useState } from "react";
import "../styles/contact-form.css"; // Optional: add your styles

const ContactForm = () => {
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: "",
    subject: "New Contact Form Submission",
    honeypot: "", // Anti-spam honeypot field
    replyTo: "@", // Reply to the sender's email
    apiKey: "YOUR_API_KEY" // Replace with your Static Forms API key
  });

  const [response, setResponse] = useState({
    type: "",
    message: ""
  });

  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData({
      ...formData,
      [name]: value
    });
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    setIsSubmitting(true);
    
    try {
      const res = await fetch("https://api.staticforms.dev/submit", {
        method: "POST",
        body: JSON.stringify(formData),
        headers: { "Content-Type": "application/json" }
      });

      const json = await res.json();

      if (json.success) {
        setResponse({
          type: "success",
          message: "Thank you for your message! We'll get back to you soon."
        });
        // Reset form
        setFormData({
          ...formData,
          name: "",
          email: "",
          message: ""
        });
      } else {
        setResponse({
          type: "error",
          message: json.error || "Something went wrong. Please try again."
        });
      }
    } catch (error) {
      console.error("Form submission error:", error);
      setResponse({
        type: "error",
        message: "Failed to submit form. Please check your connection and try again."
      });
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="contact-form-wrapper">
      {response.type === "success" && (
        <div className="alert alert-success">
          {response.message}
        </div>
      )}
      
      {response.type === "error" && (
        <div className="alert alert-error">
          {response.message}
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form">
        {/* Honeypot field - hidden from users, catches bots */}
        <input
          type="text"
          name="honeypot"
          value={formData.honeypot}
          onChange={handleChange}
          style={{ display: "none" }}
          tabIndex="-1"
          autoComplete="off"
        />

        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            required
            placeholder="Your name"
          />
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            required
            placeholder="your.email@example.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            required
            rows="5"
            placeholder="Your message..."
          />
        </div>

        <button 
          type="submit" 
          disabled={isSubmitting}
          className="submit-button"
        >
          {isSubmitting ? "Sending..." : "Send Message"}
        </button>
      </form>
    </div>
  );
};

export default ContactForm;
```

Add the form to any page:

```jsx
// src/pages/contact.js
import React from "react";
import Layout from "../components/layout";
import ContactForm from "../components/contact-form";

const ContactPage = () => (
  <Layout>
    <h1>Contact Us</h1>
    <ContactForm />
  </Layout>
);

export default ContactPage;
```

That's it! You now have a fully functional contact form. 🎉

## Adding reCAPTCHA Protection

Install the package and get your keys from [Google reCAPTCHA Admin](https://www.google.com/recaptcha/admin):

```bash
npm install react-google-recaptcha
```

Add reCAPTCHA to your form:

```jsx
// src/components/contact-form-recaptcha.js
import React, { useState, useRef } from "react";
import ReCAPTCHA from "react-google-recaptcha";
import "../styles/contact-form.css";

const ContactFormWithRecaptcha = () => {
  const recaptchaRef = useRef();
  
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: "",
    subject: "New Contact Form Submission",
    honeypot: "",
    replyTo: "@",
    apiKey: "YOUR_STATICFORMS_API_KEY", // Replace with your API key
    "g-recaptcha-response": "" // reCAPTCHA token
  });

  const [response, setResponse] = useState({
    type: "",
    message: ""
  });

  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData({
      ...formData,
      [name]: value
    });
  };

  const handleRecaptchaChange = (token) => {
    setFormData({
      ...formData,
      "g-recaptcha-response": token || ""
    });
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    
    // Verify reCAPTCHA is completed
    if (!formData["g-recaptcha-response"]) {
      setResponse({
        type: "error",
        message: "Please complete the reCAPTCHA challenge."
      });
      return;
    }
    
    setIsSubmitting(true);
    
    try {
      const res = await fetch("https://api.staticforms.dev/submit", {
        method: "POST",
        body: JSON.stringify(formData),
        headers: { "Content-Type": "application/json" }
      });

      const json = await res.json();

      if (json.success) {
        setResponse({
          type: "success",
          message: "Thank you for your message! We'll get back to you soon."
        });
        // Reset form
        setFormData({
          ...formData,
          name: "",
          email: "",
          message: "",
          "g-recaptcha-response": ""
        });
        // Reset reCAPTCHA
        if (recaptchaRef.current) {
          recaptchaRef.current.reset();
        }
      } else {
        setResponse({
          type: "error",
          message: json.error || "Something went wrong. Please try again."
        });
      }
    } catch (error) {
      console.error("Form submission error:", error);
      setResponse({
        type: "error",
        message: "Failed to submit form. Please check your connection and try again."
      });
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="contact-form-wrapper">
      {response.type === "success" && (
        <div className="alert alert-success">
          {response.message}
        </div>
      )}
      
      {response.type === "error" && (
        <div className="alert alert-error">
          {response.message}
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form">
        {/* Honeypot field */}
        <input
          type="text"
          name="honeypot"
          value={formData.honeypot}
          onChange={handleChange}
          style={{ display: "none" }}
          tabIndex="-1"
          autoComplete="off"
        />

        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            required
            placeholder="Your name"
          />
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            required
            placeholder="your.email@example.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            required
            rows="5"
            placeholder="Your message..."
          />
        </div>

        <div className="form-group">
          <ReCAPTCHA
            ref={recaptchaRef}
            sitekey="YOUR_RECAPTCHA_SITE_KEY" // Replace with your reCAPTCHA site key
            onChange={handleRecaptchaChange}
          />
        </div>

        <button 
          type="submit" 
          disabled={isSubmitting}
          className="submit-button"
        >
          {isSubmitting ? "Sending..." : "Send Message"}
        </button>
      </form>
    </div>
  );
};

export default ContactFormWithRecaptcha;
```

Learn more in our [reCAPTCHA guide](/blog/understanding-recaptcha).

## Privacy-First: Altcha CAPTCHA

For GDPR-compliant spam protection without tracking, use Altcha CAPTCHA (available from the Starter plan up, $6/month or $4/month billed annually):

```jsx
// src/components/contact-form-altcha.js
import React, { useState, useRef, useEffect } from "react";
import "../styles/contact-form.css";

const ContactFormWithAltcha = () => {
  const altchaWidgetRef = useRef(null);
  
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: "",
    subject: "New Contact Form Submission",
    honeypot: "",
    replyTo: "@",
    apiKey: "YOUR_STATICFORMS_API_KEY" // Replace with your API key
  });

  const [response, setResponse] = useState({
    type: "",
    message: ""
  });

  const [isSubmitting, setIsSubmitting] = useState(false);

  // Load Altcha script
  useEffect(() => {
    const script = document.createElement("script");
    script.src = "https://cdn.jsdelivr.net/npm/altcha@latest/dist/altcha.min.js";
    script.type = "module";
    document.head.appendChild(script);

    return () => {
      document.head.removeChild(script);
    };
  }, []);

  const handleChange = (e) => {
    const { name, value } = e.target;
    setFormData({
      ...formData,
      [name]: value
    });
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    
    // The widget puts its payload in a hidden input named after its name attribute
    const altchaToken = new FormData(e.currentTarget).get("altchaToken");
    
    if (!altchaToken) {
      setResponse({
        type: "error",
        message: "Please complete the CAPTCHA challenge."
      });
      return;
    }
    
    setIsSubmitting(true);
    
    try {
      const submitData = {
        ...formData,
        altchaToken // Static Forms reads the altchaToken (or altcha) field
      };

      const res = await fetch("https://api.staticforms.dev/submit", {
        method: "POST",
        body: JSON.stringify(submitData),
        headers: { "Content-Type": "application/json" }
      });

      const json = await res.json();

      if (json.success) {
        setResponse({
          type: "success",
          message: "Thank you for your message! We'll get back to you soon."
        });
        // Reset form
        setFormData({
          ...formData,
          name: "",
          email: "",
          message: ""
        });
        // Reset Altcha widget
        if (altchaWidgetRef.current) {
          altchaWidgetRef.current.reset();
        }
      } else {
        setResponse({
          type: "error",
          message: json.error || "Something went wrong. Please try again."
        });
      }
    } catch (error) {
      console.error("Form submission error:", error);
      setResponse({
        type: "error",
        message: "Failed to submit form. Please check your connection and try again."
      });
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="contact-form-wrapper">
      {response.type === "success" && (
        <div className="alert alert-success">
          {response.message}
        </div>
      )}
      
      {response.type === "error" && (
        <div className="alert alert-error">
          {response.message}
        </div>
      )}

      <form onSubmit={handleSubmit} className="contact-form">
        {/* Honeypot field */}
        <input
          type="text"
          name="honeypot"
          value={formData.honeypot}
          onChange={handleChange}
          style={{ display: "none" }}
          tabIndex="-1"
          autoComplete="off"
        />

        <div className="form-group">
          <label htmlFor="name">
            Name <span className="required">*</span>
          </label>
          <input
            type="text"
            id="name"
            name="name"
            value={formData.name}
            onChange={handleChange}
            required
            placeholder="Your name"
          />
        </div>

        <div className="form-group">
          <label htmlFor="email">
            Email <span className="required">*</span>
          </label>
          <input
            type="email"
            id="email"
            name="email"
            value={formData.email}
            onChange={handleChange}
            required
            placeholder="your.email@example.com"
          />
        </div>

        <div className="form-group">
          <label htmlFor="message">
            Message <span className="required">*</span>
          </label>
          <textarea
            id="message"
            name="message"
            value={formData.message}
            onChange={handleChange}
            required
            rows="5"
            placeholder="Your message..."
          />
        </div>

        <div className="form-group">
          <altcha-widget
            ref={altchaWidgetRef}
            challengeurl="https://www.staticforms.dev/api/altcha/challenge?apiKey=YOUR_API_KEY"
            name="altchaToken"
            hidefooter
          />
        </div>

        <button 
          type="submit" 
          disabled={isSubmitting}
          className="submit-button"
        >
          {isSubmitting ? "Sending..." : "Send Message"}
        </button>
      </form>
    </div>
  );
};

export default ContactFormWithAltcha;
```

See our [Altcha implementation guide](/blog/implementing-altcha-captcha-html-website) for details.

## Using Environment Variables

Protect your API keys with environment variables. Create `.env.development`:

```
GATSBY_STATICFORMS_API_KEY=your_api_key
GATSBY_RECAPTCHA_SITE_KEY=your_recaptcha_key
```

Use in your components:

```jsx
apiKey: process.env.GATSBY_STATICFORMS_API_KEY

// For reCAPTCHA
<ReCAPTCHA sitekey={process.env.GATSBY_RECAPTCHA_SITE_KEY} />
```

**Important**: Gatsby requires the `GATSBY_` prefix for browser-accessible variables.

## Advanced Features

### Custom Redirects

```jsx
const [formData, setFormData] = useState({
  // ...other fields
  redirectTo: "https://yoursite.com/thank-you",
  apiKey: process.env.GATSBY_STATICFORMS_API_KEY
});
```

### Custom Fields

Every named field is included in the notification email, so no prefix is needed. Add `company: ""` to the initial `formData` state, then add the input:

```jsx
<input
  type="text"
  name="company"
  value={formData.company}
  onChange={handleChange}
  placeholder="Company name"
/>
```

### File Uploads

See our [file upload tutorial](/blog/nextjs-contact-form-document-upload) for implementation details.

## Troubleshooting

**Not receiving emails?**
- Verify your API key in your [dashboard](https://www.staticforms.dev/app/forms)
- Check spam folder
- Confirm email verification with Static Forms

**Build errors?**
- Restart Gatsby dev server after adding environment variables
- Check `GATSBY_` prefix on all variables
- Ensure dependencies are installed

**Environment variables not working?**
- Variables must be in project root
- Restart server after changes
- Verify `.env` files aren't in `.gitignore`

## Conclusion

Static Forms provides a maintenance-free form solution for Gatsby sites. Choose from honeypot, reCAPTCHA, or privacy-focused Altcha CAPTCHA for spam protection. The free tier works great for personal projects, while paid plans — starting at $4/month billed annually on Starter — offer advanced features for larger sites.

Ready to add forms to your Gatsby site? [Sign up for Static Forms](https://www.staticforms.dev) and get started in minutes!

For other frameworks, check out our guides for [Next.js](/blog/using-staticforms-with-nextjs) and [Nuxt.js](/blog/using-staticforms-with-nuxtjs).

Happy coding! 🚀

---

## Implementing Altcha CAPTCHA in Next.js

Source: https://www.staticforms.dev/blog/implementing-altcha-captcha-nextjs  
Date: 2025-08-25  
Author: Static Forms Team

Adding CAPTCHA protection to your Next.js forms doesn't have to be complicated. Altcha provides a privacy-focused solution that's easy to implement and doesn't track your users. Let's add it to a simple contact form.

## What You Need

Before starting, make sure you have:

1. **Next.js application** 
2. **Paid plan** - Altcha needs a [Static Forms](https://www.staticforms.dev) paid plan, starting with Starter at $6/month (or $4/month billed annually)
3. **API key** - From your Static Forms account

## Step 1: Install Altcha

```bash
npm install altcha
```

## Step 2: Add Your API Key

Create a `.env.local` file:

```env
NEXT_PUBLIC_STATIC_FORMS_API_KEY=your_api_key_here
```

## Step 3: Create a Simple Contact Form

Here's a basic contact form with Altcha verification:

```tsx
'use client';

import { useState, useEffect } from 'react';

export default function ContactForm() {
  const [isSubmitting, setIsSubmitting] = useState(false);
  const [status, setStatus] = useState('');

  // Load ALTCHA package
  useEffect(() => {
    import('altcha');
  }, []);

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    
    const form = e.currentTarget;
    setIsSubmitting(true);
    
    try {
      const formData = new FormData(form);
      formData.append('apiKey', process.env.NEXT_PUBLIC_STATIC_FORMS_API_KEY || '');
      
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: formData,
      });
      
      if (response.ok) {
        setStatus('Message sent successfully!');
        form.reset();
        // Reset ALTCHA widget
        const altchaWidget = document.querySelector('altcha-widget') as any;
        if (altchaWidget?.reset) {
          altchaWidget.reset();
        }
      } else {
        setStatus('Failed to send message. Please try again.');
      }
    } catch (error) {
      setStatus('An error occurred. Please try again.');
    } finally {
      setIsSubmitting(false);
    }
  };
  
  return (
    <div className="max-w-md mx-auto p-6">
      {status && (
        <div className="mb-4 p-3 rounded bg-blue-50 text-blue-800">
          {status}
        </div>
      )}
    
      <form onSubmit={handleSubmit} className="space-y-4">
        <div>
          <label className="block mb-2 font-medium">Name</label>
          <input
            type="text"
            name="name"
            required
            className="w-full p-3 border rounded-md"
          />
        </div>
        
        <div>
          <label className="block mb-2 font-medium">Email</label>
          <input
            type="email"
            name="email"
            required
            className="w-full p-3 border rounded-md"
          />
        </div>
        
        <div>
          <label className="block mb-2 font-medium">Message</label>
          <textarea
            name="message"
            required
            rows={4}
            className="w-full p-3 border rounded-md"
          />
        </div>
        
        <div>
          <label className="block mb-2 font-medium">Verify you're human</label>
          <altcha-widget
            challengeurl={`https://www.staticforms.dev/api/altcha/challenge?apiKey=${process.env.NEXT_PUBLIC_STATIC_FORMS_API_KEY || ''}`}
            name="altchaToken"
          />
        </div>
        
        <button
          type="submit"
          disabled={isSubmitting}
          className="w-full py-3 bg-blue-600 text-white rounded-md disabled:bg-gray-400"
        >
          {isSubmitting ? 'Sending...' : 'Send Message'}
        </button>
      </form>
    </div>
  );
}
```

## Step 4: Use the Component

Create a page to use your form:

```tsx
// app/contact/page.tsx
import ContactForm from './ContactForm';

export default function ContactPage() {
  return (
    <div className="container mx-auto py-12">
      <h1 className="text-3xl font-bold text-center mb-8">Contact Us</h1>
      <ContactForm />
    </div>
  );
}
```

## Step 5: Enable Altcha

1. Go to your [CAPTCHA settings](https://www.staticforms.dev/app/forms)
2. Switch to "Altcha" tab
3. Generate your keys
4. Save settings

## That's It!

Your form now has privacy-focused CAPTCHA protection. The widget automatically:

- ✅ Loads and verifies challenges  
- ✅ Works without tracking users
- ✅ Protects against spam
- ✅ No puzzles for users to solve

## Need Help?

- [Get a paid plan](https://www.staticforms.dev/pricing) (Starter and above) to use Altcha
- [Configure settings](https://www.staticforms.dev/app/forms) in your account
- [Read more guides](/blog/getting-started-with-static-forms)

## Related Articles

- [Implementing Altcha CAPTCHA on HTML Websites](/blog/implementing-altcha-captcha-html-website)
- [Getting Started with Static Forms](/blog/getting-started-with-static-forms)
- [Adding Contact Forms to Static Sites](/blog/adding-contact-forms-to-static-sites)

---

## Implementing Altcha CAPTCHA on HTML Websites

Source: https://www.staticforms.dev/blog/implementing-altcha-captcha-html-website  
Date: 2025-08-21  
Author: Static Forms Team

Traditional CAPTCHA solutions often compromise user privacy by tracking visitors and requiring external dependencies. Altcha offers a revolutionary alternative - a privacy-first, self-hosted CAPTCHA that uses proof-of-work challenges instead of visual puzzles. In this comprehensive guide, we'll show you how to implement Altcha CAPTCHA on your HTML website.

## What is Altcha CAPTCHA?

Altcha is a modern CAPTCHA alternative that prioritizes user privacy and provides a seamless experience. Unlike traditional solutions, Altcha:

- **No cookies or tracking** - Fully GDPR compliant
- **Self-hosted** - No external dependencies on Google or other services
- **Invisible verification** - Users don't need to solve puzzles
- **Proof-of-work based** - Uses computational challenges instead of visual recognition

## Prerequisites

Before implementing Altcha, ensure you have:

1. **Paid plan** - Altcha is available on all [Static Forms](https://www.staticforms.dev) paid plans, starting with Starter at $6/month (or $4/month billed annually)
2. **API key** - Your Static Forms API key

## Step 1: Configure Altcha in Your Account

First, set up Altcha in your Static Forms account (Starter plan or above):

1. Navigate to your [CAPTCHA settings](https://www.staticforms.dev/app/forms)
2. Switch to the "Altcha" tab
3. Generate your Altcha keys
4. Configure difficulty and expiration settings
5. Save your site key for frontend integration

## Step 2: Simple HTML Form

Create a basic HTML form with Altcha:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form with Altcha</title>
    
    <!-- Include Altcha Library -->
    <script src="https://cdn.jsdelivr.net/gh/altcha-org/altcha/dist/altcha.min.js" type="module"></script>
</head>
<body>
        <h1>Contact Us</h1>
    <form action="https://api.staticforms.dev/submit" method="POST">
        <div>
            <label for="name">Name:</label>
                <input type="text" id="name" name="name" required>
            </div>

        <div>
            <label for="email">Email:</label>
                <input type="email" id="email" name="email" required>
            </div>

        <div>
            <label for="message">Message:</label>
            <textarea id="message" name="message" required></textarea>
            </div>

        <!-- Altcha Widget - Just add this one line! -->
        <altcha-widget 
            challengeurl="https://www.staticforms.dev/api/altcha/challenge?apiKey=YOUR_API_KEY_HERE"
            name="altchaToken">
        </altcha-widget>

        <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
        <button type="submit">Send Message</button>
        </form>
</body>
</html>
```

**That's it!** Just add the script tag and the `<altcha-widget>` element. The widget handles everything automatically - no JavaScript needed!

## Step 3: Optional Styling

Add some basic CSS to make it look better:

```css
<style>
    body { font-family: Arial, sans-serif; max-width: 600px; margin: 0 auto; padding: 20px; }
    div { margin: 15px 0; }
    label { display: block; margin-bottom: 5px; }
    input, textarea { width: 100%; padding: 10px; border: 1px solid #ddd; border-radius: 4px; }
    button { background: #007cba; color: white; padding: 10px 20px; border: none; border-radius: 4px; cursor: pointer; }
    button:hover { background: #005a87; }
</style>
```

## Step 4: Common Options (Optional)

You can customize the widget with these simple options:

```html
<!-- Hide the Altcha branding -->
<altcha-widget 
    challengeurl="https://www.staticforms.dev/api/altcha/challenge?apiKey=YOUR_API_KEY_HERE"
    name="altchaToken"
    hidefooter="true">
</altcha-widget>

<!-- Auto-verify when user focuses on form -->
<altcha-widget 
    challengeurl="https://www.staticforms.dev/api/altcha/challenge?apiKey=YOUR_API_KEY_HERE"
    name="altchaToken"
    auto="onfocus">
</altcha-widget>
```

### Simple Color Customization

Change the widget colors to match your site:

```css
altcha-widget {
    --altcha-color-border: #your-border-color;
    --altcha-color-border-focus: #your-focus-color;
}
```

## That's It!

Your form now has Altcha CAPTCHA protection. The widget automatically:
- ✅ Loads and verifies challenges
- ✅ Handles all the complex cryptography 
- ✅ Sends the token with your form
- ✅ Protects against spam and bots

## Quick Troubleshooting

**Widget not showing?**
- Make sure you included the script: `<script src="https://cdn.jsdelivr.net/gh/altcha-org/altcha/dist/altcha.min.js" type="module"></script>`
- Replace `YOUR_API_KEY_HERE` with your actual API key

**Form not working?**
- Check you have a [paid plan](https://www.staticforms.dev/pricing) (Altcha is available from the Starter plan up)
- Verify Altcha is enabled in your [account settings](https://www.staticforms.dev/app/forms)

## Complete Working Example

Copy and paste this complete example:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Contact Form with Altcha</title>
    
    <!-- Include Altcha -->
    <script src="https://cdn.jsdelivr.net/gh/altcha-org/altcha/dist/altcha.min.js" type="module"></script>
    
    <style>
        body { font-family: Arial, sans-serif; max-width: 600px; margin: 0 auto; padding: 20px; }
        div { margin: 15px 0; }
        label { display: block; margin-bottom: 5px; font-weight: bold; }
        input, textarea { width: 100%; padding: 10px; border: 1px solid #ddd; border-radius: 4px; box-sizing: border-box; }
        button { background: #007cba; color: white; padding: 12px 24px; border: none; border-radius: 4px; cursor: pointer; font-size: 16px; }
        button:hover { background: #005a87; }
    </style>
</head>
<body>
    <h1>Contact Form</h1>
    
    <form action="https://api.staticforms.dev/submit" method="POST">
        <div>
            <label for="name">Your Name:</label>
            <input type="text" id="name" name="name" required>
        </div>

        <div>
            <label for="email">Your Email:</label>
            <input type="email" id="email" name="email" required>
        </div>

        <div>
            <label for="message">Your Message:</label>
            <textarea id="message" name="message" rows="5" required></textarea>
        </div>

        <!-- Altcha CAPTCHA - Replace YOUR_API_KEY_HERE with your actual key -->
        <altcha-widget 
            challengeurl="https://www.staticforms.dev/api/altcha/challenge?apiKey=YOUR_API_KEY_HERE"
            name="altchaToken">
        </altcha-widget>

        <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
        
        <div>
            <button type="submit">Send Message</button>
            </div>
    </form>
</body>
</html>
```

**Just replace `YOUR_API_KEY_HERE` with your actual API key and you're done!**

## Why Use Altcha?

- ✅ **Privacy-first** - No tracking or cookies
- ✅ **User-friendly** - No puzzles to solve
- ✅ **GDPR compliant** - Built-in privacy protection
- ✅ **Easy to implement** - Just 2 lines of code
- ✅ **Works everywhere** - Modern browsers only

## Need Help?

- [Get a paid plan](https://www.staticforms.dev/pricing) (Starter and above) to use Altcha
- [Configure Altcha](https://www.staticforms.dev/app/forms) in your account settings
- [Read more form guides](/blog/getting-started-with-static-forms)

## Conclusion

Altcha is the easiest way to add privacy-focused CAPTCHA to your forms. Just include the script, add the widget, and you're protected from spam while respecting your users' privacy.

Ready to get started? [Upgrade to a paid plan](https://www.staticforms.dev/pricing) today!

---

## How to Add Document Upload to Your Next.js Contact Form

Source: https://www.staticforms.dev/blog/nextjs-contact-form-document-upload  
Date: 2025-06-12  
Author: Static Forms Team

Building a contact form with document upload functionality can significantly enhance user experience by allowing visitors to share attachments, portfolios, or supporting documents. In this comprehensive guide, we'll walk through creating a robust Next.js contact form with secure file upload capabilities.

## What You'll Learn

- How to implement file upload in React with proper validation
- Secure file handling with size and type restrictions
- Error handling for file uploads
- Form submission with FormData
- Integration with Static Forms API for seamless form processing

> **Note**: File uploads are available from the Starter plan up ($6/month, or $4/month billed annually), and the whole submission, meaning the file plus the other fields, has to stay under 4.5MB. Free-tier submissions with files will be rejected.

If you want the plain HTML version first, the [HTML file upload guide](/blog/file-upload-html) covers the markup, client-side checks and server-side safety this tutorial builds on.

## Project Setup

First, let's set up our Next.js project with the necessary dependencies:

```bash
npx create-next-app@latest contact-form-upload --typescript --tailwind --eslint
cd contact-form-upload
npm install
```

## Building the Contact Form Component

Let's create a comprehensive contact form component with document upload functionality:

```typescript
'use client';

import { useState, useEffect } from 'react';

export default function ContactForm() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  const [subject, setSubject] = useState('');
  const [message, setMessage] = useState('');
  const [attachment, setAttachment] = useState<File | null>(null);
  const [isSubmitting, setIsSubmitting] = useState(false);
  const [status, setStatus] = useState<'idle' | 'success' | 'error'>('idle');
  const [statusMessage, setStatusMessage] = useState('');

  const handleFileChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0] || null;
    
      // The whole submission must stay under 4.5MB; 4MB leaves room for the other fields
  if (file && file.size > 4 * 1024 * 1024) {
    setStatus('error');
    setStatusMessage('File size must be less than 4MB.');
      e.target.value = ''; // Clear the input
      return;
    }
    
    // File type validation
    if (file) {
      const allowedTypes = [
        'image/jpeg', 'image/png', 'image/gif', 'image/webp',
        'application/pdf', 'application/msword', 
        'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
        'text/plain', 'application/rtf'
      ];
      
      if (!allowedTypes.includes(file.type)) {
        setStatus('error');
        setStatusMessage('Please upload a valid file type (images, PDF, Word documents, or text files).');
        e.target.value = '';
        return;
      }
    }
    
    setAttachment(file);
    if (status === 'error') {
      setStatus('idle');
    }
  };

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setIsSubmitting(true);
    
    try {
      const formData = new FormData();
      formData.append('apiKey', 'your-static-forms-api-key');
      formData.append('name', name);
      formData.append('email', email);
      formData.append('subject', subject);
      formData.append('message', message);
      formData.append('replyTo', email);
      
      // Add attachment if present
      if (attachment) {
        formData.append('attachment', attachment);
      }
      
      const response = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: formData,
      });
      
      if (response.ok) {
        setStatus('success');
        setStatusMessage('Thank you for your message! We will get back to you soon.');
        // Reset form
        setName('');
        setEmail('');
        setSubject('');
        setMessage('');
        setAttachment(null);
        const fileInput = document.getElementById('attachment') as HTMLInputElement;
        if (fileInput) fileInput.value = '';
      } else {
        setStatus('error');
        setStatusMessage('Failed to send your message. Please try again.');
      }
    } catch (error) {
      // An oversized upload shows up here as a network error
      setStatus('error');
      setStatusMessage('The upload failed. Check your connection, or try smaller files.');
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="max-w-2xl mx-auto p-6">
      <h2 className="text-2xl font-bold mb-6">Contact Us</h2>
      
      {status === 'success' && (
        <div className="mb-6 bg-green-50 p-4 rounded-md border border-green-200">
          <p className="text-green-700">{statusMessage}</p>
        </div>
      )}
      
      {status === 'error' && (
        <div className="mb-6 bg-red-50 p-4 rounded-md border border-red-200">
          <p className="text-red-700">{statusMessage}</p>
        </div>
      )}

      <form onSubmit={handleSubmit} className="space-y-6">
        <div>
          <label htmlFor="name" className="block mb-2 font-medium text-gray-700">
            Name <span className="text-red-500">*</span>
          </label>
          <input
            type="text"
            id="name"
            value={name}
            onChange={(e) => setName(e.target.value)}
            required
            className="w-full p-3 border border-gray-300 rounded-md focus:ring-2 focus:ring-blue-500"
          />
        </div>
        
        <div>
          <label htmlFor="email" className="block mb-2 font-medium text-gray-700">
            Email <span className="text-red-500">*</span>
          </label>
          <input
            type="email"
            id="email"
            value={email}
            onChange={(e) => setEmail(e.target.value)}
            required
            className="w-full p-3 border border-gray-300 rounded-md focus:ring-2 focus:ring-blue-500"
          />
        </div>
        
        <div>
          <label htmlFor="subject" className="block mb-2 font-medium text-gray-700">
            Subject <span className="text-red-500">*</span>
          </label>
          <input
            type="text"
            id="subject"
            value={subject}
            onChange={(e) => setSubject(e.target.value)}
            required
            className="w-full p-3 border border-gray-300 rounded-md focus:ring-2 focus:ring-blue-500"
          />
        </div>
        
        <div>
          <label htmlFor="message" className="block mb-2 font-medium text-gray-700">
            Message <span className="text-red-500">*</span>
          </label>
          <textarea
            id="message"
            value={message}
            onChange={(e) => setMessage(e.target.value)}
            required
            rows={5}
            className="w-full p-3 border border-gray-300 rounded-md focus:ring-2 focus:ring-blue-500"
          />
        </div>
        
        <div>
          <label htmlFor="attachment" className="block mb-2 font-medium text-gray-700">
            Attachment <span className="text-gray-500 font-normal">(optional)</span>
          </label>
          <input
            type="file"
            id="attachment"
            onChange={handleFileChange}
            accept=".jpg,.jpeg,.png,.gif,.webp,.pdf,.doc,.docx,.txt,.rtf"
            className="w-full p-3 border border-gray-300 rounded-md file:mr-4 file:py-2 file:px-4 file:rounded-md file:border-0 file:bg-blue-50 file:text-blue-700 hover:file:bg-blue-100"
          />
          <p className="text-sm text-gray-500 mt-1">
            Max file size: 4MB. Accepted formats: Images, PDF, Word documents, text files.
          </p>
          {attachment && (
            <p className="text-sm text-green-600 mt-1">
              Selected: {attachment.name} ({(attachment.size / 1024 / 1024).toFixed(2)} MB)
            </p>
          )}
        </div>
        
        <button
          type="submit"
          disabled={isSubmitting}
          className={`w-full py-3 px-6 rounded-md text-white font-medium transition-colors ${
            isSubmitting 
              ? 'bg-gray-400 cursor-not-allowed' 
              : 'bg-blue-600 hover:bg-blue-700'
          }`}
        >
          {isSubmitting ? 'Sending...' : 'Send Message'}
        </button>
      </form>
    </div>
  );
}
```

## Key Features Explained

### File Validation

Our form includes comprehensive file validation to ensure security and user experience:

```typescript
const handleFileChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const file = e.target.files?.[0] || null;
  
  // Size validation (4MB, under the 4.5MB submission limit)
if (file && file.size > 4 * 1024 * 1024) {
  setStatus('error');
  setStatusMessage('File size must be less than 4MB.');
    e.target.value = '';
    return;
  }
  
  // Type validation
  const allowedTypes = [
    'image/jpeg', 'image/png', 'image/gif', 'image/webp',
    'application/pdf', 'application/msword', 
    'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
    'text/plain', 'application/rtf'
  ];
  
  if (file && !allowedTypes.includes(file.type)) {
    setStatus('error');
    setStatusMessage('Invalid file type.');
    e.target.value = '';
    return;
  }
};
```

### FormData for File Uploads

When submitting files, we use `FormData` instead of JSON to properly handle binary data:

```typescript
const formData = new FormData();
formData.append('apiKey', 'your-api-key');
formData.append('name', name);
formData.append('email', email);
// ... other fields

if (attachment) {
  formData.append('attachment', attachment);
}
```

## Environment Variables

Create a `.env.local` file to store your API keys securely:

```bash
NEXT_PUBLIC_STATIC_FORMS_API_KEY=your_api_key_here
```

Then use it in your component:

```typescript
formData.append('apiKey', process.env.NEXT_PUBLIC_STATIC_FORMS_API_KEY || '');
```

## Setting Up Static Forms

1. Visit [Static Forms](https://www.staticforms.dev) and create an account
2. Create a new form and get your API key
3. Configure your form settings to accept file uploads (Starter plan and up)
4. Add your domain to the allowed origins

## Enhanced Security Considerations

### Client-Side Validation

While we validate files on the client side, remember that client-side validation is primarily for user experience. Always validate files on the server side as well.

### File Type Restrictions

Our form accepts common document and image types:
- Images: JPEG, PNG, GIF, WebP
- Documents: PDF, Word (.doc, .docx), Plain text, RTF

### Size Limitations

Static Forms limits the whole submission, the file plus every other field, to 4.5MB. A larger request is refused with HTTP 413 before Static Forms processes it, and in the browser that shows up as a network error rather than a readable message. So the form checks the file against 4MB before upload, which leaves room for the other fields:

```typescript
if (file && file.size > 4 * 1024 * 1024) {
  // Handle oversized file
}
```

## Styling with Tailwind CSS

The form uses Tailwind CSS for responsive, modern styling. Key classes include:

- `file:` prefix for styling file input buttons
- `focus:ring-2` for accessibility-friendly focus states
- `transition-colors` for smooth hover effects

## Advanced Features

### Progress Indicator

For large file uploads, consider adding a progress indicator:

```typescript
const [uploadProgress, setUploadProgress] = useState(0);

// In your fetch request
const xhr = new XMLHttpRequest();
xhr.upload.addEventListener('progress', (e) => {
  const progress = (e.loaded / e.total) * 100;
  setUploadProgress(progress);
});
```

### Multiple File Support

To support multiple files, modify the state and input:

```typescript
const [attachments, setAttachments] = useState<File[]>([]);

// In JSX
<input
  type="file"
  multiple
  onChange={handleMultipleFileChange}
/>
```

### Drag and Drop

Enhance user experience with drag-and-drop functionality:

```typescript
const handleDrop = (e: React.DragEvent) => {
  e.preventDefault();
  const files = Array.from(e.dataTransfer.files);
  // Process dropped files
};

return (
  <div
    onDrop={handleDrop}
    onDragOver={(e) => e.preventDefault()}
    className="border-2 border-dashed border-gray-300 p-6"
  >
    Drop files here or click to select
  </div>
);
```

## Testing Your Form

1. Test with different file types and sizes
2. Verify error messages display correctly
3. Ensure form resets after successful submission
4. Test on mobile devices for responsive behavior

## Common Troubleshooting

### File Not Uploading
- Check file size limits
- Verify file type restrictions
- Ensure FormData is used instead of JSON

### Validation Errors
- Verify all required fields are filled
- Check file validation logic

## Conclusion

Adding document upload functionality to your Next.js contact form enhances user experience and provides valuable functionality for collecting attachments. By implementing proper validation, error handling, and security measures, you can create a robust form that handles file uploads safely and efficiently.

The combination of React's state management, proper file validation, and Static Forms' reliable backend processing creates a seamless experience for both developers and users. Whether you're building a portfolio submission form, support ticket system, or general contact form, these techniques will serve you well.

For more advanced form handling tutorials and Static Forms features, check out our [getting started guide](/blog/getting-started-with-static-forms) and learn about [adding contact forms to static sites](/blog/adding-contact-forms-to-static-sites).

## Related Articles

- [Getting Started with Static Forms](/blog/getting-started-with-static-forms)
- [Adding Contact Forms to Static Sites](/blog/adding-contact-forms-to-static-sites)
- [Using Static Forms with Next.js](/blog/using-staticforms-with-nextjs)

---

## Adding Contact Forms to Static Websites Guide

Source: https://www.staticforms.dev/blog/adding-contact-forms-to-static-sites  
Date: 2025-05-01  
Author: Static Forms Team

Creating a beautiful static website is relatively straightforward with modern tools and frameworks, but adding interactive elements like contact forms presents a unique challenge. Since static sites don't have server-side processing capabilities, how do you collect and process form submissions? In this comprehensive guide, we'll explore how to implement professional contact forms on static websites using a dedicated form endpoint service. New to the term? Start with [what a static form is](/what-is-a-static-form).

> **Using a framework?** The [Static Forms examples repo](https://github.com/static-forms/static-forms-examples) has a ready-to-deploy contact form for 13 frameworks, including Next.js, Nuxt, React, Vue, SvelteKit, Astro, Angular, React Router, SolidStart, Qwik, Gatsby, Eleventy and plain HTML. Each one has a one-click Deploy to Vercel button.

## The Static Site Form Challenge

Static sites are fast, secure, and cost-effective to host, making them an excellent choice for many projects. However, their static nature means they lack built-in form processing capabilities. Traditional contact forms typically require:

1. Server-side code to process form submissions
2. Database storage for form entries
3. Email sending capabilities
4. Spam protection measures

Fortunately, there's an elegant solution: **form endpoint services** that handle all the backend functionality while keeping your frontend simple and static.

## What is a Form Endpoint Service?

A form endpoint service provides dedicated API endpoints that process form submissions from your static website. These services manage all the server-side logic, allowing you to implement fully functional contact forms without writing a single line of backend code.

Static Forms is one such service that offers a comprehensive solution for handling form submissions on static websites.

## Setting Up Your First Contact Form with Static Forms

Let's walk through the process of adding a professional contact form to your static website using the [Static Forms form backend](/).

### Step 1: Create a Static Forms Account

First, you'll need to [sign up for a Static Forms account](https://www.staticforms.dev) and obtain your API key from the dashboard.

### Step 2: Create a Basic HTML Form

Next, add the following HTML code to your static site:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="text" name="name" placeholder="Your Name" required>
  <input type="email" name="email" placeholder="Your Email" required>
  <textarea name="message" placeholder="Your Message" required></textarea>
  
  <!-- Important: Include your API key -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  
  <button type="submit">Send Message</button>
</form>
```

Replace `YOUR_API_KEY_HERE` with the actual API key from your Static Forms dashboard.

### Step 3: Customize Your Form's Behavior

Static Forms provides several hidden fields that allow you to customize the behavior of your form:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Form fields -->
  
  <!-- Configuration options -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  <input type="hidden" name="subject" value="New Contact Form Submission">
  <input type="hidden" name="replyTo" value="@"> <!-- Uses the email from the form as reply-to address -->
  <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you">
  
  <button type="submit">Send Message</button>
</form>
```

These hidden fields allow you to:
- Set a custom subject line for the notification email
- Configure the reply-to address
- Redirect users to a custom thank-you page after submission

### Step 4: Add Spam Protection

To protect your form from spam submissions, it's recommended to add reCAPTCHA:

```html
<head>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>

<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Form fields -->
  
  <!-- reCAPTCHA -->
  <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
  
  <!-- Configuration options -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  
  <button type="submit">Send Message</button>
</form>
```

For more information on implementing reCAPTCHA with Static Forms, check out our [understanding reCAPTCHA guide](/blog/understanding-recaptcha).

## Advanced Features for Better Contact Forms

Static Forms offers several advanced features to enhance your contact forms:

### File Attachments

Allow users to upload files with their form submissions (available from the Starter plan up):

```html
<input type="file" name="attachment" accept=".pdf,.doc,.docx">
```

### Form Validation

While HTML5 provides basic validation, you might want to add custom JavaScript validation:

```javascript
document.querySelector('form').addEventListener('submit', function(event) {
  const email = document.querySelector('input[name="email"]').value;
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  
  if (!emailRegex.test(email)) {
    event.preventDefault();
    alert('Please enter a valid email address');
  }
});
```

## Integrating with Popular Static Site Generators

Static Forms works seamlessly with all major static site generators:

### Next.js Integration

For Next.js projects, check out our detailed [guide on using Static Forms with Next.js](/blog/using-staticforms-with-nextjs).

### Nuxt.js Integration

If you're using Nuxt.js, we have a comprehensive [tutorial on integrating Static Forms with Nuxt.js](/blog/using-staticforms-with-nuxtjs).

### Gatsby, Hugo, and Jekyll

The integration process is similar for other static site generators - simply include the HTML form with the appropriate action and hidden fields.

## Styling Your Contact Form

A well-designed contact form improves user experience and increases submission rates. Here's a simple CSS example to style your form:

```css
.contact-form {
  max-width: 600px;
  margin: 0 auto;
  padding: 2rem;
  border-radius: 8px;
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
}

.form-group {
  margin-bottom: 1.5rem;
}

.form-control {
  display: block;
  width: 100%;
  padding: 0.75rem;
  border: 1px solid #ddd;
  border-radius: 4px;
  font-size: 1rem;
}

.submit-btn {
  display: inline-block;
  padding: 0.75rem 1.5rem;
  background-color: #4a90e2;
  color: white;
  border: none;
  border-radius: 4px;
  cursor: pointer;
  font-size: 1rem;
  transition: background-color 0.3s ease;
}

.submit-btn:hover {
  background-color: #3578ca;
}
```

## Best Practices for Contact Forms on Static Sites

To ensure your contact form provides the best possible user experience:

1. **Keep it simple** - Only ask for information you actually need
2. **Validate inputs** - Provide clear error messages for invalid entries
3. **Show loading states** - Indicate when a form is being submitted
4. **Provide clear success messages** - Confirm when submissions are successful
5. **Test thoroughly** - Ensure your form works across different browsers and devices

## Troubleshooting Common Issues

If you're experiencing problems with your contact form:

- **Not receiving emails?** Check your spam folder and verify your API key is correct
- **reCAPTCHA not working?** Ensure your site and secret keys are properly configured
- **Styling issues?** Use browser developer tools to inspect and debug CSS problems
- **Submission errors?** Check the browser console for JavaScript errors

## Conclusion

Adding a contact form to your static website doesn't have to be complicated. With form endpoint services like Static Forms, you can implement professional contact forms without the need for server-side code or complex infrastructure.

By following the steps outlined in this guide, you can create beautiful, functional contact forms that enhance your static website's interactivity while maintaining all the benefits of static hosting.

Ready to get started? [Sign up for Static Forms](https://www.staticforms.dev) today and add a professional contact form to your static website in minutes.

## Complete Example

Here's a complete example of a styled contact form with Static Forms integration:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Contact Us</title>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
  <style>
    .contact-form {
      max-width: 600px;
      margin: 2rem auto;
      padding: 2rem;
      border-radius: 8px;
      box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
      font-family: system-ui, -apple-system, BlinkMacSystemFont, sans-serif;
    }
    .form-group {
      margin-bottom: 1.5rem;
    }
    .form-control {
      display: block;
      width: 100%;
      padding: 0.75rem;
      border: 1px solid #ddd;
      border-radius: 4px;
      font-size: 1rem;
    }
    .submit-btn {
      display: inline-block;
      padding: 0.75rem 1.5rem;
      background-color: #4a90e2;
      color: white;
      border: none;
      border-radius: 4px;
      cursor: pointer;
      font-size: 1rem;
      transition: background-color 0.3s ease;
    }
    .submit-btn:hover {
      background-color: #3578ca;
    }
    .g-recaptcha {
      margin-bottom: 1.5rem;
    }
  </style>
</head>
<body>
  <div class="contact-form">
    <h2>Contact Us</h2>
    <form action="https://api.staticforms.dev/submit" method="POST">
      <div class="form-group">
        <label for="name">Name</label>
        <input type="text" id="name" name="name" class="form-control" required>
      </div>
      
      <div class="form-group">
        <label for="email">Email</label>
        <input type="email" id="email" name="email" class="form-control" required>
      </div>
      
      <div class="form-group">
        <label for="message">Message</label>
        <textarea id="message" name="message" class="form-control" rows="5" required></textarea>
      </div>
      
      <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
      
      <!-- Hidden fields -->
      <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
      <input type="hidden" name="subject" value="New Contact Form Submission">
      <input type="hidden" name="replyTo" value="@">
      <input type="hidden" name="redirectTo" value="https://yoursite.com/thank-you">
      
      <button type="submit" class="submit-btn">Send Message</button>
    </form>
  </div>
</body>
</html>
```

This blog post is part of our ongoing series on web development best practices. For more insights on creating effective websites, check out our other guides on [getting started with Static Forms](/blog/getting-started-with-static-forms).

---

## Using Static Forms with Nuxt.js: A Complete Guide

Source: https://www.staticforms.dev/blog/using-staticforms-with-nuxtjs  
Date: 2025-04-27  
Author: Static Forms Team

Are you building a Nuxt.js application and need a simple way to handle form submissions without setting up a backend server? Static Forms is the perfect solution for collecting form data from your site and receiving submissions directly in your inbox.

In this guide, we'll explore how to integrate the Static Forms service with your Nuxt.js application, including both basic implementation and enhanced security with reCAPTCHA. If you're using Next.js instead, check out our [Next.js integration guide](/blog/using-staticforms-with-nextjs).

> **Prefer a working project?** The [complete Nuxt example](https://github.com/static-forms/static-forms-examples/tree/main/apps/nuxt-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## What is Static Forms?

Static Forms is a form backend for your website, and static sites need no server of their own to use it. It allows you to receive form submissions via email without writing any server-side code. This is particularly useful for:

- Contact forms
- Feedback forms
- Newsletter signups
- Simple data collection

The service is free to use (with some limitations) and provides a straightforward API for integrating forms into your static website.

## Getting Started with Static Forms

Before implementing forms in your Nuxt.js app, you'll need to:

1. Visit [staticforms.dev](https://www.staticforms.dev)
2. Register for a free account
3. Obtain your unique API key

This API key will be used to connect your forms to your Static Forms account, ensuring submissions are forwarded to your email address.

## Basic Integration in Nuxt.js

Let's start by implementing a simple contact form without reCAPTCHA. This approach is quick to set up but offers less protection against spam.

### Create a Client-Side Component for Your Form

```vue
<!-- components/ContactForm.vue -->
<script setup lang="ts">
import { ref } from 'vue'

const formData = ref({
  name: '',
  email: '',
  message: '',
  subject: 'Contact Form Submission', // Default subject
  honeypot: '', // Anti-spam field
  replyTo: '@', // This will set replyTo to the email provided
  apiKey: 'YOUR_API_KEY' // Replace with your actual apiKey
})

const response = ref({
  type: '',
  message: ''
})

const isSubmitting = ref(false)

const handleSubmit = async () => {
  isSubmitting.value = true
  
  try {
    const res = await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      body: JSON.stringify(formData.value),
      headers: { 'Content-Type': 'application/json' }
    })

    const json = await res.json()

    if (json.success) {
      response.value = {
        type: 'success',
        message: 'Thank you for your message! We\'ll get back to you soon.'
      }
      // Reset form fields
      formData.value.name = ''
      formData.value.email = ''
      formData.value.message = ''
    } else {
      response.value = {
        type: 'error',
        message: json.error || 'An error occurred. Please try again.'
      }
    }
  } catch (error) {
    console.error('Error submitting form:', error)
    response.value = {
      type: 'error',
      message: 'An error occurred while submitting the form. Please try again.'
    }
  } finally {
    isSubmitting.value = false
  }
}
</script>

<template>
  <div class="w-full max-w-md mx-auto">
    <div v-if="response.type === 'success'" class="p-4 mb-4 text-sm rounded-md bg-green-50 text-green-700">
      {{ response.message }}
    </div>
    <div v-else-if="response.type === 'error'" class="p-4 mb-4 text-sm rounded-md bg-red-50 text-red-700">
      {{ response.message }}
    </div>

    <form @submit.prevent="handleSubmit" class="space-y-4">
      <!-- Honeypot field to prevent spam -->
      <input
        type="text"
        v-model="formData.honeypot"
        style="display: none"
      />

      <div>
        <label for="name" class="block text-sm font-medium mb-1">Name</label>
        <input
          id="name"
          v-model="formData.name"
          type="text"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <div>
        <label for="email" class="block text-sm font-medium mb-1">Email</label>
        <input
          id="email"
          v-model="formData.email"
          type="email"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <div>
        <label for="message" class="block text-sm font-medium mb-1">Message</label>
        <textarea
          id="message"
          v-model="formData.message"
          rows="4"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        ></textarea>
      </div>

      <button
        type="submit"
        :disabled="isSubmitting"
        class="w-full px-4 py-2 text-white bg-blue-600 rounded-md hover:bg-blue-700 disabled:opacity-50"
      >
        {{ isSubmitting ? 'Sending...' : 'Send Message' }}
      </button>
    </form>
  </div>
</template>
```

### Use the Form Component in Your Page

```vue
<!-- pages/contact.vue -->
<script setup lang="ts">
definePageMeta({
  title: 'Contact Us',
  description: 'Get in touch with our team'
})
</script>

<template>
  <div class="container mx-auto py-12">
    <h1 class="text-3xl font-bold mb-8 text-center">Contact Us</h1>
    <ContactForm />
  </div>
</template>
```

## Enhanced Integration with reCAPTCHA

For better protection against spam and bot submissions, we can add Google reCAPTCHA to our form. First, we need to install the Vue reCAPTCHA package:

```bash
npm install vue-recaptcha@latest
```

### Contact Form with reCAPTCHA

```vue
<!-- components/ContactFormWithRecaptcha.vue -->
<script setup lang="ts">
import { ref, onMounted } from 'vue'
import VueRecaptcha from 'vue-recaptcha'

// Add reCAPTCHA script to the document
onMounted(() => {
  if (!document.getElementById('recaptcha-script')) {
    const script = document.createElement('script')
    script.id = 'recaptcha-script'
    script.src = 'https://www.google.com/recaptcha/api.js?onload=onRecaptchaLoaded&render=explicit'
    script.async = true
    script.defer = true
    document.head.appendChild(script)
  }
})

const formData = ref({
  name: '',
  email: '',
  message: '',
  subject: 'Contact Form Submission',
  honeypot: '',
  replyTo: '@',
  apiKey: 'YOUR_API_KEY', // Replace with your actual apiKey
  'g-recaptcha-response': '' // Will be filled by the reCAPTCHA
})

const response = ref({
  type: '',
  message: ''
})

const isSubmitting = ref(false)
const recaptchaInstance = ref(null)

const onRecaptchaVerified = (token: string) => {
  formData.value['g-recaptcha-response'] = token
}

const onRecaptchaExpired = () => {
  formData.value['g-recaptcha-response'] = ''
}

const resetRecaptcha = () => {
  if (recaptchaInstance.value) {
    recaptchaInstance.value.reset()
  }
}

const handleSubmit = async () => {
  if (!formData.value['g-recaptcha-response']) {
    response.value = {
      type: 'error',
      message: 'Please complete the reCAPTCHA verification.'
    }
    return
  }

  isSubmitting.value = true
  
  try {
    const res = await fetch('https://api.staticforms.dev/submit', {
      method: 'POST',
      body: JSON.stringify(formData.value),
      headers: { 'Content-Type': 'application/json' }
    })

    const json = await res.json()

    if (json.success) {
      response.value = {
        type: 'success',
        message: 'Thank you for your message! We\'ll get back to you soon.'
      }
      // Reset form fields
      formData.value.name = ''
      formData.value.email = ''
      formData.value.message = ''
      formData.value['g-recaptcha-response'] = ''
      resetRecaptcha()
    } else {
      response.value = {
        type: 'error',
        message: json.error || 'An error occurred. Please try again.'
      }
      resetRecaptcha()
    }
  } catch (error) {
    console.error('Error submitting form:', error)
    response.value = {
      type: 'error',
      message: 'An error occurred while submitting the form. Please try again.'
    }
    resetRecaptcha()
  } finally {
    isSubmitting.value = false
  }
}
</script>

<template>
  <div class="w-full max-w-md mx-auto">
    <div v-if="response.type === 'success'" class="p-4 mb-4 text-sm rounded-md bg-green-50 text-green-700">
      {{ response.message }}
    </div>
    <div v-else-if="response.type === 'error'" class="p-4 mb-4 text-sm rounded-md bg-red-50 text-red-700">
      {{ response.message }}
    </div>

    <form @submit.prevent="handleSubmit" class="space-y-4">
      <!-- Honeypot field to prevent spam -->
      <input
        type="text"
        v-model="formData.honeypot"
        style="display: none"
      />

      <div>
        <label for="name" class="block text-sm font-medium mb-1">Name</label>
        <input
          id="name"
          v-model="formData.name"
          type="text"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <div>
        <label for="email" class="block text-sm font-medium mb-1">Email</label>
        <input
          id="email"
          v-model="formData.email"
          type="email"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <div>
        <label for="message" class="block text-sm font-medium mb-1">Message</label>
        <textarea
          id="message"
          v-model="formData.message"
          rows="4"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        ></textarea>
      </div>

      <div class="mb-4">
        <vue-recaptcha
          ref="recaptchaInstance"
          :sitekey="'YOUR_RECAPTCHA_SITE_KEY'"
          @verify="onRecaptchaVerified"
          @expired="onRecaptchaExpired"
        />
      </div>

      <button
        type="submit"
        :disabled="isSubmitting"
        class="w-full px-4 py-2 text-white bg-blue-600 rounded-md hover:bg-blue-700 disabled:opacity-50"
      >
        {{ isSubmitting ? 'Sending...' : 'Send Message' }}
      </button>
    </form>
  </div>
</template>
```

### Using the reCAPTCHA Form Component

```vue
<!-- pages/contact-secure.vue -->
<script setup lang="ts">
definePageMeta({
  title: 'Secure Contact Form',
  description: 'Contact us using our secure form with reCAPTCHA protection'
})
</script>

<template>
  <div class="container mx-auto py-12">
    <h1 class="text-3xl font-bold mb-8 text-center">Secure Contact Form</h1>
    <p class="text-center mb-8">This form is protected by reCAPTCHA to prevent spam submissions.</p>
    <ContactFormWithRecaptcha />
  </div>
</template>
```

## Using Nuxt.js Composition API for Form Reusability

For larger applications, you might want to extract the form logic into a composable function for better reusability:

```typescript
// composables/useStaticForm.ts
import { ref } from 'vue'

export default function useStaticForm(initialData: any = {}) {
  const formData = ref({
    name: '',
    email: '',
    message: '',
    subject: 'Contact Form Submission',
    honeypot: '',
    replyTo: '@',
    apiKey: 'YOUR_API_KEY', // Replace with your actual apiKey
    ...initialData
  })

  const response = ref({
    type: '',
    message: ''
  })

  const isSubmitting = ref(false)

  const submitForm = async () => {
    isSubmitting.value = true
    
    try {
      const res = await fetch('https://api.staticforms.dev/submit', {
        method: 'POST',
        body: JSON.stringify(formData.value),
        headers: { 'Content-Type': 'application/json' }
      })

      const json = await res.json()

      if (json.success) {
        response.value = {
          type: 'success',
          message: 'Thank you for your message! We\'ll get back to you soon.'
        }
        // Reset certain fields but keep configuration
        const { apiKey, subject, replyTo, honeypot } = formData.value
        formData.value = {
          name: '',
          email: '',
          message: '',
          subject,
          honeypot,
          replyTo,
          apiKey
        }
        return true
      } else {
        response.value = {
          type: 'error',
          message: json.error || 'An error occurred. Please try again.'
        }
        return false
      }
    } catch (error) {
      console.error('Error submitting form:', error)
      response.value = {
        type: 'error',
        message: 'An error occurred while submitting the form. Please try again.'
      }
      return false
    } finally {
      isSubmitting.value = false
    }
  }

  const resetForm = () => {
    const { apiKey, subject, replyTo, honeypot } = formData.value
    formData.value = {
      name: '',
      email: '',
      message: '',
      subject,
      honeypot,
      replyTo,
      apiKey
    }
    response.value = { type: '', message: '' }
  }

  return {
    formData,
    response,
    isSubmitting,
    submitForm,
    resetForm
  }
}
```

You can then use this composable in any component:

```vue
<!-- components/NewsletterSignup.vue -->
<script setup lang="ts">
import useStaticForm from '~/composables/useStaticForm'

const { formData, response, isSubmitting, submitForm } = useStaticForm({
  subject: 'Newsletter Signup',
  apiKey: 'YOUR_API_KEY' // Replace with your actual apiKey
})

const handleSubmit = async () => {
  await submitForm()
}
</script>

<template>
  <div class="newsletter-form">
    <div v-if="response.type === 'success'" class="p-4 mb-4 text-sm rounded-md bg-green-50 text-green-700">
      {{ response.message }}
    </div>
    <div v-else-if="response.type === 'error'" class="p-4 mb-4 text-sm rounded-md bg-red-50 text-red-700">
      {{ response.message }}
    </div>

    <form @submit.prevent="handleSubmit" class="space-y-4">
      <div>
        <label for="name" class="block text-sm font-medium mb-1">Name</label>
        <input
          id="name"
          v-model="formData.name"
          type="text"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <div>
        <label for="email" class="block text-sm font-medium mb-1">Email</label>
        <input
          id="email"
          v-model="formData.email"
          type="email"
          class="w-full px-3 py-2 border border-gray-300 rounded-md"
          required
        />
      </div>

      <button
        type="submit"
        :disabled="isSubmitting"
        class="w-full px-4 py-2 text-white bg-blue-600 rounded-md hover:bg-blue-700 disabled:opacity-50"
      >
        {{ isSubmitting ? 'Submitting...' : 'Subscribe to Newsletter' }}
      </button>
    </form>
  </div>
</template>
```

## Environment Variables in Nuxt.js

For better security, you should store your Static Forms API key as an environment variable:

1. Add to your `nuxt.config.ts`:

```typescript
export default defineNuxtConfig({
  runtimeConfig: {
    public: {
      staticformsKey: process.env.STATICFORMS_API_KEY || ''
    }
  }
})
```

2. Create a `.env` file in your project root:

```
STATICFORMS_API_KEY=your_api_key_here
```

3. Access it in your components or composables using `useRuntimeConfig`:

```typescript
const config = useRuntimeConfig()
const apiKey = config.public.staticformsKey
```

## Conclusion

Integrating Static Forms with Nuxt.js provides a simple, effective solution for handling form submissions in static sites without setting up a backend server. Whether you use the basic implementation or enhance it with reCAPTCHA for extra security, Static Forms makes the process straightforward.

For more information about Static Forms, check out our [getting started guide](/blog/getting-started-with-static-forms) or explore other integration examples for different frameworks, such as our [Next.js integration tutorial](/blog/using-staticforms-with-nextjs).

Remember that the free tier has some limitations, but it's perfect for most personal projects and small business websites. For larger projects with higher submission volumes, consider the Starter plan at $6/month (or $4/month billed annually), which raises you to 3,000 submissions a month and adds file uploads, webhooks, and advanced CAPTCHA.

Happy coding with Nuxt.js and Static Forms!

---

## Introducing New Plans and Policies for Static Forms

Source: https://www.staticforms.dev/blog/introducing-new-plans-and-policies  
Date: 2025-04-19  
Author: Static Forms Team

*Update: this post describes the plans as they were announced in April 2025. Static Forms now has four plans — Free, Starter ($6/month, or $4/month billed annually), Pro ($9/month) and Agency ($19/month). See [pricing](/pricing) for the current line-up and limits.*

We're excited to announce significant updates to Static Forms plans and policies, designed to better serve our growing user base while maintaining the security and reliability you've come to expect.

## What's Changing?

### Free, Pro, and Advanced Plans

We've introduced a structured approach to our service with three distinct plans:

- **Free Plan**: Includes a generous usage allowance suitable for most personal projects and small to medium websites
- **Pro Plan**: Designed for higher volume needs, offering increased limits and additional features
- **Advanced Plan**: Built for high-volume teams that need significantly higher limits and priority support

**Good news**: All existing accounts are automatically enrolled in the Free plan, which includes enough capacity for the majority of our users.

### Extended Grace Period

We understand that transitioning to a new pricing model requires time and planning. To ensure a smooth transition, we're providing an extended grace period:

- If your usage exceeds the Free plan threshold, your service will continue uninterrupted until **April 30, 2025**
- Starting May 2025, if you exceed the Free plan limits, email sending will pause for the remainder of that month until you upgrade to a paid plan

This gives you nearly a full year to evaluate your needs and make any necessary adjustments.

### reCAPTCHA Is Now Optional

Based on your valuable feedback, we've made reCAPTCHA integration optional for all users:

- You can now choose whether to implement reCAPTCHA on your forms
- It will only become mandatory if we detect spam submissions from your form
- If spam is detected, you'll have 14 days to configure reCAPTCHA

This change provides more flexibility in how you design and implement your forms while still maintaining robust protection when needed.

## Why These Changes?

These updates are the result of extensive user feedback and our commitment to providing a sustainable, high-quality service:

1. **Better resource allocation**: By introducing tiered plans, we can optimize resources for different usage patterns
2. **Improved spam prevention**: Our targeted approach to reCAPTCHA implementation focuses security measures where they're most needed
3. **Sustainable growth**: These changes help ensure we can continue to provide reliable service and develop new features

## What You Need to Do

For most users, no immediate action is required. Here's what we recommend:

1. **Check your current usage**: Log in to your dashboard to see how your usage compares to the Free plan limits
2. **Review plan options**: Familiarize yourself with the different plans to determine which best fits your needs
3. **Consider your reCAPTCHA strategy**: Decide whether to implement reCAPTCHA proactively or wait until needed

## Plan Comparison

> **Note:** this table shows the plans as they stood in April 2025. The current line-up is Free, Starter ($6/month, or $48/year — $4/month billed annually), Pro ($9/month) and Agency ($19/month) — see [pricing](/pricing) for today's plans and limits.

| Feature | Free Plan | Pro Plan | Advanced Plan |
|---------|-----------|----------|---------------|
| Monthly submissions | 500 | 25,000 | 200,000 |
| Priority support | ✗ | ✓ | ✓ |
| Price | $0 | $9/month | $35/month |

## Looking Forward

These changes represent an important step in our journey to provide the best form handling solution for static websites. We're committed to continuing to improve Static Forms based on your feedback and needs.

We're grateful for your ongoing support and trust in our service. As always, our team is available to answer any questions or provide assistance during this transition.

For more information or if you have any questions, please don't hesitate to reach out to our support team.

---

We look forward to continuing to serve your form handling needs and are excited about the future of Static Forms!

---

## Using Static Forms with Next.js: A Complete Guide

Source: https://www.staticforms.dev/blog/using-staticforms-with-nextjs  
Date: 2025-04-19  
Author: Static Forms Team

Are you building a Next.js application and need a simple way to handle form submissions without setting up a backend server? Static Forms is the perfect solution for collecting form data from your site and receiving submissions directly in your inbox.

In this guide, we'll explore how to integrate the Static Forms service with your Next.js application, including both basic implementation and enhanced security with reCAPTCHA. If you're using Nuxt.js instead, check out our [Nuxt.js integration guide](/blog/using-staticforms-with-nuxtjs).

> **Prefer a working project?** The [complete Next.js example](https://github.com/static-forms/static-forms-examples/tree/main/apps/next-example) is on GitHub and deploys to Vercel in one click. It's one of [13 framework examples](https://github.com/static-forms/static-forms-examples) covering Next.js, Nuxt, SvelteKit, Astro, Angular and more.

## What is Static Forms?

Static Forms is a form backend for your website, and static sites need no server of their own to use it. It allows you to receive form submissions via email without writing any server-side code. This is particularly useful for:

- Contact forms
- Feedback forms
- Newsletter signups
- Simple data collection

The service is free to use (with some limitations) and provides a straightforward API for integrating forms into your static website.

## Getting Started with Static Forms

Before implementing forms in your Next.js app, you'll need to:

1. Visit [staticforms.dev](https://www.staticforms.dev)
2. Register for a free account
3. Obtain your unique API key

This API key will be used to connect your forms to your Static Forms account, ensuring submissions are forwarded to your email address.

## Basic Integration in Next.js

Let's start by implementing a simple contact form without reCAPTCHA. This approach is quick to set up but offers less protection against spam.

### Create a Client Component for Your Form

```tsx
// app/components/contact-form.tsx
"use client";

import { useState } from "react";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Textarea } from "@/components/ui/textarea";

export default function ContactForm() {
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: "",
    subject: "Contact Form Submission", // Default subject
    honeypot: "", // Anti-spam field
    replyTo: "@", // This will set replyTo to the email provided
    apiKey: "YOUR_API_KEY" // Replace with your actual API key
  });

  const [response, setResponse] = useState({
    type: "",
    message: ""
  });

  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
    setFormData({
      ...formData,
      [e.target.name]: e.target.value
    });
  };

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setIsSubmitting(true);
    
    try {
      const res = await fetch("https://api.staticforms.dev/submit", {
        method: "POST",
        body: JSON.stringify(formData),
        headers: { "Content-Type": "application/json" }
      });

      const json = await res.json();

      if (json.success) {
        setResponse({
          type: "success",
          message: "Thank you for your message! We'll get back to you soon."
        });
        // Reset form fields
        setFormData({
          ...formData,
          name: "",
          email: "",
          message: ""
        });
      } else {
        setResponse({
          type: "error",
          message: json.message || "An error occurred. Please try again."
        });
      }
    } catch (error) {
      console.error("Error submitting form:", error);
      setResponse({
        type: "error",
        message: "An error occurred while submitting the form. Please try again."
      });
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="w-full max-w-md mx-auto">
      {response.type === "success" ? (
        <div className="p-4 mb-4 text-sm rounded-md bg-green-50 text-green-700">
          {response.message}
        </div>
      ) : response.type === "error" ? (
        <div className="p-4 mb-4 text-sm rounded-md bg-red-50 text-red-700">
          {response.message}
        </div>
      ) : null}

      <form onSubmit={handleSubmit} className="space-y-4">
        {/* Honeypot field to prevent spam */}
        <input
          type="text"
          name="honeypot"
          style={{ display: "none" }}
          onChange={handleChange}
        />

        <div>
          <label htmlFor="name" className="block text-sm font-medium mb-1">
            Name
          </label>
          <Input
            id="name"
            name="name"
            type="text"
            value={formData.name}
            onChange={handleChange}
            required
          />
        </div>

        <div>
          <label htmlFor="email" className="block text-sm font-medium mb-1">
            Email
          </label>
          <Input
            id="email"
            name="email"
            type="email"
            value={formData.email}
            onChange={handleChange}
            required
          />
        </div>

        <div>
          <label htmlFor="message" className="block text-sm font-medium mb-1">
            Message
          </label>
          <Textarea
            id="message"
            name="message"
            rows={4}
            value={formData.message}
            onChange={handleChange}
            required
          />
        </div>

        <Button
          type="submit"
          disabled={isSubmitting}
          className="w-full"
        >
          {isSubmitting ? "Sending..." : "Send Message"}
        </Button>
      </form>
    </div>
  );
}
```

### Use the Form Component in Your Page

```tsx
// app/contact/page.tsx
import ContactForm from "@/app/components/contact-form";

export const metadata = {
  title: "Contact Us",
  description: "Get in touch with our team"
};

export default function ContactPage() {
  return (
    <div className="container mx-auto py-12">
      <h1 className="text-3xl font-bold mb-8 text-center">Contact Us</h1>
      <ContactForm />
    </div>
  );
}
```

## Enhanced Integration with reCAPTCHA

For better protection against spam and bot submissions, we can add Google reCAPTCHA to our form. This requires a few additional steps:

1. Register for reCAPTCHA at [Google reCAPTCHA](https://www.google.com/recaptcha/admin) and get your site key
2. Add the reCAPTCHA component to your form

### Contact Form with reCAPTCHA

```tsx
// app/components/contact-form-with-recaptcha.tsx
"use client";

import { useState, useRef } from "react";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Textarea } from "@/components/ui/textarea";
import ReCAPTCHA from "react-google-recaptcha";

export default function ContactFormWithRecaptcha() {
  const recaptchaRef = useRef<ReCAPTCHA>(null);
  
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: "",
    subject: "Contact Form Submission",
    honeypot: "",
    replyTo: "@",
    apiKey: "YOUR_API_KEY", // Replace with your actual API key
    "g-recaptcha-response": "" // Will be filled programmatically
  });

  const [response, setResponse] = useState({
    type: "",
    message: ""
  });

  const [isSubmitting, setIsSubmitting] = useState(false);

  const handleChange = (e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
    setFormData({
      ...formData,
      [e.target.name]: e.target.value
    });
  };

  const handleRecaptchaChange = (token: string | null) => {
    setFormData({
      ...formData,
      "g-recaptcha-response": token || ""
    });
  };

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setIsSubmitting(true);
    
    try {
      // Execute reCAPTCHA and wait for the token
      let token = formData["g-recaptcha-response"];
      if (recaptchaRef.current && !token) {
        token = await recaptchaRef.current.executeAsync();
      }
      
      if (!token) {
        setResponse({
          type: "error",
          message: "Please complete the reCAPTCHA verification."
        });
        setIsSubmitting(false);
        return;
      }

      const submitData = {
        ...formData,
        "g-recaptcha-response": token
      };

      const res = await fetch("https://api.staticforms.dev/submit", {
        method: "POST",
        body: JSON.stringify(submitData),
        headers: { "Content-Type": "application/json" }
      });

      const json = await res.json();

      if (json.success) {
        setResponse({
          type: "success",
          message: "Thank you for your message! We'll get back to you soon."
        });
        // Reset form fields
        setFormData({
          ...formData,
          name: "",
          email: "",
          message: "",
          "g-recaptcha-response": ""
        });
        // Reset reCAPTCHA
        if (recaptchaRef.current) {
          recaptchaRef.current.reset();
        }
      } else {
        setResponse({
          type: "error",
          message: json.message || "An error occurred. Please try again."
        });
      }
    } catch (error) {
      console.error("Error submitting form:", error);
      setResponse({
        type: "error",
        message: "An error occurred while submitting the form. Please try again."
      });
    } finally {
      setIsSubmitting(false);
    }
  };

  return (
    <div className="w-full max-w-md mx-auto">
      {response.type === "success" ? (
        <div className="p-4 mb-4 text-sm rounded-md bg-green-50 text-green-700">
          {response.message}
        </div>
      ) : response.type === "error" ? (
        <div className="p-4 mb-4 text-sm rounded-md bg-red-50 text-red-700">
          {response.message}
        </div>
      ) : null}

      <form onSubmit={handleSubmit} className="space-y-4">
        {/* Honeypot field to prevent spam */}
        <input
          type="text"
          name="honeypot"
          style={{ display: "none" }}
          onChange={handleChange}
        />

        {/* Invisible reCAPTCHA */}
        <ReCAPTCHA
          ref={recaptchaRef}
          size="invisible"
          sitekey="YOUR_RECAPTCHA_SITE_KEY" // Replace with your reCAPTCHA site key
          onChange={handleRecaptchaChange}
        />

        <div>
          <label htmlFor="name" className="block text-sm font-medium mb-1">
            Name
          </label>
          <Input
            id="name"
            name="name"
            type="text"
            value={formData.name}
            onChange={handleChange}
            required
          />
        </div>

        <div>
          <label htmlFor="email" className="block text-sm font-medium mb-1">
            Email
          </label>
          <Input
            id="email"
            name="email"
            type="email"
            value={formData.email}
            onChange={handleChange}
            required
          />
        </div>

        <div>
          <label htmlFor="message" className="block text-sm font-medium mb-1">
            Message
          </label>
          <Textarea
            id="message"
            name="message"
            rows={4}
            value={formData.message}
            onChange={handleChange}
            required
          />
        </div>

        <Button
          type="submit"
          disabled={isSubmitting}
          className="w-full"
        >
          {isSubmitting ? "Sending..." : "Send Message"}
        </Button>
      </form>
    </div>
  );
}
```

### Installing Required Dependencies

Don't forget to install the necessary packages:

```bash
npm install react-google-recaptcha
# or
bun add react-google-recaptcha
```

## Using Environment Variables for API Keys

For better security, it's recommended to use environment variables for your API keys instead of hardcoding them in your components:

1. Create a `.env.local` file in your project root:

```
NEXT_PUBLIC_STATICFORMS_API_KEY=your_staticforms_api_key
NEXT_PUBLIC_RECAPTCHA_SITE_KEY=your_recaptcha_site_key
```

2. Update your components to use these environment variables:

```tsx
// In your form component
apiKey: process.env.NEXT_PUBLIC_STATICFORMS_API_KEY
```

```tsx
// In your reCAPTCHA component
sitekey={process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY}
```

## Advanced Configuration Options

Static Forms offers several additional configuration options for enhancing your forms:

### Custom Success/Error Redirects

You can specify custom URLs to redirect users after form submission:

```tsx
const [formData, setFormData] = useState({
  // ...other fields
  redirectTo: "https://yoursite.com/thank-you",
  apiKey: "YOUR_API_KEY"
});
```

### Custom Fields

You can add custom fields to your form by prefixing the field name with `$`:

```tsx
<div>
  <label htmlFor="company" className="block text-sm font-medium mb-1">
    Company
  </label>
  <Input
    id="company"
    name="$company" // Note the $ prefix
    type="text"
    value={formData.$company}
    onChange={handleChange}
  />
</div>
```

## Troubleshooting Common Issues

### Form Submissions Not Received

If you're not receiving form submissions:

1. Double-check your API key is correct
2. Make sure your email address is verified with Static Forms
3. Check your spam folder

### reCAPTCHA Not Working

If reCAPTCHA isn't functioning properly:

1. Verify your site key is correct
2. Ensure your domain is listed in the reCAPTCHA admin console
3. Check for any JavaScript errors in the console

## Conclusion

Integrating Static Forms with Next.js provides a simple, effective solution for handling form submissions in static sites without setting up a backend server. Whether you use the basic implementation or enhance it with reCAPTCHA for extra security, Static Forms makes the process straightforward.

For more information about Static Forms, check out our [getting started guide](/blog/getting-started-with-static-forms) or explore other integration examples for different frameworks, such as our [Nuxt.js integration tutorial](/blog/using-staticforms-with-nuxtjs).

Remember that the free tier has some limitations, but it's perfect for most personal projects and small business websites. For larger projects with higher submission volumes, consider the Starter plan at $6/month (or $4/month billed annually), which raises you to 3,000 submissions a month and adds file uploads, webhooks, and advanced CAPTCHA.

Happy coding with Next.js and Static Forms!

---

## Understanding reCAPTCHA Integration with Static Forms

Source: https://www.staticforms.dev/blog/understanding-recaptcha  
Date: 2025-04-02  
Author: Static Forms Team

Protecting your forms from spam and bot submissions is essential for maintaining the quality of your form data. In this guide, we'll explore how to effectively integrate Google reCAPTCHA with Static Forms to secure your forms without compromising user experience.

## Why Use reCAPTCHA?

reCAPTCHA offers several advantages for form protection:

- **Bot Detection**: Effectively identifies and blocks automated submissions
- **User Experience**: Modern versions (reCAPTCHA v3) can work invisibly without user interaction
- **Accessibility**: Provides audio alternatives for users with visual impairments
- **Adaptability**: Adjusts security levels based on user behavior

## Setting Up reCAPTCHA

### Step 1: Get Your reCAPTCHA Keys

1. Go to the [Google reCAPTCHA Admin Console](https://www.google.com/recaptcha/admin)
2. Sign in with your Google account
3. Click on the "+" icon to create a new site registration
4. Choose the reCAPTCHA type (v2 "I'm not a robot" Checkbox is recommended for most uses)
5. Add your domains (the sites where the reCAPTCHA widget will run)
6. Accept the Terms of Service and click "Submit"
7. You'll receive a **Site Key** and a **Secret Key** - you'll need both

### Step 2: Configure Your Form

Add the reCAPTCHA script to your page's `<head>` section:

```html
<head>
  <!-- Other head elements -->
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>
```

Then add the reCAPTCHA widget to your form:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Your regular form fields -->
  
  <!-- reCAPTCHA widget -->
  <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>
  
  <!-- Static Forms configuration -->
  <input type="hidden" name="apiKey" value="YOUR_API_KEY">
  
  <button type="submit">Submit</button>
</form>
```

Be sure to replace:
- `YOUR_SITE_KEY` with your reCAPTCHA Site Key
- `YOUR_API_KEY` with your Static Forms API key

> **Important**: Your reCAPTCHA Secret Key should be configured in your [Static Forms dashboard](https://www.staticforms.dev/app/forms), never in client-side code.

## Best Practices

### Position the CAPTCHA Strategically

Place the reCAPTCHA widget near your submit button to ensure users complete it before submission. This reduces form abandonment due to confusion about the submission process.

### Style the Widget to Match Your Site

While you can't completely customize the reCAPTCHA widget, you can adjust its theme to match your site's design:

```html
<div class="g-recaptcha" 
     data-sitekey="YOUR_SITE_KEY" 
     data-theme="dark">
</div>
```

Choose between `light` (default) and `dark` themes.

### Monitor Effectiveness

After implementing reCAPTCHA, monitor your form submissions to ensure:

1. Legitimate users aren't being blocked
2. Spam submissions have decreased
3. The user experience remains smooth

### Consider Invisible reCAPTCHA for Advanced Cases

If you want to minimize user friction even further, consider using reCAPTCHA v3 or the invisible version of v2. These versions don't require direct user interaction but might require additional JavaScript implementation.

## reCAPTCHA v3 (Paid Plans)

On the Starter plan and up, Static Forms also supports reCAPTCHA v3, which provides invisible bot detection without requiring user interaction. Key differences:

| Feature | v2 | v3 (Paid Plans) |
|---------|----|----------|
| User Interaction | Required (checkbox) | None (invisible) |
| User Experience | Some friction | Completely seamless |
| Detection Method | Challenge-based | Score-based (0.0-1.0) |
| Availability | All users | Starter plan and above |

For more information on implementing reCAPTCHA v3, see our [reCAPTCHA v3 guide](/blog/recaptcha-v3-for-pro-users). If you'd rather not depend on Google, [Cloudflare Turnstile best practices](/blog/cloudflare-turnstile-best-practices) covers an invisible alternative, also on the Starter plan and above.

## Troubleshooting Common Issues

### The reCAPTCHA Widget Doesn't Appear

- Verify that the Google reCAPTCHA script is properly loaded
- Check for JavaScript console errors
- Ensure your site key is correct

### Form Submissions Are Rejected

- Confirm your Secret Key is correct in the form configuration
- Make sure users are completing the CAPTCHA challenge
- Verify that your domain is properly registered in the reCAPTCHA console

### Users Report Difficulty Completing CAPTCHAs

- Ensure the widget is visible and not obscured by other elements
- Consider switching to a less strict CAPTCHA type
- Provide clear instructions for users

## Conclusion

Integrating reCAPTCHA with Static Forms provides an effective defense against spam while maintaining a good user experience. By following the steps and best practices outlined in this guide, you can secure your forms without adding unnecessary friction to the submission process.

At Static Forms, we're committed to helping you balance security and usability. Our integration with Google reCAPTCHA is designed to be simple yet effective, giving you peace of mind without compromising on user experience.

Remember, for accounts where we detect significant spam activity, reCAPTCHA will be automatically required to ensure the continued quality of your form submissions.

---

## Getting Started with Static Forms

Source: https://www.staticforms.dev/blog/getting-started-with-static-forms  
Date: 2025-04-01  
Author: Static Forms Team

Static Forms provides a simple and reliable way to handle form submissions on your website, static or not, without any server-side code. In this guide, we'll walk you through setting up your first form with Static Forms.

> **Using a framework?** The [Static Forms examples repo](https://github.com/static-forms/static-forms-examples) has a ready-to-deploy contact form for 13 frameworks, including Next.js, Nuxt, React, Vue, SvelteKit, Astro, Angular, React Router, SolidStart, Qwik, Gatsby, Eleventy and plain HTML. Each one has a one-click Deploy to Vercel button.

## Prerequisites

Before you begin, you'll need:

- A static website (HTML, Gatsby, Next.js, etc.)
- A Static Forms account (sign up for free)
- Your API key from the dashboard

## Step 1: Create a Basic HTML Form

First, let's create a basic HTML form that we'll integrate with Static Forms. Add the following to your HTML:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <input type="text" name="name" placeholder="Your Name" required>
  <input type="email" name="email" placeholder="Your Email" required>
  <textarea name="message" placeholder="Your Message" required></textarea>
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  <button type="submit">Send Message</button>
</form>
```

Make sure to replace `YOUR_API_KEY_HERE` with your actual API key from the Static Forms dashboard.

## Step 2: Add reCAPTCHA Protection

To protect your form from spam, we recommend adding reCAPTCHA validation:

```html
<head>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>

<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Form fields from Step 1 -->
  
  <!-- Add reCAPTCHA -->
  <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
  
  <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
  <button type="submit">Send Message</button>
</form>
```

**reCAPTCHA v2 vs v3:**
- **v2** (shown above): Requires user to check "I'm not a robot" box. Available for all users.
- **v3**: Invisible verification, no user interaction. Available from the Starter plan up ($6/month, or $4/month billed annually). See our [reCAPTCHA v3 guide](/blog/recaptcha-v3-for-pro-users) for details.

## Step 3: Customize the Form Behavior

Static Forms allows you to customize the behavior of your form with additional hidden fields:

```html
<form action="https://api.staticforms.dev/submit" method="POST">
  <!-- Form fields from previous steps -->
  
  <!-- Customize form behavior -->
  <input type="hidden" name="subject" value="New Contact Form Submission">
  <input type="hidden" name="replyTo" value="@"> <!-- Use the email from the form -->
  <input type="hidden" name="redirectTo" value="https://yourwebsite.com/thank-you">
  
  <button type="submit">Send Message</button>
</form>
```

## Testing Your Form

Once you've integrated your form, you should test it to make sure everything works as expected:

1. Fill out the form with valid information
2. Complete the reCAPTCHA challenge (if enabled)
3. Submit the form
4. Check your email for the form submission

## Troubleshooting

If you're not receiving form submissions, check the following:

- Verify your API key is correct
- Make sure your reCAPTCHA keys are valid (if using reCAPTCHA)
- Check that all required form fields are present
- Look for any JavaScript errors in your browser console

## Next Steps

Now that you have your basic form working, you might want to explore more advanced features of Static Forms:

- **File Attachments**: Allow users to upload files with their submissions (Starter plan and up)
- **Custom Redirects**: Send users to different pages based on form data
- **Advanced Spam Protection**: Additional layers of protection for your forms

---

## Code Example: Complete Contact Form

Here's a complete example of a contact form with all the features mentioned above:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Contact Us</title>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
  <style>
    form {
      max-width: 500px;
      margin: 0 auto;
    }
    input, textarea, button {
      display: block;
      width: 100%;
      margin-bottom: 15px;
      padding: 10px;
    }
    button {
      background: #fe5b5b;
      color: white;
      border: none;
      cursor: pointer;
    }
  </style>
</head>
<body>
  <h1>Contact Us</h1>
  
  <form action="https://api.staticforms.dev/submit" method="POST">
    <input type="text" name="name" placeholder="Your Name" required>
    <input type="email" name="email" placeholder="Your Email" required>
    <input type="text" name="subject" placeholder="Subject" required>
    <textarea name="message" placeholder="Your Message" rows="5" required></textarea>
    
    <div class="g-recaptcha" data-sitekey="YOUR_RECAPTCHA_SITE_KEY"></div>
    
    <!-- Hidden fields -->
    <input type="hidden" name="apiKey" value="YOUR_API_KEY_HERE">
    <input type="hidden" name="replyTo" value="@">
    <input type="hidden" name="redirectTo" value="https://yourwebsite.com/thank-you">
    
    <button type="submit">Send Message</button>
  </form>
</body>
</html>
```

We hope this guide has been helpful in getting you started with Static Forms! If you have any questions or need assistance, don't hesitate to [contact our support team](/contact).

---