Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Why cutting fields is the most overrated fix, and what actually changes how many people finish your form.
Most contact form advice tells you to cut fields. Three is the magic number, apparently, and anything past that is friction. Our own quote form asks for six things.
You may not agree with this one. Field count is a nearly exhausted lever. The evidence behind "cut it to three" is over a decade old, it came mostly from newsletter signups and lead magnets rather than business enquiries, and several later tests found that removing fields made conversion worse rather than better. What actually moves the number is which fields you ask for, how you label them, and whether the form matches the size of the thing you're asking someone to do.
So this article is about the form itself: the fields, the labels, the validation, the mobile behaviour, the spam handling, and the page it sits on.
It assumes people are already reaching your form. If they're not, that's a different problem, and seven reasons people don't get in touch covers that one.
Eight things to fix, roughly in the order worth doing them.
The advice traces back to a HubSpot study from 2012, which found that cutting a form from four fields to three lifted completion by around 50%. That's a real finding, and it has been repeated more or less continuously for the fourteen years since.
The part that rarely gets repeated is the rest of the same data. Returns fell away sharply past three fields, and the forms being measured were mostly newsletter signups and download gates. Nobody was asking those people to describe a project.
Then there's the counter-evidence, which is more interesting than the original. Conversion consultant Michael Aagaard stripped fields out of a client's form expecting a lift and got a 14% drop instead. His own explanation was blunt: he'd removed the fields people actually wanted to fill in and left behind the ones they didn't. He put them back, rewrote the labels instead of deleting anything, and conversion went up 19.21%.
Venture Harbour published a study in 2021 finding that reducing fields could cost as much as 14.23%. And a 2026 review of the whole body of evidence concluded that field count is a saturated lever: multiple tests over the past decade produced lifts under 5%, and several found that cutting fields actively hurt, because a form asking almost nothing starts to read as suspiciously low-commitment.
That last point is the one worth sitting with. Context decides all of this. Someone handing over an email address for a PDF wants the smallest possible form. Someone about to spend $3,000 on a website is running a completely different calculation, and a form that asks them nothing at all can read as careless rather than considerate.
Which is why our own quote form asks for six things and we've no plans to cut it back. The levers that actually matter are underneath the field count: which fields you choose, how you label them, and whether the shape of the form matches the size of the ask.
Here's the test that settles your field list. Write out the reply you'd want to send to a good enquiry. Then look at what you had to know in order to write it. That's your form.
Most forms get built the other way round, starting from what would be handy to have in the CRM later. It's how you end up asking for company size and job title on an enquiry about a five-page website.
Ours asks for six things because a useful first reply needs six things: who they are, two ways to reach them, roughly what they want built, roughly what they can spend, and what the project actually is. Take any one of those out and the reply turns into a question instead of an answer, which costs both of us two days.
There's a catch buried in the "what do you want built" field, though, and it's the one most people miss. Plenty of visitors genuinely don't know whether they need a landing page, a full website or a Shopify store. Making them choose forces a guess, and guessing wrong in front of a company you're about to hire is uncomfortable enough that some of them just close the tab.
So the last option in ours reads "Not sure — help me decide."
It keeps the field, keeps the answer useful when people can give one, and removes the only real reason to abandon it.
The highest-return change in that whole body of research wasn't removing anything. It was rewriting the labels.
A label has one job beyond naming the field, and that's answering the question the visitor is quietly asking: why do you want to know that? Every field where the answer isn't obvious creates a small pause, and the pauses add up.
Instead of | Try |
Budget | Budget range — a rough figure is fine, it helps us suggest the right approach |
Phone | WhatsApp number — required, so we can send project updates without a week of email |
Message | What are you trying to build or fix? A few lines is plenty |
Company | Company name — so we can look at your current site before replying |
None of that removes a field. It removes the reason somebody stalls on one.
Two practical notes worth having. Keep the explanation short enough to sit under the field. If it genuinely needs more than a line, a tooltip is a reasonable home for the long version. But the part that removes hesitation has to stay visible without a click. That a field is optional, or what you'll do with the answer, can't live behind an icon, because icons mostly don't get opened. Short hint visible, detail in the tooltip.
One caveat if you go that way: make sure the tooltip opens on tap, not only on hover. Hover doesn't exist on a phone, and that's where most of your enquiries are coming from.
And don't use the placeholder as the label. Placeholder text disappears the moment someone starts typing, which takes the instruction away at exactly the point they need it, and screen readers treat it inconsistently. Label above, hint below, and a placeholder only if you want to show an example.
Requiring a phone number is probably the most reliably expensive single decision on a contact form. The figures people quote vary widely. An old Unbounce number puts the dip at around 5%, other reports claim far steeper drops, so treat it as directional rather than precise. The direction holds even when the size doesn't.
The mechanism isn't complicated. A required phone number reads as we are going to ring you. Someone who was weighing up whether to enquire about a website is now also weighing up an unscheduled sales call, and for a decent number of people that settles it.
Which is why the standard advice is to make it optional, and for most businesses that advice is right.
Ours does the opposite, and the reasoning is the part worth taking. We require a WhatsApp number and leave email optional. Our projects run on WhatsApp: build updates, a quick question about a logo file, a screenshot that needs a yes or no. Doing each of those by email adds a day. So the number isn't there so we can sell to someone. It's the channel the work actually happens on, and requiring it reflects how we operate rather than how we'd like to follow up.
The rule underneath both versions is the same. Don't require a number by default. If you do require one, say what it's for, right next to the field. "So we can send project updates without a week of email" is a reason. An asterisk and nothing else is a threat.
Worth checking while you're in there: don't ask for a phone number and a WhatsApp number as two separate fields. Pick the one you'll actually use.
Let me save you some money. If your contact form has six fields, you don't need a multi-step form, and building one will cost you time you'd be better off spending on the labels.
The numbers behind the multi-step advice are real. It's worth looking at where they came from. Venture Harbour's much-quoted jump from 0.96% to 8.1% was a consulting enquiry funnel carrying more than thirty questions across four steps. BrokerNotes went from 11% to 46% on a financial lead-generation form. The endlessly repeated "13.85% versus 4.53%" comes from the same family of long, qualification-heavy funnels.
Our security experts remove malware, fix vulnerabilities, and protect your site.
None of those are contact forms.
Zuko's testing puts an actual threshold on it. A two-step form outperforms a single page by around 14%, but only once you're past seven fields. Below that the effect is neutral or negative. Reform arrive at the same place from the other direction: for a basic contact form under five fields, single-step still wins.
So the rule is short. Under seven fields, leave it on one page. Splitting a short form adds clicks without taking anything away.
Multi-step earns its keep when later questions depend on earlier answers. A quote engine where choosing "Shopify" opens a different branch than "landing page." An equipment list where the instrument decides what else you need to know. That's not friction reduction, it's routing, and it's a genuinely different job.
If you do build one, there's a decision most guides skip: whether contact details go in step one. Marketers want them first so abandoned forms can be chased. That only pays off if you have a process that actually chases them. If you don't, an email address from someone who never finished asking their question is worth nothing, and putting the easy question first is the better trade.
Almost every form is responsive now. The fields stack, nothing overflows, and it passes inspection in a browser window dragged down to 375 pixels. Then you fill it in on an actual phone and it's miserable.
Responsive layout is about width. Input behaviour is about typing. Only one of those tends to get checked.
Four things, and together they take about ten minutes:
Set the input types. type="email" gives people the keyboard with the @ on it. type="tel" gives them the number pad. Leave everything as plain text and you've made every single field harder to complete than it needed to be.
Add autocomplete attributes. With autocomplete="name", "email" and "tel" set properly, a returning visitor fills three fields with one tap on their saved details. It's the largest reduction in typing available to you and it costs three attributes.
Keep input font size at 16px or above. Below that, iOS zooms in when the field takes focus, the layout jumps, and people lose their place. Don't solve it by disabling zoom, which breaks the page for anyone who needs to magnify anything.
Use chips or radio buttons instead of a dropdown for short lists. A dropdown holding four budget ranges is three taps and a scroll. The same four as tappable buttons is one tap, and all the options are visible at once.
Tap target sizing matters as well, but that's a whole-site problem rather than a form one, and it's covered in the wider design mistakes.
Watch somebody hit send on a form with a validation error in it. The page reloads, the fields are empty, and there's a red line at the top saying something like Invalid input. Almost nobody retypes all of it. They leave, and in your analytics it looks like an abandoned form rather than a broken one.
So the first rule is that nothing they typed ever disappears. Whatever else happens, their words stay in the boxes.
After that, check fields as people move through them rather than only when they submit, but validate when someone leaves a field rather than while they're still in it. Flagging an incomplete email address halfway through typing it is its own special kind of annoying.
Then write the errors as instructions. "Invalid email" tells someone they've failed. "This looks like it's missing an @" tells them what to do about it. Put the message beside the field it belongs to, not in a summary at the top of the page where they have to work out which box it means.
And validate in both places. We use Zod on the client and again on the server. The client check is the experience: instant, no reload, no waiting. The server check is the actual safety, because anything running in a browser can be bypassed. Doing only the first is insecure. Doing only the second means a full round trip and a page reload over a missing @.
The cheapest fix in this whole section is the button itself. Disable it while it's submitting and change the label to say so, or people press it three times and you get three copies of the same enquiry.
Image puzzles work, in the sense that they stop bots. They also stop people. Every visitor ends up paying for the bot's behaviour, in the worst possible place: after they've written their message and just before they send it.
The trade is usually the wrong way round anyway. Deleting four spam messages a day costs you five minutes. Losing a slice of your real enquiries costs considerably more than five minutes.
So the goal is to shift the cost off the visitor and onto the server. Roughly in order of effort:
A honeypot is a hidden field a person never sees and a bot fills in anyway. Anything arriving with that field completed goes straight in the bin. It's free, it's invisible, and on its own it removes most low-effort spam.
A time check catches the rest of the cheap stuff. A form submitted two seconds after it loaded wasn't filled in by a human.
Rate limiting handles volume. The same source submitting over and over gets throttled regardless of what's in the fields.
For anything past that, use a managed service rather than a puzzle. We run Arcjet with rate limiting on our own form. Cloudflare Turnstile is the common lighter-weight alternative to reCAPTCHA. Both do their checking in the background instead of asking your visitor to identify traffic lights.
None of this is airtight and some spam will still land. The question was never whether you can stop all of it. It's whether the thing you installed to stop it is costing you more than the spam was.
Most confirmation pages say "Thank you, we'll be in touch" and stop there. That page is a real piece of screen time from someone who has just decided to trust you, and it's usually wasted.
Give it three things. What happens next and roughly when. What to do if nothing arrives, which is usually a direct email address in case the reply lands in spam. And one useful thing to do in the meantime, whether that's a relevant piece of writing or a plain description of how you run projects.
Make it a real URL rather than a message swapped in where the form was. You'll want to count those submissions in analytics, and you can't count a page that doesn't exist.
Avoid dropping people straight into a booking calendar. Offer it if it helps, but a calendar that appears uninvited turns a completed enquiry back into a decision.
A dedicated contact page is worth having, and it shouldn't be the only place your form lives.
Someone who has just finished reading your Shopify page is warmer than they will be at any other point. Sending them to a general contact page means an extra click and a loss of context, and the form they land on won't know what they were reading. Put a form at the end of each service page instead, with the relevant option pre-selected if you can.
The contact page still has a job for people who navigate straight to it, usually returning visitors and referrals. It needs four things: the form, the alternatives to the form, your response time, and your location if location matters to the work.
Two things to skip. Don't lead with a large map, because maps serve people who are already coming to you, not people deciding whether to. And don't put two different forms on one page. Competing forms split attention the same way competing buttons do.
The order matters more than the individual changes. We work through the field list first, starting from the reply that needs sending, then the labels, then the mobile input behaviour, and only then the plumbing underneath.
For reference, ours ended up at six fields with WhatsApp required and email optional, Zod validating on both the client and the server, and Arcjet handling spam and rate limiting. None of that is complicated. It's just decided rather than inherited from a template.
If your form is getting traffic and not submissions, that gap is usually four or five small things rather than one big one, and it's the work we do.
What's a good contact form conversion rate?
Published benchmarks for this vary so widely that they're close to useless. The reported figures disagree by an order of magnitude, because they're measuring different form types on different traffic. Track your own rate over time instead and compare it against itself.
How many fields should my form have?
However many your first reply needs, and no more. For most service businesses that lands somewhere between four and seven. The number matters much less than whether each field explains itself.
Should I use a form builder or have one built?
If your site runs on WordPress, Framer or Webflow, the built-in or platform-native option is usually fine and it'll handle the plumbing for you. Custom is worth it when the form needs to branch, route or feed something else. We build ours because the site is a custom application anyway, not because builders are bad.
Do I need a captcha?
Start without one. A honeypot field and rate limiting will remove most of the spam, invisibly. Add a managed check like Turnstile only if something is still getting through, and don't reach for image puzzles at all.
CEO
UI/UX Designer & Founder at AppDeel | We Design & Develop SaaS, eCommerce & Business Websites with Next.js, Shopify & Webflow
Read more posts by Azizul Hakim →Google described our client's homepage as "Slide 1." Here is how design decisions quietly break SEO, and why website architecture should be planned first.
A breakdown of the fake Cloudflare verification scam hitting WordPress sites — how it hides from site owners, why security scanners miss it, and how we remove it.
How to remove malware from a WordPress site: hidden backdoors, database spam, rogue admin accounts, and a fake Cloudflare verification page.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
