What fields to put on a contact form, one by one

The test for every field

For each field you're considering, finish this sentence: "When someone fills this in, I will…". If the answer is "reply to them", "send it to the right person" or "quote a price", keep it. If it's "probably nothing" or "it might be useful", drop it. Each field adds typing on a phone, another place for mistakes, and more personal data to look after.

Field by field

Name: Keep, as a single field. Splitting first and last name fails for many people's names and adds a field. Mark it autocomplete="name".
Email: Keep, with type="email" and autocomplete="email" so phones show the right keyboard and browsers can fill it in. It's how you reply.
Message: Keep, as a multi-line box big enough to show several lines. Set a generous length limit rather than none.
Phone: Optional at most, unless you really call people back. If you ask, say why ("if you'd prefer a call") and use type="tel".
Subject: Usually drop. People write the subject in the message anyway.
Enquiry type: Keep only if it routes the message to different people or answers. Use a short list of radio buttons rather than a dropdown when there are four options or fewer.
Company: Keep for business-to-business services where you'd qualify the lead by it; drop for consumer businesses.
How did you hear about us?: Drop from the form. Ask in your reply, or use your analytics.
Consent checkbox: Not needed to reply to someone who wrote to you. Add an unticked, optional box only if you also want to send marketing.
File upload: Only if you genuinely need attachments, such as photos for a repair quote. It brings file-handling and security work.

MDN's reference for the autocomplete attribute lists the standard tokens, including name, email, tel and organization. Using them lets browsers fill the form in a tap, which matters most on phones.

Labels, errors and the confirmation

The W3C's forms tutorial covers what makes a form usable for everyone. The parts that matter most for a contact form:

A visible label for every field, tied to it in the markup. Placeholder text is not a label: it vanishes when someone types and is often too faint to read.
Say what's optional, not what's required, if most fields are required.
Show errors next to the field, in words: "Enter an email address like name@example.com", not "Invalid input". Keep everything the visitor typed.
Don't rely on colour alone to show an error; add text or an icon.
Check on the server too. Browser validation helps honest visitors and is easy to bypass.
Confirm clearly. A thank-you message that says the message was sent, when they'll hear back and how ("We reply within one working day by email").

Common mistakes

A phone number field marked required on a form where you always reply by email.
A dropdown of eight enquiry types that all go to the same inbox.
Clearing the form after an error, so the visitor retypes a long message on a phone.
No confirmation, or one that disappears in a second, so people send the form twice.
A CAPTCHA before anything else, rather than quieter spam defences. See stopping contact form spam.

Check your form

Fill it in on a phone using autofill. Every field should fill correctly.
Tab through it with a keyboard. Focus should be visible on every field and the button, in order.
Submit it empty, then with a bad email. Each error should say what to fix, beside the field.
Use a screen reader on the form (VoiceOver or NVDA). Each field should be announced by its label.
Send a real message and time how long until it reaches the person who answers.

Anticode's built-in forms

Anticode's built-in contact form uses the three-field pattern: name, email and a message. The booking form asks for the service, day, time, name, phone and email, and the newsletter form for an email only. Sentinel checks that every field is typed and length-capped and has a label before a page can publish, and the design gate requires visible keyboard focus. After sending, visitors see a thank-you page in the site's own design.

The fields are fixed: you can't add a company field, an enquiry type or a file upload to the built-in forms, and no Anticode form accepts file uploads. For other fields, use a custom form tied to a site function, which takes up to 30 plain-text fields, or an app build. The form design guide covers layout and spacing.

Questions people ask

How many fields should a contact form have?

Usually three: name, email and message. Add more only when the answer changes what you do with the message.

Should I ask for a phone number?

Only if you'll call. If you do ask, make it optional unless phone is the only way you work, and say why you want it.

Do I need a privacy notice on the form?

A short line linking to your privacy policy beside the button is good practice, so people know how their details will be used.

Sources

W3C WAI: Forms tutorial, checked 24 October 2026
MDN: HTML autocomplete attribute, checked 24 October 2026