Why is my form not submitting: find the step

Most forms that stop submitting fail before any request leaves the browser. A required field is empty or hidden, so the browser blocks the send and tries to show its message on a field the visitor cannot see. A script that runs on page load can fail partway, which means the handler that catches the click was never attached, and the button falls back to doing nothing. A form can also post to an address that changed in the last release, or to a form service that an ad blocker cancels. The owner usually tests on a laptop, signed in, with the fields already filled, so the form looks fine.

• Press Send with the Network tab open. Is there a request to the form's address at all?
• Leave one required field empty, press Send, and check that a message appears beside that field.
• Read the Console on page load for a red error. A script that fails early stops the submit handler from attaching.
• Does the form's address still exist? A moved address returns an error or a blank page.
• Turn off extensions and try a private window. A blocked request never reaches your server.

A submit can stop at three points, and each leaves a different trace. Before the request, the browser checks the required fields and may block the send. During the request, the browser passes the data to the form's address, and the network can refuse or cancel it. After the request, the server answers, and the page either shows the answer or ignores it. A visitor sees the same silence at all three points, which is why the owner cannot tell them apart by looking at the button. Each point leaves its own trace, and the trace is what you read in the browser.

Open the developer tools before you press Send, and keep the Network tab visible. If no request to the form's address appears, the submit stopped before the send, so look at the Console and at the required fields. If a request appears with a status such as 404 or 500, the address or the server is the problem, and the response usually names the cause. If the request is listed as blocked or cancelled, an extension or an ad blocker stopped it. Test once in a private window with extensions turned off, so the answer is clear.

A required field inside a closed panel, an accordion, a tab, or a later step the visitor has not reached is the most common silent failure. The browser refuses to submit, looks for the field to show its message, and cannot focus it because it is hidden. Chrome's Console can name the control it could not focus. Open the form, expand every section, and press Send with each field empty in turn. The first empty field that stays hidden is the one to fix, usually by moving it out of the closed panel or by showing its message as text near the button.

Your own test is weak evidence here, because your browser remembers the fields, you are signed in, and your extensions allow requests that a stranger's browser may block. A simulated visitor starts from an empty form, arrives from a search or an ad, and types the way a first-time visitor types. The run records failed app requests and JavaScript errors on the step where they happen, so the report shows the step where the run stopped, the error recorded there and a screenshot, with a fix prompt you can paste into a coding agent. If the form leads to a confirmation email, the visitor's inbox can receive it.

Signup flow testing

A form that works today can stop after the next release, when someone adds a required field, renames an input or moves the address it posts to. Rerun the same simulated visitors after each change to see who got past the form. If the form sits behind a login, test it with a test account, and check each preview deploy before it reaches the live site.