Webflow form not submitting? Work through these eight causes in order

Establish what "not submitting" means first

Before diagnosing, work out which of these you have, because they have almost nothing in common:

1. The success message never appears — the submit does something, but the form doesn't confirm.
2. Success appears, but no submission arrives — the form is happy; delivery is broken.
3. Nothing happens at all on click.
4. It works on the staging domain but not the live one, or vice versa.

Open your browser console (F12 → Console) and submit once. Then open the Network tab and submit again, watching for a request. Those two observations narrow it to a couple of causes immediately: a console error means JavaScript; no network request at all means the form isn't wired; a request that 4xx/5xxs means the endpoint.

Now work down the list. It's ordered by how often each turns out to be the actual cause, not by how interesting it is.

1. The form isn't on a Webflow-hosted site

Webflow's form handling is a hosting feature. Export your site's code and host it elsewhere, and the form posts into nothing — Webflow's endpoint isn't there any more.

This catches people who exported to Netlify or Vercel for performance and didn't realise forms came along as markup only. Symptom: the form appears to submit, no submission ever arrives, and nothing is wrong with the markup.

Fix: point the form at your own endpoint (Netlify Forms, Formspree, a serverless function), or keep the site on Webflow hosting.

2. Missing or duplicated form structure

Webflow's form is a specific arrangement: a Form Block containing a <form>, plus separate success and error divs. Delete or replace parts of it and behaviour degrades in confusing ways.

Common versions:

• The success and error states were deleted because they looked untidy in the Designer. Submission works; nothing confirms it.
• The <form> was replaced with a plain div by pasting custom markup.
• Two forms on one page share an identical name. Webflow uses the name to group submissions, and identical names produce mixed-up or missing data.

Fix: rebuild the form from Webflow's Form Block component and give each form a distinct name in Settings.

3. A required field the visitor can't see

A required field hidden with display: none — or hidden inside a closed step of a multi-step form, or off-screen at a smaller breakpoint — blocks submission. The browser refuses to submit and tries to focus the invalid field, which it cannot show. On some browsers you get a console message; on others, nothing.

This is the most common cause of "nothing happens at all", and it's especially common after someone hides a field for one breakpoint only.

Fix: find it programmatically rather than by eye:

document.querySelectorAll('form [required]').forEach(el => {
  const visible = el.offsetParent !== null;
  if (!visible) console.warn('Hidden required field:', el.name || el.id, el);
});

Then either remove required or genuinely remove the field.

4. Custom code hijacking submit

Any script calling preventDefault() on the form's submit event stops Webflow's own handler. Usually this is deliberate — someone wired the form to a CRM or a webhook — and then the custom handler throws an error partway through, so neither path completes.

Symptom: console error on submit, no network request to Webflow.

Fix: check every script that touches the form. If you're posting somewhere yourself, own the whole flow: show your own success state, handle errors, and don't rely on Webflow's UI. If you want both, submit to your endpoint and let the native submission proceed.

5. The submission limit for the plan is exhausted

Form submissions are capped per site plan, and they reset monthly. On a free or Starter site the allowance is small enough to hit during testing alone. Once exhausted, submissions are rejected.

Symptom that gives it away: it worked last week and stopped, with no code change.

Fix: check Site Settings → Forms for your usage, and note that submissions still count while you're testing. Test with a handful, not fifty.

6. Spam protection rejecting real people

If reCAPTCHA is on the form, a failed challenge blocks submission — and reCAPTCHA fails silently more often than people expect: aggressive privacy extensions, blocked third-party scripts, corporate networks, or an unconfigured site key after a domain change.

Turnstile-based bot protection at site level can produce the same effect for a small share of visitors.

Fix: temporarily remove the captcha and test. If submissions start working, the challenge is your problem, not the form. Consider a honeypot instead — a hidden field bots fill and humans never see. It stops the large majority of bot traffic with zero user-facing cost and no third-party script. Webflow documents the technique directly.

7. File upload rejected

The file upload field has a size limit — 10MB by default. A visitor attaching a 12MB photo from their phone gets a rejection, and the messaging is not always obvious enough for them to understand what went wrong.

Symptom: works for you, fails for some visitors, correlates with mobile.

Fix: state the limit next to the field, in text, before they choose a file. If you genuinely need large files, don't fight the form — use a dedicated upload service and pass the resulting URL through a hidden field.

8. The redirect goes somewhere broken

If the form is set to redirect on success rather than show an inline message, and the redirect URL is wrong, the submission is recorded but the visitor lands on a 404 and reasonably concludes it failed. Your submissions list will show entries; your users will tell you the form is broken. Both are true.

Fix: check Form Settings → Redirect URL, and actually click through it.

When it works locally but not live

A category of its own, worth separating:

• Staging vs production keys. reCAPTCHA site keys are domain-bound; a key registered for yoursite.webflow.io fails on yoursite.com.
• Not republished. Form changes need a publish. Editing in the Designer changes nothing live until you publish.
• Cached page. Your CDN may be serving an older version of the page with the older form markup. Hard-refresh, or purge.

After you've fixed it

Two things worth doing once, so the next failure is loud instead of silent.

Connect submissions to somewhere you actually look. Webflow stores them and emails a notification, and those notifications reliably end up filtered. Send them to Slack, a CRM, or a shared inbox someone owns.

Submit a real test monthly. A form that's been quietly broken for six weeks is a much more expensive problem than one broken for a day, and forms break from the outside — an expired key, a plan limit, a changed redirect — not just from edits you made.

Sources: Webflow: prevent spam in form submissions · Webflow: honeypot technique · Webflow: form submissions