Use truthful field semantics and ordered autocomplete tokens, then verify synthetic autofilled values through validation and the actual submitted payload without suppressing password managers.
Wrong autofill is often a mismatch between what a field means, what its markup says and how the application retains its value. Fix those layers before disabling autofill. Clear input-purpose hints help browsers and assistive tools, but the final proof is that the intended values survive correction and reach the right submitted fields.
This guide covers website forms you maintain. Use a test environment and synthetic profiles, not a customer’s saved address, password or card. The two-address example is fictional and does not claim a browser defect or an observed conversion improvement.
Separate a wrong suggestion from a lost value
Record the first point at which the task fails. Does the browser suggest the wrong kind of value, fill an unexpected field, or correctly fill a value that disappears after a validation message? These symptoms point to different work.
For a fictional parcel form, the shipping postcode might fill correctly while the billing postcode receives the same value despite a different profile choice. Another version might show both values correctly but submit only one. A screenshot of populated inputs cannot distinguish those cases.
Check the rendered controls, their labels, names, IDs and owning form, then inspect the application’s test submission. Redact the values from logs and screenshots. Keep synthetic fixtures separate from real customer or administrator profiles.
Give type, autocomplete and inputmode different jobs
An input’s type describes the control and its data semantics. The autocomplete attribute describes the information’s purpose, such as email, username or postal-code. inputmode suggests an appropriate keyboard; it does not validate the value.
For an email used to contact a visitor, an email input with autocomplete email expresses a different purpose from a sign-in identity using autocomplete username, even when that identity happens to be an email address. Choose the purpose the application actually uses.
Likewise, a phone number is not a quantity to calculate. Use an appropriate telephone control and purpose rather than treating it as a general number. Postal codes and account identifiers may contain leading zeros or letters. Keep their representation intact instead of converting everything that contains digits into numeric data.
| Actual purpose | Useful semantic distinction |
|---|---|
| Contact email | Email control with the email purpose. |
| Sign-in identity | Username purpose, even when the identity’s format is an email. |
| Telephone | Telephone semantics, allowing the formats the service supports. |
| Postal code | Text identifier with postal-code purpose, preserving zeros and letters. |
| Quantity | A numeric quantity with application-specific range validation. |
Separate repeated groups with ordered tokens
The HTML autofill standard defines ordered tokens rather than an arbitrary collection of words. When used, a section token comes first, followed by an applicable shipping or billing group and then the field purpose.
For the fictional parcel form, the following escaped markup illustrates two separate postcode controls. It omits the rest of the form and is not a live submission interface.
<label for="delivery-postal">Delivery postcode</label>
<input id="delivery-postal" name="delivery_postal"
type="text"
autocomplete="section-delivery shipping postal-code">
<label for="invoice-postal">Billing postcode</label>
<input id="invoice-postal" name="invoice_postal"
type="text"
autocomplete="section-invoice billing postal-code">Use the same section token consistently for the other controls in that address. If there are two different recipients, give their groups distinct stable sections rather than duplicate IDs. The labels and submitted field names should make the distinction clear to the visitor and server as well.
A section describes grouping; it does not select a particular saved profile or guarantee that a browser ignores its own heuristics. Test the actual user choice rather than treating a standards-compliant token as an end-to-end result.
Use truthful password and verification purposes
A current-password field asks for an existing credential. A new-password field is for creating or changing one, including its confirmation when relevant. A one-time-code field is for the real verification code in an authentication flow. Do not assign those purposes to unrelated inputs to discourage suggestions.
The sign-in guidance recommends making password-manager interactions work with the form’s actual purpose. Blocking paste, manufacturing hidden password fields or switching a control’s type on focus can make legitimate completion harder without reliably solving the original issue.
Do not assume autocomplete off will prevent a password manager from offering or filling credentials. Browser and manager behaviour varies. If a sensitive workflow genuinely needs a different treatment, review that specific requirement rather than removing assistance from every field on the website.
Preserve values through the application’s form lifecycle
Follow one synthetic filled value from the visible control through application state, validation, rerender and submission. A controlled component can display a browser-filled value temporarily, then replace it with an older application value when another field changes.
Check the framework’s supported form integration rather than adding random events until the screen looks right. Verify the values after blur, after changing a neighbouring control, after a server validation error and immediately before the test request is sent. Do not inspect only the state object or only the DOM.
Stable names and IDs help keep field ownership intelligible. When a country change deliberately changes address fields, explain the new requirements and preserve values that remain valid. Replacing the whole form with empty controls is not an acceptable response to one incorrect field.
For the parcel example, submit a synthetic address with a leading-zero postal identifier and a separate billing address. Confirm that each reaches its corresponding test record. The server must still validate supported countries, required fields and permitted values; autofill is convenience, not trusted identity evidence.
Make international input possible
A numeric keyboard can reduce typing for a truly numeric field, but it may be the wrong choice for postal codes across several countries. Telephone entries can need a plus sign and spaces; identifiers may need letters. Select hints according to the supported task and let visitors correct the result.
Do not silently remove leading zeros or force every address into one country’s pattern. If the service supports only a limited region, say so before the form and validate that actual requirement. A generic website form should not reject legitimate input because its example happened to contain only digits.
In a synthetic test set, include an identifier beginning with zero, an alphanumeric postal format, a long address line and punctuation in contact information. Those are cases to test, not proof that every jurisdiction’s address model has been covered.
Treat input-purpose hints as one part of accessibility
WCAG 1.3.5 concerns programmatically identifiable purposes for covered fields collecting information about the user. It helps tools provide useful assistance. It does not mean inventing a user-information purpose for every arbitrary search, product or other-person field.
Correct hints do not replace persistent labels, meaningful instructions or clear errors. Our form-accessibility guide covers that separate journey. Verify that errors identify the affected control and keep valid filled answers available.
If the form is embedded, compare its standalone behaviour too. An iframe session or storage failure may interrupt the flow even when autocomplete markup is correct; the embedded-form diagnosis addresses that different boundary.
Review the completed task in supported browsers
- Use synthetic profiles with deliberately different shipping and billing values.
- Check a fresh visitor, a saved-profile choice and manual entry without saved data.
- Verify keyboard and mobile completion, including any needed letters or plus sign.
- Trigger a controlled validation error, correct it and confirm valid values persist.
- Inspect the actual test submission and resulting field mapping without logging secrets.
- Repeat after a browser or form-library change that affects the observed behaviour.
Accept the repair when the field purpose is truthful, repeated groups remain distinct, and both assisted and manual entry complete the task with the correct values. The aim is not to defeat autofill heuristics; it is to give visitors reliable help and retain responsibility for the form’s own state and validation.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: autocomplete HTML attributeChecked Input-purpose tokens, ordered section and shipping/billing groups, and limitations of off for password-manager behaviour.
Limits: Hints do not force a particular profile choice or identical autofill heuristics in every browser. - WHATWG HTML Standard: Autofilling form controlsChecked Autofill field-name semantics, token order and grouping of controls.
Limits: Conforming markup still requires testing with actual supported browsers and the application's form lifecycle. - MDN: inputmodeChecked Keyboard input hints and the fact that inputmode does not impose validation requirements.
Limits: A keyboard hint cannot guarantee every character is available on every device or validate an international identifier. - W3C: Understanding Identify Input PurposeChecked WCAG 1.3.5 scope for covered information about the user and programmatically identifiable purpose.
Limits: The criterion does not require every field, including arbitrary product or other-person data, to use a user-information autocomplete purpose. - web.dev: Sign-in form best practicesChecked Username and current/new-password semantics, password-manager support and avoiding unnecessary restrictions on password entry.
Limits: Good input hints do not authenticate a user or replace server-side validation and authorization.