How Many Fields Should a Contact Form Have?

Count the fields on your contact form. If the number is above five, most of them were chosen for a reason nobody wrote down: a sales manager wanted company size, an old CRM insisted on a job title, a marketing tool asked for consent to a programme that never launched. What you are looking at is sediment, not design.

The defensible number of contact form fields is the number you can justify one at a time, starting from a question almost nobody asks out loud: what do we need in order to reply at all? Everything past that answer is a trade, and every trade costs you a share of the people who were, a moment ago, about to write to you.

This is not an argument for a two-field form on every site. Some enquiries genuinely need routing, and a form that produces unusable enquiries has failed as completely as one nobody submits. It is an argument for justification: each field earns its place out loud, in front of somebody who is allowed to say no.

One thing before the detail. Form design sits downstream of a decision most teams have not actually made, which is what an enquiry is for. If nobody can say what happens in the twenty minutes after a submission arrives, the field list gets decided by whoever asks loudest, and it will keep growing.

Start from what you need in order to reply

Two things. A way to reach the person, and enough of what they want that your first response is not "could you tell us a bit more?". That is the floor. For a large number of sites it is also the ceiling.

In practice that means an email address and a message box. A name is a third field most teams treat as free, and it very nearly is: people expect it, it costs one line, and it makes the reply readable. Past those three you have stopped collecting what you need in order to reply. You are collecting what you would like to know, which comes out of a different budget.

The cost of a field is not spread evenly, either. It lands hardest on the people you most want to hear from: somebody on a phone, at the end of a working day, with one specific question and half a minute of patience. A redesign that converts worse than the page it replaced has quite often done nothing except add two fields and a consent checkbox to a form that used to work.

Every field after that has to earn its place

Here is the test we apply, and it works best said aloud with the person who requested the field. A field stays only if it passes all four.

1. It changes what happens next. Not what gets reported. What happens: who reads the enquiry, how quickly, and what they say first. If the honest answer is "it fills a column", that is a report you can build later, not a question to ask a stranger now.
2. The person can answer it without thinking. Anything needing a decision, a lookup or a guess is a field people abandon rather than get wrong. Budget range is the classic: most people genuinely do not know yet, and the ones who do are unwilling to say so first.
3. You cannot get it another way. Company size, sector and seniority are often knowable from the email domain and thirty seconds of looking. Asking a stranger to do your research is a poor trade for the enquiries it costs you.
4. Somebody will still own it in six months. Fields outlive the people who request them. An unowned field sits there long after the campaign that needed it ended, quietly reducing submissions on a page nobody is reviewing.

The fields that usually pass

A short list, and shorter than most forms imply. One routing question, phrased the way a visitor would phrase it rather than the way your organisation is structured: what is this about? Four or five options, one of them "something else". That single field frequently replaces three demographic ones, because it does the actual job of getting the enquiry to the right person while it is still warm.

A timing question earns its place where scheduling is the real constraint. A file upload earns it where work cannot begin without an artefact. And on product and interface work, a single link field ("where can we see it?") replaces several paragraphs of typed description and costs nothing when it is left blank.

The fields that almost never do

• Phone number, when nobody intends to call. Widely abandoned, widely collected out of habit, and rarely dialled by anybody once it arrives.
• Company size and revenue band. A qualification question aimed at your sales process, answered by a stranger with no reason to be accurate about it.
• Job title as free text. It arrives as a hundred spellings of the same six roles, and somebody cleans it by hand forever.
• How did you hear about us? Well-meant attribution, answered badly at the moment of peak impatience. Ask it in the reply, where it becomes a conversation instead of a tax.
• A confirm-email field. It does not catch typos, because people paste. It does add a step, and it irritates the people who did it right.

None of those are forbidden. They are simply expensive, and the expense is invisible because you never meet the people who closed the tab. That asymmetry is the reason field lists only ever grow: adding one produces a visible column, and removing one produces nothing anybody can point at in a meeting.

Every field is a question you ask a stranger before you have told them anything useful in return.

Required, optional, and the asterisk that lies

Most forms mark five fields required and mean two. That is not a labelling slip, it is a tactic: mark everything required and everything comes back full. It works in the narrow sense that the columns populate. It also converts hesitation into abandonment, because a required field somebody cannot answer honestly leaves them two choices, and you will not enjoy either of them.

Our rule is blunt. A field is required only if you would genuinely refuse the enquiry without it. Everything else is optional and says so in words, not with a symbol whose meaning half your visitors have to infer. Where optional fields are the minority, label those instead of labelling the required ones, which removes an entire class of misreading for the cost of a few words.

