A form is the last step between a visitor and an enquiry, and it is where many people stop. This guide shows how to cut the effort, fix the common faults and handle what happens after the send button.
Website forms get more submissions when they ask only for what you need to reply, label every field clearly, work properly on a phone, explain errors in plain words and confirm what happens next. Most abandoned forms fail on effort or trust: too many fields, unclear questions or no sign that the message arrived. Test on a real phone and send yourself an enquiry.
What makes website forms succeed or fail
Website forms succeed when a visitor can finish them quickly and trusts what happens next. Every field adds effort, and every unclear label adds doubt. The visitor has already decided to get in touch, so the form's job is to avoid giving them a reason to stop.
It helps to think about three moments: before they start, while they fill it in, and after they press send. Most contact form best practices belong to one of these, and so does the rest of this guide.
How many fields should a form have?
Ask only for what you need to take the next step. There is no correct number. A short enquiry form often needs a name, an email address and a message. A quote request needs more, because you cannot price a job without detail. Each extra field makes the form feel longer, so give every field a reason to exist.
Test each field with one question: what would you do differently if the answer were missing? If the answer is nothing, remove it. If you need it only sometimes, make it optional or ask for it in your reply. Keep the fields that save you time, such as a choice of service that sends the enquiry to the right person.
Fewer fields are not always better. A form that is too vague produces enquiries you cannot act on, and replying to ask the same questions makes a slower first impression. The right length depends on your business, so compare versions using real submissions rather than copying another site.
| Field | Keep it when | Think twice when |
|---|---|---|
| Full name | You address people by name | You split it into first name, last name and title |
| Email address | You reply by email | You make people type it twice |
| Phone number | You will actually call | You only ever reply by email, or you demand one local format |
| Company name | You sell to businesses | Most of your customers are individuals |
| Message or details | Always | The box is blank with no hint about what to write |
| Location | You serve certain areas or ship to certain places | You serve everyone the same way |
| Preferred way or time to reply | You offer a real choice | You always reply by email |
| Budget | You can use it to shape your reply | The visitor cannot know yet, or would rather talk first |
| File upload | You need a brief, a photograph or a document | It is optional and rarely used |
Write clear labels and instructions
Put a visible label above every field and keep it visible while the visitor types. A properly connected label means that tapping it selects the field, and screen readers announce it. Placeholder text inside the box is not a replacement. The W3C's forms tutorial notes that placeholder text disappears once someone starts typing, is often low in contrast and is not treated as a label by screen readers. web.dev's guidance on forms also advises against using placeholders as labels.
Show an example of the answer you want in a hint under the field, not inside it. Tell people early which fields are required and use the same marking throughout. Put any overall instructions before the form, so a visitor using a screen reader hears them first. Word the button as the action it performs, such as "Send message" or "Request a quote", not "Submit".
Make forms work on a phone
Most forms fail on phones in small ways that add up. Use the field types the phone understands. An email field brings up a keyboard with the @ sign, a telephone field brings up a number pad, and a field marked for numeric input avoids the full keyboard. Add autocomplete attributes so the browser can fill in name, email and phone from saved details. web.dev's guidance describes these and recommends a single name field unless you have a good reason to split it. Leave autofill switched on unless you are sure that turning it off helps the visitor.
Make every field and button large enough to tap with a thumb, with space between them, and check that the on-screen keyboard does not hide the field being typed in or the send button. Test on a real phone using mobile data, because a form that feels fine on an office computer can be awkward on a small screen. The guide to a mobile friendly website lists the wider checks.
Plan for visitors in different countries
If your audience spans countries, avoid fields that assume one. Phone numbers differ in length and layout, so accept spaces, a plus sign and a country code instead of enforcing one pattern. Addresses differ in what they call the region and the postal code, and some places have no postal code at all, so ask for an address only when you need it and let people type it freely. Names may have one part or many, and a single full name field respects that. Ask for a time zone with any callback request, and state the time zone you work in.
Do not require something that only some visitors can supply. A mandatory state or county field turns away people whose country has none. Check too that the form accepts accented letters and non-Latin writing, because customers in some regions will type their names that way.
Why do people abandon forms?
People abandon forms because the effort looks greater than the reward, because something breaks, or because they stop trusting the request. The table links common causes with fixes.
| Cause | What the visitor experiences | What to change |
|---|---|---|
| Too many fields, or no reason given for asking | The form looks like work | Remove fields, and explain why you need the sensitive ones |
| Private details asked for too early | Doubt about who will see them | Ask later, or add a short note on how you use the data |
| Vague error messages | The form refuses and gives no hint why | Name the field and say how to fix it |
| Answers lost after an error | They must start again | Keep what they typed |
| Strict formats | A phone number or postal code is rejected | Accept the usual variations |
| A hard puzzle test | They cannot pass it | Use invisible checks first and keep another route open |
| A slow or jumpy page | The layout shifts while they type | Speed the page up and reserve space for late-loading items |
| A pop-up over the form | They cannot reach the fields | Remove the overlay from form pages |
| No clear confirmation | They are unsure the message went | Show a message and send a confirmation email |
| Small targets and the wrong keyboard on a phone | Typing is awkward | Use the right field types and larger controls |
| One long block of fields | The form looks endless | Group related fields under headings, or split into steps |
How to write error messages
An error message should say what went wrong and how to fix it, next to the field it concerns. "Enter an email address in the format name@example.com" helps. "Invalid input" does not. Do not rely on colour alone to show an error. Add text, and for longer forms put a short summary at the top. Keep the visitor's answers in place when the page reloads.
Check inputs on the server as well as in the browser. Browser checks give quick feedback, but they can be bypassed or may not run, so the server must decide what is acceptable.
Should I use a multi-step form?
Use steps when a long form really has separate parts, such as a quote request that asks about the job first and the contact details second. Show progress, let people go back without losing answers and keep the first step easy. Splitting a form into steps does not remove effort. It only spreads it out.
If the form has only a few fields, one page is simpler and easier to repair when something breaks. If the form matters to the business, compare both versions with real visitors before you commit.
Should a form open in a pop-up?
A form in a pop-up works when the visitor asked for it, for example by pressing a "Request a call" button. A form that opens by itself over the page is more likely to be closed unread. The guide to website pop-ups sets out when an overlay helps and what Google says about intrusive ones. For your main enquiry form, a normal page or a plain section of a page is the safer choice.
What should happen after someone submits?
Tell the visitor straight away that the message was received and what happens next. A good confirmation says who will reply, how, and roughly when if you can keep that promise. Avoid sending the visitor back to the home page, or leaving the form blank with no message, because either leaves them wondering whether it worked.
Behind the scenes, decide where each submission goes and who owns the reply. Send the notification to an inbox that several people monitor, not to one person. Store a copy of every submission somewhere other than email, so a delivery problem does not lose an enquiry. A short automatic confirmation by email can help, especially if it repeats what the visitor sent. Then reply promptly, because a good form followed by a slow reply still loses the enquiry.
A separate thank-you page is useful for measuring. It gives you a clear address to count in your analytics, so you can see how many people finish the form. Count submissions on the server too, since analytics can miss some.
If you want to add the person to a mailing list, ask separately and say so plainly. Do not tick the box for them. Rules on consent for email, and on what you must say about personal data, differ by country and change, so ask a lawyer or the official regulator what applies to you.
Where forms come from, and what to check
A form is usually produced in one of three ways: by a plugin or add-on in a content management system, by the form feature of a website builder, or by code written for your site. Plugin and builder forms are quick to add but need updating like any other software, and some load extra scripts that slow the page. Custom forms can be light and fit your process, but a developer must change them. The guide to a WordPress website vs a custom website compares the two routes more generally.
Hosting matters as well, because form emails are sent from the server. Some plans restrict outgoing mail, and a failed send may show only in a log. The guide to types of web hosting explains the plans, and your developer can tell you how your site sends mail.
Test and measure your forms
Send a test through the live form on a phone and on a computer, and confirm that the message arrives and the confirmation appears. Test the failures on purpose: leave a required field empty, type a bad email address and paste a very long message. In your analytics, compare how many people reach the form with how many submit. Some analytics and form tools also show which field people leave at, so check what yours offers. When you change something, change one thing at a time so you know what helped.
Count real enquiries, not raw submissions. Spam and test messages inflate the total, so remove them before you judge a change.
A developer can repair forms that fail to send or are hard to use on a phone. The website development service page describes the websites Liftup builds.
Questions and answers
How many fields should a form have?
There is no correct number. Ask only for what you need to take the next step, which for a simple enquiry is often a name, an email address and a message. For each field, ask what you would do differently without the answer, and drop it if the answer is nothing. A quote request can reasonably ask for more.
Why do people abandon forms?
The common causes are too many fields, private questions asked too early, vague error messages, answers lost after an error, awkward typing on a phone and no sign that the message was sent. Slow or jumpy pages and pop-ups over the form also drive people away. Fix faults first, then test changes one at a time.
What should happen after someone submits?
The visitor should see a clear confirmation saying the message arrived and what happens next. Behind the scenes, the enquiry should reach an inbox that is monitored, a copy should be stored outside email, and someone should reply promptly. A separate thank-you page also gives you an address to measure.
Should I use a multi-step form?
Use steps only when a long form has separate parts, such as job details followed by contact details. Show progress and let people go back without losing answers. For a short form, one page is simpler and easier to fix, because splitting a form only spreads the effort out.
Should I mark fields as required or optional?
Mark required fields clearly and keep them to a minimum. If most fields are required, mark the optional ones instead, so the form is not covered in symbols. Use the same marking throughout and explain it at the top of the form.
Why is my form not sending emails?
Common causes are notifications filtered as junk, a sending address not authorised for your domain, a wrong recipient address, a full mailbox or a clash with another plugin. Ask your developer to check the logs and to store submissions in a database so none are lost. Test again after every change.