Browser autofill can turn a tedious form into a quick task. A customer asking for a quote may be able to enter their name, email, phone number, and address with a few taps rather than typing each one on a phone keyboard. But autofill is not magic: browsers need recognizable fields, and people need to be able to review what gets filled.
These form browser autofill best practices help you make fields easier for browsers to identify without giving up control over the information you collect. They apply whether you use a form builder or build your form in HTML. The key is to use familiar labels and field types, add accurate autocomplete hints when you can, and test the result in real browsers.
What browser autofill does—and what it does not do
Autofill uses information saved in a browser or password manager to suggest or enter details such as a person’s name, email address, phone number, shipping address, or payment information. The exact behavior varies by browser, device, settings, and the person’s saved profile. A browser may show suggestions, fill a group of fields, or do nothing.
That makes autofill different from a form integration that looks up a customer record or a browser extension that stores business data. Your form cannot assume a value will be filled, and it should remain straightforward to complete by hand.
Autofill can also be useful to the team receiving submissions. A correctly filled email address or postal code is less likely to contain a typing mistake. It does not guarantee accurate data, though: people can have old addresses in a saved profile, and a browser can make a plausible but wrong guess. Keep important values visible and editable so respondents can check them.
Give every field clear, familiar clues
Use visible labels that describe the information
Write labels in the language people expect to see: “First name,” “Email address,” and “Postal code” are easier to interpret than “Contact field,” “ID,” or an internal database label. Put a visible label next to each control, and keep it present when the person starts typing. Placeholder text alone is not a reliable label; it disappears as soon as a value is entered and may be missed by assistive technology.
Good labels help people and provide context for browsers trying to identify a field. They are not a substitute for the technical hints described below, but they are the foundation. If you are reviewing labels and prompts as a whole, also check that your form error messages help people correct a mistake rather than just announcing that one occurred.
Choose the right input type
Use a field type that reflects the value you expect. An email field should be an email input, a phone number should use a telephone input, and a date should use an appropriate date control when that works for your audience and browsers. Correct types can provide a suitable mobile keyboard and help browsers interpret the field.
For example, a quote request might use an email input for “Work email” and a telephone input for “Phone number.” Do not use a number input for a phone number: phone numbers are identifiers, not quantities, and can contain leading zeros, spaces, or a country code.
Form builders often set input types behind the scenes. Check their field settings rather than assuming a field labelled “Email” automatically has the right underlying type.
Use stable field names in custom forms
If you control the HTML, give fields meaningful, stable name attributes, such as name, email, and postal-code. A name like field_7 gives the browser little to work with. The visible label and the HTML name do not need to match exactly, but they should refer to the same kind of information.
The MDN guide to the autocomplete attribute explains that browsers use autocomplete tokens to identify the purpose of fields. They may also use other clues, so meaningful names and labels matter even if you add tokens.
Add autocomplete tokens for standard information
The HTML autocomplete attribute lets you tell a browser what a field is for. A token is a standard value such as given-name or email. It is more specific than a broad instruction to “autofill.” The browser still decides whether and how to fill the field.
For a basic contact form, the relevant HTML might look like this:
<label for="given-name">First name</label>
<input id="given-name" name="given-name" autocomplete="given-name">
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">
<label for="phone">Phone number</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">Common tokens include name, given-name, family-name, email, tel, organization, street-address, address-level2 (usually a city or town), address-level1 (often a state, province, or region), and postal-code. The HTML Standard’s autofill field-name definitions lists the recognized tokens and their intended meanings.
Use the token that matches the data, not the one that seems most likely to trigger a fill. For example, do not mark a company’s internal account number as postal-code just because it contains digits. An inaccurate hint can lead to confusing suggestions or values in the wrong field.
Use address tokens for the right kind of address
When a form asks for a shipping or billing address, identify which address is being collected. A token can include a section and address type, such as section-shipping shipping street-address or section-billing billing street-address. A section name groups related fields; the address type distinguishes shipping from billing.
For example, a checkout form with two address groups should not give both street fields the same generic identity if one is a shipping address and the other is a billing address. Use matching tokens for the city, region, and postal code in each group too. This gives browsers a clearer map of the form. Check the syntax in the HTML standard or your form builder’s documentation before publishing, since builders may expose these settings differently.
Handle names and phone numbers without assumptions
Names do not follow one universal pattern. If your process does not need to address people by first and last name separately, a single “Full name” field with autocomplete="name" may be more inclusive and easier to fill. If you need separate parts for a clear business reason, label and identify each part accurately.
Phone numbers also vary by country. Avoid hard-coding a format that rejects valid international numbers unless your service genuinely operates in one region. If you need a country code, say so in the label or provide a country selector; do not expect respondents to infer it from a placeholder.
Do not make autofill a requirement
A form should work for someone using a shared computer, a private browsing window, an unfamiliar device, or a browser with autofill turned off. It should also work if the saved details are incomplete. Keep fields editable, allow people to replace a suggestion, and do not treat an empty field as an autofill failure.
Be cautious about setting autocomplete="off" across a form. The browser may ignore it for some fields, and blocking useful suggestions can make a form harder to complete. There may be a valid reason not to suggest a value—for example, a one-time code or a field that should not be filled from a saved profile—but decide field by field rather than disabling autofill everywhere.
For credentials, use the appropriate purpose tokens, such as current-password or new-password, rather than trying to prevent password managers from working. For a one-time verification code, one-time-code may help compatible devices offer a code suggestion. These hints do not remove the need to protect sensitive data on your own systems.
Make the form easy to review and correct
Autofill can place a valid-looking value in the wrong place, especially when a form has multiple address sections or unusual field names. Keep a clear visual relationship between each label and its field. Group related details, and use headings such as “Shipping address” and “Billing address” where people need to distinguish them.
Do not hide an important value just because the browser filled it. Give users a clear way to edit details and catch errors before submission. If you ask for a confirmation field, consider whether it genuinely catches a meaningful problem; asking people to type an email address twice can undermine the time saved by autofill. A better approach may be a clear review step or an easy correction process.
Also make optional fields genuinely optional. If you do not need a second phone number or a separate company address to handle the request, do not make it a barrier to submission. This practical framework for deciding when a field should be optional can help you make that call.
Test autofill with realistic tasks
Testing only in the form builder preview is not enough. Publish a test version or use a safe staging environment, then try the form in common browsers and on both desktop and mobile devices. Autofill behavior can differ, and form builders may render fields differently from their editor.
- Use a fresh test submission. Check how the form behaves when fields are empty and when a browser has saved profile details.
- Try more than one profile. Test a profile with a middle name, an international phone number, or a different address format if those are realistic for your audience.
- Check grouped fields. On a checkout form, see whether shipping suggestions land in shipping fields and billing suggestions in billing fields.
- Review what is submitted. Confirm that the form sends the values you see, not stale or hidden values left over from a previous test.
- Complete it without autofill. Make sure manual entry, error recovery, and keyboard navigation still work.
On mobile, check whether the right keyboard appears, whether suggestions obscure a field or button, and whether a person can move through the form without losing their place. Autofill is only one part of a usable mobile experience; use this mobile form design checklist to review the rest.
For each test, note the browser and device, the fields that filled, and any unexpected values. You do not need a large testing program for a short contact form. A few repeatable checks can catch an incorrectly identified address field or a layout that makes filled values hard to inspect.
Protect privacy while keeping autofill useful
Autofill fills information a person has chosen to save in their browser; it does not give your form permission to collect unrelated information. Ask only for data you need to respond, deliver a service, or complete the stated task. Avoid adding personal fields simply because a browser might be able to fill them.
The W3C’s explanation of WCAG’s Identify Input Purpose criterion describes how standard tokens can help identify the purpose of common personal-information fields, including for user agents and assistive technologies. This is useful context for accessibility as well as autofill. It does not mean every form must collect every listed detail, or that tokens alone make a form accessible.
For forms that collect sensitive information, consider whether that information belongs in a browser-fillable field at all. Explain why you need it, limit access to submissions, and follow the privacy and security rules that apply to your organization. Autofill can make entry easier, but it should not quietly expand what you collect.
A practical pre-publish checklist
- Each field has a visible, specific label.
- Input types match the information requested, including email and telephone fields.
- Custom HTML uses meaningful
nameattributes and accurateautocompletetokens. - Shipping, billing, and other repeated sections are clearly distinguished.
- People can review and change values filled by the browser.
- The form remains usable when autofill is unavailable or disabled.
- You have tested the form in at least one desktop and one mobile browser used by your audience.
- You collect only the personal information needed for the task.
Good autofill support is mostly careful form construction: familiar labels, appropriate controls, accurate hints, and a sensible way to review entries. Those choices help browsers interpret your form, but they also make it clearer for people who type every answer themselves.
FAQ
Does adding an autocomplete attribute guarantee that a browser will fill a field?
No. The attribute gives the browser a hint about a field’s purpose. Browser settings, saved information, device behavior, and the form’s structure all affect whether a value is suggested or filled.
Should I turn autocomplete off on a contact form?
Usually, there is no need to disable it for ordinary contact details. Use accurate field purposes and let people edit suggestions. Consider a restriction only for a specific field where filling saved profile information would be inappropriate.
What is the difference between an input type and an autocomplete token?
An input type describes the kind of control or value, such as an email address or telephone number. An autocomplete token describes the specific purpose of the value, such as a shipping street address or a family name. Both can help browsers interpret a field.
Can autofill help with accessibility?
Accurate autocomplete tokens can help browsers and assistive technologies identify common personal-information fields. They are one part of accessible form design, not a replacement for clear labels, keyboard access, instructions, and usable error messages.
How should I test autofill without using real customer information?
Use a test browser profile with made-up details and submit only to a staging form or a clearly marked test destination. Check the visible values and the resulting submission, then remove test records so they are not mistaken for real inquiries.