And do not enforce a shape you cannot predict. Postcodes and phone formats vary by country and by decade, and a validation rule written against one of them rejects real people holding real numbers. The input types and autocomplete attributes in the HTML standard do more good than any pattern you can write: they let the browser fill the field correctly in the first place, which beats telling somebody their own address is invalid.

Progressive disclosure, and where it backfires

The tempting answer to a long form is to hide most of it. Show three fields, reveal the rest once somebody has committed. Sometimes that is right. Often it is a way of keeping fields that should have been cut, and it brings failures of its own.

Disclosure works when the later fields genuinely depend on an earlier answer. Somebody selects "careers" and gets a different second step from somebody who selects "support". That is branching rather than hiding, and it shortens the form for everyone, because nobody has to read past the questions that do not apply to them.

Disclosure fails when it disguises length. People who cannot see the end of a task judge badly whether to start it, and a form that grows as you type feels evasive even when it is not. It also breaks in the two places nobody tests: with a keyboard, where focus lands somewhere unexpected after a reveal, and with a screen reader, where new fields appear with no announcement at all. We wrote about what a keyboard user experiences because this class of defect is invisible to the person who built it and obvious to the person who cannot get past it.

Error handling that does not blame the person

Every form has an error state, and most error states were written in ten minutes at the end of the build. This is the highest ratio of effort to outcome anywhere in the form, because somebody seeing an error has already decided to give you their details and is now being told they did it wrong.

When to validate

Not on every keystroke. Telling somebody their email address is invalid while they are typing the second character is technically accurate and socially rude. Validate a field when the person leaves it, and validate the whole form on submit. Once a field is already in error, then check as they type, because at that point the feedback is a repair rather than an accusation.

What to say, and where to say it

Errors belong next to the field they concern, in text, and they say what to do rather than what went wrong. "Enter an email address so we can reply" beats "Invalid input" every time. Never use colour alone: a red border communicates nothing to somebody who cannot distinguish it, which is why WCAG 2.2 asks that errors be identified in text and described in a way that helps a person correct them.

Wire each message to its field with aria-describedby so it is announced when focus arrives, and move focus to the first error on a failed submit instead of leaving somebody to hunt for the red one. Resist adding ARIA to elements that are already semantic: a real label and a native input carry most of this without help. The accessibility you build in by default is always cheaper than the version retrofitted after an audit, and the standard we publish on our accessibility page applies to a contact form as much as to a page of prose.

What happens after submit is part of the form

The field count gets all the attention and the confirmation gets none. "Thanks, we will be in touch" tells a person nothing they can act on and gives them no way to know whether it worked. Say what happens next, who reads it, and roughly when. If there is a reference, show the reference.

The other half of after-submit is internal. A form nobody answers within a working day is a slower version of having no form. That is an operations problem rather than a design one, and it deserves settling before anybody argues about field counts, because it decides whether the enquiry was worth collecting at all. It is also where an apparent conversion problem turns out to have been a process problem wearing a nicer jacket.

When a form is the wrong instrument

A good share of what arrives through contact forms is not an enquiry at all. It is a question the site already answers: do you work with companies our size, do you do this in our country, what does a project like ours involve. Those people did not want a conversation. They wanted one fact, and the form was the only door they could find.

That argues for better answers rather than a shorter form. A lightweight widget that gives website-informed answers and carries contact and conversion actions in the same place, as Flidu does, can absorb the factual traffic and leave the form for enquiries that genuinely need a person. The real design work sits in the handover: recognising the moment an answer stops being enough and passing the conversation on without making somebody repeat themselves. Our parent company covers that moment in when an answer is not enough.

One condition attaches to all of that. Where an automated answer is involved, say so plainly at the point of contact rather than in a footer nobody reads, and never let a visitor believe they have reached a person when they have not. We treat that as a design requirement rather than a compliance one, and the wording is covered in how a chatbot should tell visitors it is not a person.

So, the number

Three on most marketing sites: name, email, message. Four when routing genuinely saves time on both sides, with the routing question written in the visitor’s language rather than yours. Anything above five needs a reason you would be willing to defend to the person who abandoned the form, and "the CRM has a column for it" is not that reason.

Now the honest exception. On high-consideration services where every submission consumes an hour of a senior person’s time, a longer form is a legitimate filter, and the fields that feel rude are doing useful work. If that is your situation, say so on the page. "We ask a few extra questions so the right person answers you" buys a surprising amount of patience, and it converts an obstacle into an explanation.

The opposite exception is worth naming too. On a page somebody reached from one specific offer, the form should be shorter than your standard, because you already know why they are there. Running one identical form across every page is tidy and slightly wrong. If you want a second read on a particular form, including the conversion work around it, send us the page and tell us what happens to an enquiry after it lands.