Form submission error: find the rule it breaks

The form checks what it can see. The server checks more: a phone format, a length limit, a file size, a security token that has expired. When the server rejects a value, most forms return one generic message, so the visitor gets the same box for every rejection. The visitor changes what they think is wrong, presses Send, and gets the box again, because the value they changed was not the one that failed. Inputs that look normal to you can still break a rule, such as a leading plus sign, an accent in a name, or a long pasted address.

• Open the Network tab, press Send, and read the status code on the request to the form's address.
• Does the response body name a field? A list of field names points to a rule that rejected those values.
• Try a phone number with spaces, a plus sign and a country code. Does the error change?
• Leave the form open a long time, then submit. A stale security token can be rejected even when the values are correct.
• Is the same error text used for every failure? If yes, the visitor cannot tell what to change.

The error box appears on every press, and it looks the same whatever went wrong. The visitor corrects something they think is wrong, presses Send again, and gets the same box. After a few tries they stop. The owner sees a run of attempts in the server log with no matching lead. Because the message is generic, the visitor cannot tell whether the problem was the phone number, a missing field, a file that was too large or the server itself. The form is doing what it was built to do, and the way it reports failure hides the reason.

Open the Network tab, press Send once, and click the request to the form's address. The status code and the response body tell you which kind of failure you have. A 400 or 422 with a list of field names means the server rejected specific values, so the fix is a rule or a message. A 413 means the request was too large, usually because of a file attachment. A 403 means the server refused the whole request, which often points to a security token that was not accepted. A 500 means the server failed while handling the request, so changing the values will not help.

The wrong message is 'Something went wrong. Please try again.' It repeats after every press and names nothing. The right message is 'Phone number: remove the letters. Spaces, dashes and a leading plus are fine.' It sits beside the phone field, so the visitor knows which box and which rule. Do the same for a file box: 'This file is too large to send. Choose a smaller PDF' beside the upload, not one general line under the button. A message that names the field also tells you which rule to check first in the code.

Test website before launch

A form loaded in one tab and submitted much later can carry a security token that the server has since replaced or expired. The visitor sees the same generic error each time, because the token in the page never changes. Reloading the page fixes it, but a visitor who does not know to reload stays stuck. Fix it in the form: issue a fresh token when the page is loaded or when the form is focused, and when the server reports a stale token, show a message that asks the visitor to refresh the page and keeps the values they typed.

A rule added in one release, such as a stricter phone format or a shorter field limit, can reject values that passed last month. Rerun the same simulated visitors after each change, including visitors who type the awkward inputs: a leading plus, a space, an accent in the name. If the form sits behind a login, test it with a test account, and check each preview deploy before it goes live.