What is a form submission?

What happens when somebody presses submit

The browser gathers every answer and sends it to a server in a single request, almost always a POST. The HTTP standard describes that method in almost exactly these terms, listing the fields entered into an HTML form among the blocks of data POST exists to deliver to a data handling process. The server then checks the answers, stores them, and replies so the page can show a confirmation. Every one of those steps can fail independently. A dropped connection means the answers never arrived; a rejected check means they arrived and were refused; a stored record with a failed confirmation means the person thinks it did not work and tries again. A submission, strictly, is the stored record, not the button press.

Why the server has to check again

Anything a browser enforces can be skipped by somebody sending the request directly, so a form that only validates in the page is trusting the person at the other end. MDN puts the rule bluntly: all data that comes to a server must be checked and sanitised, always. That is why a well built form checks the same things twice, once in the browser to help the person fix a mistake quickly, and once on the server to decide whether the record is accepted at all. It also explains a confusing experience for respondents, where a form that looked complete is rejected on submit because a rule only the server knows about has not been met.

Counting submissions honestly

A count of submissions is not a count of people. The same person may send a form twice because the confirmation was slow, a team may share one login, and the owner may have sent five test copies while building it. Before reporting a number, remove test rows, look for near duplicates a few minutes apart from the same name or email, and decide whether a person who submitted twice counts once. For surveys, write that rule down before the results come in, so the decision cannot drift towards whichever count looks better. The same discipline applies to spam, which should be removed by a stated rule rather than by eye.

Submissions and a changing form

A submission only makes sense next to the questions it answered. If a form is edited after it goes live, the earlier submissions were given to different wording, and sometimes to different options. A tool that records which version of the form each submission came from lets you separate the two groups later; one that does not leaves you reconstructing the change from memory. Keep a short log of what changed and when, even with version tracking, because the reason for a change rarely survives in the data. When the answers are analysed, treat each version as its own group first and combine them only for questions whose wording and options did not move. A question that changed from four options to five cannot be merged into one chart without explaining what the fifth option absorbed, and a reader will reasonably assume the change in results is real unless the chart says otherwise.

What a submission becomes in the form builder

When a form is submitted, the server checks that required answers are present, text lengths and number ranges are within their limits, and choice answers are among the field's options, then stores the answers with the time submitted and the version number of the form. It does not store an IP address, browser details or the respondent's account. The submission appears as one row in the responses table, where it can be downloaded as a PDF or deleted, and the CSV export writes Submitted At first with one column per field. After it is stored, any add-ons run: the webhook posts once, the email alert goes to its one address, and e-signing starts if the form uses it.

Questions people ask