Jotform form not submitting: find the cause

A form checks its fields when the visitor presses Submit. If a required field is empty, or holds an answer the form rejects, the press is refused and the error appears on that field. On a long form the field can sit far above the button, and on a phone it can be off the screen. A question that appears only after one answer is easy to miss on the way down. The visitor sees nothing change because the error is out of view, cannot find the box that needs fixing, and does not write to you. They close the tab, and your entries stay flat.

• Open each conditional question, note which answer shows it, and check whether the field under it is still required.
• Press Submit with the form empty and note the first field that shows an error, and whether it is on screen.
• Open the browser console on the press and look for a failed request to the form's submission address.
• Check the form's settings for a closed state or a limit on the number of entries.
• Check the form on a phone too, since a field can sit off the screen there and still block the submit.

The visitor fills the fields, presses Submit, and waits. The button may spin for a moment and return to normal. The page may scroll to an error, or it may not move at all, and the error can sit under a field near the top of a long form. Some visitors see nothing, because the error is off the screen and the page shows no other sign that the press failed. The person who built the form does not see this, because they already know which answers open the hidden questions and they fill the form in the same order every time.

Start with the questions that a condition hides or shows. Pick each answer that opens or closes a question, and check whether any required mark is still on a field the visitor cannot see. A closed or limited form shows a different state: the visitor sees a closed message in place of the form, or the form refuses the press with no reason given. A blocked embed shows in the console as a request that never leaves the page, or a script that was refused. Check them in that order, because the first one is the cheapest to rule out.

The simulated visitor fills each field it can see, presses Submit, and records the step where the submit stopped. The report gives you that step, a screenshot of the error or the silence, and any script error or failed request recorded there. The run sees only the public page, so it cannot tell you whether an entry reached your inbox or your spreadsheet. A form that sends a confirmation email to the address typed in it can reach the simulated visitor's inbox, so the report can show that step.

Forms get edited after they go live. A new question, a changed condition or a new required field can block the submit for an answer nobody tested. After each edit, run the same visitors through every answer path, including the path with hidden fields, before you share the link again.