Why is my Webflow form not submitting?

Every article on this lists the same dozen possible causes and leaves you to work through them, which is the slow way. Almost all of these failures fall into three groups, and two checks in the browser tell you which group you are in before you change anything. Do the diagnosis first. It takes about a minute and it stops you disabling scripts and rebuilding the form to fix something that turned out to be a setting.

How do you find out which problem you have?

Open the browser developer tools and submit the form twice, watching a different panel each time. On the first submission watch the console: an error appearing at the moment you click means JavaScript is interrupting the submission. On the second, watch the network panel: if no request appears at all, the form is not wired to submit anything, and if a request appears but comes back with an error status, the form is working and the endpoint receiving it is not. Those three outcomes point at three completely different sets of causes, and knowing which one you have removes most of the checklist immediately.

The form is not attempting to submit, which is almost always a structural issue in the Designer rather than a bug. The most common cause is that the button inside the form is a plain button element rather than a submit button, which looks identical on the page and does nothing when clicked. The next most common is a required field that is hidden, perhaps inside a step that is not currently visible, because the browser refuses to submit while a required field it cannot show is empty. After those, check that the fields are actually inside the form element rather than sitting next to it, which happens easily when a layout is rearranged.

The console shows an error. What is causing it?

Usually custom code, either yours or something a tool injected, interfering with the script that handles submission. Anything that attaches its own handler to the form, prevents the default behaviour, or throws an error before Webflow's own code runs will stop the submission silently from the visitor's point of view. Test by removing custom code from the page temporarily and submitting again, then reintroducing it a piece at a time. Third-party widgets are worth suspecting early, particularly anything that manipulates the page after load, because they are the code most likely to be present without anyone remembering adding it.

The request is sent but comes back as an error. Why?

The form is fine and something about where it is posting is not. A custom form action is the first thing to check, because setting one tells Webflow the submission is going somewhere else, so it stops processing it and stops sending notifications. Next is whether the site has exceeded its plan's submission allowance for the month, which produces a rejection rather than a warning on the page. Then look at anything sitting between the browser and the endpoint: a lapsed certificate, or a content security policy strict enough to block the request, both produce this shape of failure while everything on the page looks normal.

It submits, but the notification email never arrives. Where did it go?

This is a different problem from a form that does not submit, and it is worth separating because the fixes share nothing. Check the submissions list in the site settings first: if the entry is there, the form worked and only the notification failed, which points at the email path rather than the form. From there the usual causes are a notification address that was never set or was set on a different form, filtering at the receiving end, or a sending domain that has not been verified. The submissions list is the fact; the email is a convenience layered on top of it.

It works for me but not for a visitor. What is different?

Usually spam filtering, or the fact that you are testing somewhere the visitor is not. Automated protection blocks submissions that look machine-generated, and a genuine visitor writing in unusual phrasing, or sending from a network with a poor reputation, can be caught by it. Test with plain, ordinary content before concluding the form is broken. The other common gap is that you are testing on a staging domain while visitors are on the live one, or testing while logged in to the site. Reproduce the visitor's conditions exactly, in a private window, on the real domain, before debugging anything else.

Why did the form stop working after I exported the site?

Because form handling is a hosting service rather than part of the exported code, so the form now posts to nothing. The markup comes with you and looks complete, which is what makes this confusing: the form renders, accepts input and appears to submit. What is missing is the thing that was receiving it, and that stayed behind. Any exported site needs its own form handling arranged, whether that is a small endpoint you write, a hosted form service or your framework's own handler. Check this before moving a site rather than after, because the failure is invisible until somebody mentions they never heard back.