Form Validation Rules That Stop Bad Data Before It Reaches You

Short answer: validation is about whether a real person's answer is usable, and the three rules worth adding first are phone format, email shape, and a considered required-versus-optional pass. As of September 2026 BotForms attaches auto-validation rules when it generates a form, on every plan from $29/month — but the business-specific rules are still yours to add.

There is a category of lost revenue that never appears in any dashboard: the customer who filled in your form properly, typed one digit too few in their phone number, and became a submission you cannot answer. No error was raised. No spam filter triggered. The lead simply arrived unusable and you had no way to know whether it was a real enquiry.

Validation is the cheapest fix in form design and the one most often skipped, because a form without it looks like it works.

Validation is not spam protection

These get conflated constantly and they are unrelated problems.

Spam protection answers "is this a person?" It deals with bots, scrapers and injected content. The submissions it catches are ones you never wanted. Getting it wrong in the strict direction blocks real customers silently, which is why the approaches that do not punish honest submitters are worth understanding — stopping contact form spam without a CAPTCHA covers those.

Validation answers "is this answer usable?" It deals with typos, misunderstandings and missing context from people who genuinely want to hear from you. The submissions it catches are ones you very much wanted, arriving broken.

A form can have excellent spam protection and still be quietly losing a tenth of its real leads to a mistyped digit.

The rules that earn their place

Not every field needs a rule. These are the ones that pay for themselves on almost any lead form.

Field	Rule worth having	What it catches	Trap to avoid
Phone	Digit count within a sensible range, common separators allowed	Missing digits, letters typed into the field	Hard-coding one country's format
Email	Shape check plus a nudge on obvious domain typos	gmial.com, missing the domain entirely	Rejecting valid but unusual addresses
Postcode or ZIP	Format for the regions you serve	Half-typed codes, wrong-country entries	Blocking anything outside a whitelist without saying so
Date	Range bounded by your actual availability	Requests for last Tuesday, or three years out	Rejecting the far future when it might be genuine
Description	Minimum sensible length	Single-word answers you cannot quote from	Setting the minimum so high people give up
Number of units, rooms, vehicles	Positive integers within a plausible range	Zeros, decimals, obvious mis-keys	Capping so low that real large jobs bounce

The theme running through the right-hand column: validate for shape, not for truth. You can check that a phone number has a plausible number of digits. You cannot check that it is the person's number, and trying will cost you more than it saves.

Required versus optional is a validation decision

The most consequential validation rule on any form is which fields are mandatory, and it is usually decided by accident.

Every required field is a place someone can stop. Every optional field is a piece of information you will often not get. The correct question for each field is not "would this be useful?" — everything is useful — but "would I refuse to act on this submission without it?"

For most lead forms the honest answer is: name, one way to contact them, and one line about what they want — the field set built out in how to build an AI lead capture form. Everything else is nice to have and should be optional, because a partial lead you can call beats a complete one that was abandoned at field nine.

This is also where a generated form set needs the most editing. Drafting tools tend toward completeness, marking more fields required than a human would, which is one of the specific over-collection patterns in what AI gets wrong when it writes form questions. The volume effect is real: form length and required-field count are the two levers that move drop-off most, as reducing form abandonment sets out.

Timing and wording

Two implementation details do most of the perceived-quality work.

Validate when focus leaves the field. Per-keystroke validation shows an error on the second character of an email address, which reads as being told off for typing. Submit-only validation means the person scrolls back up a form hunting for red. Checking as the person moves on is the pattern that annoys the fewest people.

Say what is expected, not what is wrong. "Invalid input" is a dead end. "Include the area code, for example 817 555 0142" tells the person exactly what to do. Keep the message beside the field, and keep everything they already typed — a form that clears itself on a failed submit converts approximately nobody on the second attempt.

The rules only you can write

Generated validation handles the generic layer well. What it cannot know is your operating reality, and these are usually the rules that prevent the most expensive mistakes:

Service area. If a postcode outside your coverage should not book, that is a rule. Better still, it is a rule with a helpful message rather than a rejection — telling someone you do not cover their area is a better outcome than taking a booking you have to cancel.

Lead time. An appointment request for two hours from now, when you need a day's notice, is a validation problem being solved later by an awkward phone call.

Capacity and plausibility. A quantity field that accepts 9,999 will eventually receive it. A sensible upper bound with a "for larger jobs, call us" message routes that enquiry correctly instead of dropping it into the same queue as a two-room job.

Mutually dependent fields. If choosing "commercial" makes a company name necessary, that is conditional logic doing validation work — and it is a better experience than showing the field to everyone. This is the same machinery as multi-step forms that adapt to answers, applied to correctness rather than to length.

Validation cannot save a badly designed question

Worth saying, because a lot of effort gets spent in the wrong place. A perfectly validated field asking an ambiguous question produces perfectly formatted useless answers.

"When would you like this done?" validated as a date still produces a date the person picked at random because they assumed you would call to arrange it. "What is the issue?" validated to a twenty-character minimum still produces "it is broken" plus filler. The fix for those is the wording of the question, not a rule attached to it. Validation is the last line, not the first.

The same applies to the fields you intend to analyse later. A free-text field with a length rule is still free text, and still ungroupable in a spreadsheet — the reasons to constrain it at source are in exporting form submissions to CSV and Excel.

An audit you can do this afternoon

Pull the last fifty submissions from your main form and mark each one:

Actionable as submitted. Actionable after a follow-up. Not actionable at all.

Then look only at the second and third groups and note which field failed. In practice one or two fields account for nearly everything — most often the phone number, and most often because the form accepted anything.

Fix those fields, then re-run the same count in a month. It is a twenty-minute exercise that surfaces more recoverable revenue than most conversion work, because these are leads that already wanted to buy.

Getting started

BotForms attaches auto-validation rules when it generates a form from a description, including field type detection, on every plan from $29/month. The business-specific rules — service area, lead time, plausible ranges — are the ones to add by hand afterwards, and they are the ones that pay.

See features for the builder and its logic options, pricing for plan limits, or start a 30-day trial.