HTML Guides for autocomplete

The autocomplete attribute tells the browser whether it can assist the user in filling out a form field, and if so, what type of data is expected. The generic values "on" and "off" control whether the browser should offer autofill suggestions to the user. Since type="hidden" inputs are never displayed and never receive direct user input, these values don't apply — there's no user interaction to assist with.

According to the HTML specification, hidden inputs can have an autocomplete attribute, but only with specific named autofill detail tokens (like "transaction-id" or "cc-number"). These tokens serve a programmatic purpose by providing hints about the semantic meaning of the hidden value, which can be useful for form processing. The generic "on" and "off" values, however, are explicitly disallowed because they only relate to the user-facing autofill behavior.

This validation error matters for standards compliance and can indicate a logical mistake in your markup. If you added autocomplete="off" to a hidden input hoping to prevent the browser from caching or modifying the value, it won't have that effect. Hidden input values are controlled entirely by the server or by JavaScript, not by browser autofill.

How to fix it

1. Remove the autocomplete attribute if it's not needed — this is the most common fix.
2. Use a specific autofill token if you need to convey semantic meaning about the hidden value (e.g., autocomplete="transaction-id").
3. Reconsider the input type — if the field genuinely needs autofill behavior controlled, it probably shouldn't be type="hidden".

Examples

Incorrect: using autocomplete="off" on a hidden input

<formaction="/submit"method="post">

<inputtype="hidden"name="token"value="abc123"autocomplete="off">

<buttontype="submit">Submit</button>

</form>

Incorrect: using autocomplete="on" on a hidden input

<formaction="/submit"method="post">

<inputtype="hidden"name="session-id"value="xyz789"autocomplete="on">

<buttontype="submit">Submit</button>

</form>

Correct: removing the autocomplete attribute

<formaction="/submit"method="post">

<inputtype="hidden"name="token"value="abc123">

<buttontype="submit">Submit</button>

</form>

Correct: using a specific autofill token

If the hidden input carries a value with a well-defined autofill semantic, you can use a named token:

<formaction="/checkout"method="post">

<inputtype="hidden"name="txn"value="TXN-001"autocomplete="transaction-id">

<buttontype="submit">Complete Purchase</button>

</form>

This is valid because "transaction-id" is a specific autofill detail token recognized by the specification, unlike the generic "on" or "off" values.

The autocomplete attribute tells the browser whether and how to automatically fill in a form field based on previously entered data. It makes sense for fields where users type or select values from a predictable set — like names, emails, addresses, dates, and numbers. However, certain input types don't produce text or numeric data that browsers could meaningfully store and recall. These include checkbox, radio, file, button, submit, reset, and image.

The HTML specification explicitly limits autocomplete to the following input types: color, date, datetime-local, email, hidden, month, number, password, range, search, tel, text, time, url, and week. Using it on any other type violates the spec and produces a validation error.

Why this matters

• Standards compliance: Browsers are not required to honor autocomplete on unsupported input types, so including it has no practical effect and produces invalid markup.
• Code clarity: Invalid attributes can confuse other developers reading your code, suggesting a behavior that doesn't actually exist.
• Accessibility: Screen readers and assistive technologies rely on valid markup to accurately convey form behavior to users. Unexpected attributes can introduce ambiguity.

How to fix it

1. Identify the input type that has the autocomplete attribute.
2. If the type is checkbox, radio, file, button, submit, reset, or image, remove the autocomplete attribute.
3. If you genuinely need autocomplete behavior, reconsider whether the correct input type is being used. For example, a field that should accept text input might have been incorrectly set to type="checkbox".

Examples

❌ Invalid: autocomplete on a checkbox

<form>

<label>

<inputtype="checkbox"name="terms"autocomplete="off"> I agree to the terms

</label>

</form>

The browser cannot meaningfully autocomplete a checkbox, so this attribute is not allowed here.

✅ Fixed: remove autocomplete from the checkbox

<form>

<label>

<inputtype="checkbox"name="terms"> I agree to the terms

</label>

</form>

❌ Invalid: autocomplete on radio buttons

<form>

<fieldset>

<legend>Preferred contact method</legend>

<label>

<inputtype="radio"name="contact"value="email"autocomplete="off"> Email

</label>

<label>

<inputtype="radio"name="contact"value="phone"autocomplete="off"> Phone

</label>

</fieldset>

</form>

✅ Fixed: remove autocomplete from radio buttons

<form>

<fieldset>

<legend>Preferred contact method</legend>

<label>

<inputtype="radio"name="contact"value="email"> Email

</label>

<label>

<inputtype="radio"name="contact"value="phone"> Phone

</label>

</fieldset>

</form>

❌ Invalid: autocomplete on a file input

<form>

<labelfor="resume">Upload resume:</label>

<inputtype="file"id="resume"name="resume"autocomplete="off">

</form>

✅ Fixed: remove autocomplete from the file input

<form>

<labelfor="resume">Upload resume:</label>

<inputtype="file"id="resume"name="resume">

</form>

✅ Valid: autocomplete on supported types

<form>

<labelfor="email">Email:</label>

<inputtype="email"id="email"name="email"autocomplete="email">

<labelfor="bday">Birthday:</label>

<inputtype="date"id="bday"name="bday"autocomplete="bday">

<labelfor="query">Search:</label>

<inputtype="search"id="query"name="query"autocomplete="off">

</form>

If you want to disable autocomplete for an entire form — including checkboxes and other non-text fields — set autocomplete="off" on the <form> element itself rather than on individual inputs that don't support the attribute:

<formautocomplete="off">

<labelfor="username">Username:</label>

<inputtype="text"id="username"name="username">

<label>

<inputtype="checkbox"name="remember"> Remember me

</label>

</form>

The autocomplete attribute helps browsers automatically fill in form fields with previously saved user data. The HTML specification defines a strict set of valid autofill field names, and "company" is not among them. While "company" might seem like an intuitive choice, the spec uses "organization" to represent a company name, business name, or other organizational name associated with the person or address in the form.

Using an invalid autocomplete value means browsers won't recognize the field's purpose and cannot offer relevant autofill suggestions. This degrades the user experience — especially on mobile devices where autofill significantly speeds up form completion. It also impacts accessibility, as assistive technologies may rely on valid autocomplete tokens to help users understand and complete forms efficiently.

The full list of valid autofill field names is defined in the WHATWG HTML Living Standard. Some commonly used values include "name", "email", "tel", "street-address", "postal-code", "country", and "organization". When choosing a value, always refer to the specification rather than guessing a name that seems logical.

Examples

❌ Invalid: using "company" as an autocomplete value

<labelfor="company">Company Name</label>

<inputtype="text"id="company"name="company"autocomplete="company">

This triggers the validation error because "company" is not a recognized autofill field name.

✅ Valid: using "organization" instead

<labelfor="company">Company Name</label>

<inputtype="text"id="company"name="company"autocomplete="organization">

The value "organization" is the spec-defined autofill field name for "the company, organization, institution, or other entity associated with the person, address, or contact information in the other fields associated with this field."

✅ Valid: using "organization" with a section and purpose

You can combine "organization" with other valid tokens for more specificity:

<labelfor="work-org">Employer</label>

<inputtype="text"id="work-org"name="employer"autocomplete="section-work organization">

This tells the browser that the field is for an organization name within a specific named section of the form, which is useful when a form collects information about multiple entities.

Common Autofill Field Names for Business Forms

Here are some valid autocomplete values you might use alongside "organization" in a business-related form:

• "organization" — company or organization name
• "organization-title" — job title (e.g., "Software Engineer", "CEO")
• "name" — full name of the contact person
• "email" — email address
• "tel" — telephone number
• "street-address" — full street address

Using the correct values ensures browsers can provide meaningful autofill suggestions, making your forms faster and easier to complete.

The autocomplete attribute helps browsers autofill form fields with previously saved user data. The HTML specification defines a strict set of valid values, and each one maps to a specific type of information (like a name, email address, phone number, or street address). The string "contact" by itself is not a valid autofill field name — it's a contact type token, which is a modifier meant to be combined with a field name to distinguish between different types of contact information.

The HTML spec defines two contact type tokens: "home", "work", "mobile", "fax", and "pager" (for phone-related fields), as well as the broader "shipping" and "billing" scoping tokens. The token "contact" doesn't exist as a standalone value at all. You may have confused it with a contact type prefix pattern like "home email" or "work tel", or you may have intended to use a specific field name entirely.

Getting the autocomplete value right matters for several reasons. Browsers rely on these exact tokens to offer relevant autofill suggestions. Screen readers and assistive technologies may also use this information to help users understand what data a field expects. An invalid value means the browser will likely ignore the attribute entirely, degrading the user experience — especially on mobile devices where autofill is heavily used.

To fix the issue, determine what kind of information the input field is collecting and use the appropriate autofill field name. Common valid values include "name", "email", "tel", "street-address", "postal-code", "organization", and "username". If you want to indicate that this is specifically a contact email or phone (as opposed to, say, a billing one), you don't use "contact" — instead, you can omit the modifier entirely or use a section-scoping approach.

Examples

❌ Invalid: Using "contact" as the autocomplete value

<labelfor="email">Contact Email</label>

<inputtype="email"id="email"name="email"autocomplete="contact">

The value "contact" is not a recognized autofill field name, so the browser cannot determine what to autofill.

✅ Fixed: Using a valid autofill field name

<labelfor="email">Contact Email</label>

<inputtype="email"id="email"name="email"autocomplete="email">

The value "email" is a valid autofill field name that tells the browser to suggest saved email addresses.

✅ Fixed: Using a valid combination with a section or contact type token

If you need to differentiate between types of phone numbers, you can use tokens like "home", "work", or "mobile" as prefixes:

<labelfor="work-tel">Work Phone</label>

<inputtype="tel"id="work-tel"name="work-tel"autocomplete="work tel">

<labelfor="home-email">Personal Email</label>

<inputtype="email"id="home-email"name="home-email"autocomplete="home email">

Common valid autocomplete values

Here are some frequently used valid autofill field names:

For the complete list of valid values and their permitted combinations, refer to the WHATWG autofill specification.

The autocomplete attribute on a <form> element only accepts "on" or "off" as valid values — "false" is not a recognized keyword.

The autocomplete attribute controls whether the browser can automatically fill in form fields based on previously entered values. When set on a <form> element, it applies as the default behavior for all fields within that form. The valid values are "on" (the browser may auto-complete entries) and "off" (the browser should not auto-complete entries).

It's a common mistake to use "true" or "false" since many other attributes and programming languages use boolean-style values. However, the HTML specification explicitly defines only "on" and "off" for the <form> element's autocomplete attribute.

Note that individual <input> elements support a much wider range of autocomplete values (like "name", "email", "street-address", etc.), but these extended values do not apply to the <form> element itself.

Invalid Example

<formautocomplete="false"action="/submit"method="post">

<labelfor="email">Email</label>

<inputtype="email"id="email"name="email">

<buttontype="submit">Submit</button>

</form>

Valid Example

<formautocomplete="off"action="/submit"method="post">

<labelfor="email">Email</label>

<inputtype="email"id="email"name="email">

<buttontype="submit">Submit</button>

</form>

The autocomplete attribute tells the browser whether and how it should autofill a form field. The HTML living standard defines a specific set of allowed values — an empty string is not among them. When the attribute is present but empty, the browser receives ambiguous instructions: you've explicitly declared the attribute, signaling intent, but provided no actual directive. Different browsers may interpret this inconsistently, some treating it as on, others ignoring it, and others falling back to default behavior.

This matters for several reasons:

• Standards compliance: The WHATWG HTML specification requires autocomplete to contain either the keywords on or off, or one or more valid autofill detail tokens. An empty string satisfies none of these.
• Accessibility: Autofill helps users with motor impairments or cognitive disabilities complete forms more quickly and accurately. An ambiguous autocomplete value can interfere with assistive technologies that rely on these hints.
• User experience: Specific autofill tokens like email, tel, street-address, and current-password allow browsers and password managers to suggest the right data for the right field. Using them correctly makes forms faster and easier to complete.

This issue commonly arises when a framework or template engine outputs autocomplete="" as a default, or when a developer intends to disable autocomplete but leaves the value blank instead of using off.

How to fix it

Choose one of these approaches depending on your intent:

1. Remove the attribute if you want default browser behavior (the browser decides whether to autofill).
2. Use on to explicitly allow autofill.
3. Use off to explicitly discourage autofill (note: browsers may still autofill for login fields regardless).
4. Use a specific autofill token to tell the browser exactly what kind of data the field expects. This is the most helpful option for users.

Common autofill tokens include: name, given-name, family-name, email, username, new-password, current-password, tel, street-address, postal-code, country, and cc-number. You can find the full list in the WHATWG autofill specification.

Examples

Incorrect: empty autocomplete value

<inputtype="text"name="username"autocomplete="">

This triggers the validation error because the attribute is present but contains no valid token.

Correct: remove the attribute entirely

If you have no specific autofill preference, simply omit the attribute:

<inputtype="text"name="username">

Correct: use on or off

Explicitly enable or disable autofill:

<inputtype="text"name="username"autocomplete="on">

<inputtype="text"name="search-query"autocomplete="off">

Correct: use specific autofill tokens

Specific tokens give browsers the best hints for filling in the right data. This is the recommended approach for forms that collect personal information:

<form>

<labelfor="name">Full name</label>

<inputtype="text"id="name"name="name"autocomplete="name">

<labelfor="useremail">Email</label>

<inputtype="email"id="useremail"name="useremail"autocomplete="email">

<labelfor="phone">Phone</label>

<inputtype="tel"id="phone"name="phone"autocomplete="tel">

<labelfor="pwd">Password</label>

<inputtype="password"id="pwd"name="pwd"autocomplete="current-password">

<buttontype="submit">Sign in</button>

</form>

Using precise tokens like current-password and email helps password managers and mobile keyboards provide the most relevant suggestions, improving the experience for all users.

The autocomplete="new-password" value can only be used on <input> elements whose type accepts password input, specifically type="password".

The autocomplete attribute helps browsers autofill form fields. However, certain autofill tokens are restricted to specific input types. The new-password token tells the browser to suggest a new, generated password — which only makes sense on a password field. If you use it on a type="text", type="email", or other non-password input, the validator will flag it as invalid.

The same restriction applies to current-password. Both tokens are exclusively valid on <input type="password">.

Invalid Example

<labelfor="pass">Create a password</label>

<inputtype="text"id="pass"autocomplete="new-password">

Valid Example

<labelfor="pass">Create a password</label>

<inputtype="password"id="pass"autocomplete="new-password">

If your field is not meant to collect a password, use a different autocomplete value appropriate for the input type, such as username, email, or off.

The autocomplete attribute tells the browser how to handle autofilling a form field. The HTML specification defines a strict set of allowed values: the keywords on and off, and a collection of autofill field names such as name, email, username, new-password, street-address, and many others. The value "none" is not part of this specification, even though it might seem like a logical choice for "no autocomplete."

This confusion likely arises because some non-web APIs and frameworks use "none" as a keyword to disable features. In HTML, however, the correct keyword to disable autocompletion is "off". Using an invalid value like "none" leads to undefined browser behavior — some browsers may ignore it entirely and autofill anyway, while others might treat it as equivalent to "on". This inconsistency can cause unexpected user experiences and potential security concerns, especially for sensitive fields like passwords or credit card numbers.

Beyond standards compliance, using valid autocomplete values improves accessibility. Assistive technologies and password managers rely on recognized autofill field names to help users fill out forms efficiently. When a valid, descriptive value like "username" or "email" is provided, browsers and assistive tools can offer more accurate suggestions.

How to fix it

Replace "none" with the appropriate valid value:

• Use "off" if you want to disable autofill for the field.
• Use "on" if you want the browser to decide how to autofill the field.
• Use a specific autofill field name if you want to hint at the type of data expected.

Common autofill field names include: name, given-name, family-name, email, username, new-password, current-password, tel, street-address, postal-code, country, cc-number, cc-exp, and cc-name. You can also combine tokens, such as "shipping postal-code" or "billing cc-number", to provide additional context through section and hint tokens.

Note: Even with autocomplete="off", some browsers may still autofill certain fields (particularly login credentials) for security or usability reasons. This is browser-specific behavior and not something the HTML specification can override.

Examples

Incorrect: using "none" to disable autofill

<form>

<labelfor="user">Username</label>

<inputtype="text"id="user"name="username"autocomplete="none">

</form>

Correct: using "off" to disable autofill

<form>

<labelfor="user">Username</label>

<inputtype="text"id="user"name="username"autocomplete="off">

</form>

Correct: using a specific autofill field name

When you know what kind of data a field collects, providing a descriptive autofill field name is often better than using "on" or "off". This helps browsers offer accurate suggestions:

<form>

<labelfor="user">Username</label>

<inputtype="text"id="user"name="username"autocomplete="username">

<labelfor="email">Email</label>

<inputtype="email"id="email"name="email"autocomplete="email">

<labelfor="pwd">New Password</label>

<inputtype="password"id="pwd"name="password"autocomplete="new-password">

</form>

Correct: using section and hint tokens

You can prefix an autofill field name with a section name or shipping/billing hint to distinguish between multiple addresses in the same form:

<form>

<labelfor="ship-zip">Shipping postal code</label>

<inputtype="text"id="ship-zip"name="ship_zip"autocomplete="shipping postal-code">

<labelfor="bill-zip">Billing postal code</label>

<inputtype="text"id="bill-zip"name="bill_zip"autocomplete="billing postal-code">

</form>

The autocomplete attribute on <form> elements controls whether the browser should automatically fill in form fields based on previously entered data. Unlike autocomplete on <input> elements — which accepts a rich set of tokens like "name", "email", "street-address", etc. — the <form> element itself only accepts two values: "on" and "off".

A common workaround that gained popularity was setting autocomplete="nope" (or other made-up values like "new-password", "false", or "disabled") on the <form> element. This hack exploited the fact that some browsers would treat any unrecognized value as a signal to disable autocomplete. However, this behavior is non-standard and unreliable — browsers may ignore invalid values entirely and fall back to their default behavior, which is typically "on".

Using invalid attribute values causes several problems:

• Standards compliance: The HTML specification explicitly defines the allowed values, and validators will flag anything else as an error.
• Unpredictable behavior: Different browsers handle invalid values differently. What works in one browser today may stop working in the next update.
• Accessibility and user experience: Assistive technologies and browser features rely on standard attribute values to function correctly. Invalid values can interfere with password managers and autofill tools that many users depend on.

It's worth noting that even with autocomplete="off", some browsers (particularly Chrome) may still autofill certain fields like login credentials for security reasons. If you need finer-grained control, apply autocomplete attributes directly on individual <input> elements using the appropriate autofill tokens from the specification.

Examples

❌ Invalid: Using a made-up value on a form

<formautocomplete="nope"action="/submit"method="post">

<labelfor="username">Username</label>

<inputtype="text"id="username"name="username">

<buttontype="submit">Submit</button>

</form>

This triggers the error Bad value "nope" for attribute "autocomplete" on element "form" because "nope" is not a valid autocomplete value for <form>.

✅ Fixed: Using the correct value to disable autocomplete

<formautocomplete="off"action="/submit"method="post">

<labelfor="username">Username</label>

<inputtype="text"id="username"name="username">

<buttontype="submit">Submit</button>

</form>

✅ Using autocomplete on individual inputs for more control

If you need to disable autocomplete for specific fields while leaving others enabled, apply the attribute directly on the <input> elements instead:

<formaction="/submit"method="post">

<labelfor="username">Username</label>

<inputtype="text"id="username"name="username"autocomplete="username">

<labelfor="secret">One-time code</label>

<inputtype="text"id="secret"name="secret"autocomplete="off">

<buttontype="submit">Submit</button>

</form>

In this example, the username field uses the standard "username" autofill token to help browsers fill it correctly, while the one-time code field has autocomplete disabled since its value should never be reused.

The autocomplete attribute tells the browser how to handle autofill for a form field. The HTML specification defines a strict set of valid values, which include "on", "off", and a list of autofill field names such as "username", "new-password", "cc-number", "postal-code", and many others. When you use a value that isn't in this list — such as "nope", "false", "none", or any other made-up string — the W3C validator reports it as an invalid autofill field name.

A common reason developers use values like "nope" is as a workaround because some browsers historically ignored autocomplete="off". In older versions of Chrome and Firefox, the browser would still show autofill suggestions even when off was set, so developers discovered that using an unrecognized value like "nope" effectively tricked the browser into not showing suggestions. While this hack may have worked in practice, it produces invalid HTML and is not a reliable long-term solution since browser behavior around unrecognized values can change at any time.

Why this matters

• Standards compliance: Invalid attribute values make your HTML non-conforming, which can cause issues with tooling, testing pipelines, and accessibility auditors.
• Accessibility: Screen readers and assistive technologies rely on valid autocomplete values to help users fill in forms. Using a correct autofill field name like "given-name" or "email" can significantly improve the experience for users with disabilities. In fact, WCAG 2.1 Success Criterion 1.3.5 specifically recommends using valid autocomplete values for fields that collect user information.
• Browser behavior: Modern browsers have improved their handling of autocomplete="off". Using the standard value is now more reliable than it once was, and using it correctly ensures predictable behavior across browsers.

How to fix it

1. To disable autocomplete, replace the invalid value with "off".
2. To enable smart autofill, use the appropriate autofill field name from the HTML specification's list of autofill field names. This is the preferred approach for most user-facing forms.
3. For new passwords (e.g., registration or password-change forms), use "new-password" — this tells the browser to suggest a generated password rather than filling in a saved one.

Examples

Invalid: made-up autocomplete value

<inputtype="text"name="firstName"autocomplete="nope">

Other common invalid values that trigger the same error include "false", "none", "disable", and "no".

Fixed: disabling autocomplete with "off"

<inputtype="text"name="firstName"autocomplete="off">

Fixed: using a valid autofill field name

Using a specific autofill field name is often better than "off" because it helps browsers and assistive technologies understand the purpose of the field:

<inputtype="text"name="firstName"autocomplete="given-name">

Fixed: common valid autocomplete values in a form

<formmethod="post"action="/register">

<labelfor="name">Full Name</label>

<inputtype="text"id="name"name="name"autocomplete="name">

<labelfor="email">Email</label>

<inputtype="email"id="email"name="email"autocomplete="email">

<labelfor="newpass">Password</label>

<inputtype="password"id="newpass"name="password"autocomplete="new-password">

<labelfor="tel">Phone</label>

<inputtype="tel"id="tel"name="phone"autocomplete="tel">

<buttontype="submit">Register</button>

</form>

Some of the most commonly used valid values include: "name", "given-name", "family-name", "email", "username", "new-password", "current-password", "street-address", "postal-code", "country", "tel", "cc-number", and "organization". Refer to the full list in the HTML specification for all available options.

The autocomplete attribute tells browsers whether and how to autofill a form field. The HTML specification defines a strict set of valid values for this attribute, known as autofill field names. These include values like "on", "off", "name", "email", "username", "new-password", "current-password", "address-line1", "postal-code", "cc-number", and many others. When you use a value that doesn't appear in this list — such as "nothanks", "nope", or "false" — the W3C validator reports it as an invalid autofill field name.

A common reason developers use made-up values is frustration with browsers ignoring autocomplete="off". Some browsers (notably Chrome) may still autofill certain fields even when autocomplete="off" is set, particularly for login-related fields. This has led to workarounds using random strings, but these are non-standard and can produce unpredictable behavior across different browsers and assistive technologies.

Why This Matters

• Standards compliance: Invalid attribute values make your HTML non-conforming, which can lead to unexpected browser behavior now or in the future.
• Accessibility: Screen readers and other assistive technologies may use the autocomplete attribute to help users fill in forms. A recognized value like "name" or "email" gives these tools meaningful context, while a random string provides none.
• Browser behavior: Browsers are designed to interpret the standard values. An unrecognized value may be treated inconsistently — some browsers might ignore it, others might treat it as "on", and behavior could change between versions.

How to Fix It

If you want to disable autocomplete, use "off":

<inputtype="text"name="search"autocomplete="off">

If you want to help browsers autofill correctly, use the appropriate autofill field name from the specification:

<inputtype="email"name="email"autocomplete="email">

If autocomplete="off" isn't being respected by the browser (a known issue with some login fields in Chrome), consider these standards-compliant alternatives:

• Use autocomplete="new-password" on password fields where you don't want saved passwords suggested.
• Use a more specific valid token that doesn't match what the browser is trying to autofill.
• Use the readonly attribute and remove it on focus via JavaScript as a supplementary measure.

Examples

❌ Invalid: arbitrary string as autocomplete value

<form>

<labelfor="firstName">First name</label>

<inputtype="text"name="firstName"id="firstName"autocomplete="nothanks">

<labelfor="userEmail">Email</label>

<inputtype="email"name="userEmail"id="userEmail"autocomplete="nope">

</form>

Both "nothanks" and "nope" are not valid autofill field names and will trigger the validation error.

✅ Valid: using "off" to disable autocomplete

<form>

<labelfor="firstName">First name</label>

<inputtype="text"name="firstName"id="firstName"autocomplete="off">

<labelfor="userEmail">Email</label>

<inputtype="email"name="userEmail"id="userEmail"autocomplete="off">

</form>

✅ Valid: using proper autofill field names

<form>

<labelfor="firstName">First name</label>

<inputtype="text"name="firstName"id="firstName"autocomplete="given-name">

<labelfor="userEmail">Email</label>

<inputtype="email"name="userEmail"id="userEmail"autocomplete="email">

<labelfor="newPass">New password</label>

<inputtype="password"name="newPass"id="newPass"autocomplete="new-password">

</form>

Using descriptive autofill tokens like "given-name", "email", and "new-password" is the best approach when you want browsers and assistive technologies to understand your form fields. For a complete list of valid autofill field names, refer to the WHATWG HTML specification's autofill section.

The HTML specification defines specific rules about which autocomplete values can be used on which form elements. The street-address token is categorized as a "multiline" autofill field because street addresses often span multiple lines (e.g., "123 Main St\nApt 4B"). Since <input> elements only accept single-line text, the spec prohibits using street-address with them. The <textarea> element, on the other hand, naturally supports multiline content, making it the appropriate host for this token.

This matters for several reasons. First, browsers use autocomplete values to offer autofill suggestions. When the element type doesn't match the expected data format, browsers may not autofill correctly or may ignore the hint entirely. Second, standards compliance ensures consistent behavior across different browsers and assistive technologies. Third, using the correct pairing improves the user experience — users expect their full street address to appear in a field that can actually display it properly.

You have two approaches to fix this:

1. Use a <textarea> — If you want the full street address in a single field, switch from <input> to <textarea>. This is the most semantically correct choice when you expect multiline address data.

2. Use line-specific tokens on <input> elements — If your form design uses separate single-line fields for each part of the address, use address-line1, address-line2, and address-line3 instead. These tokens are explicitly allowed on <input> elements.

Examples

❌ Invalid: street-address on an <input>

<labelfor="address">Street Address</label>

<inputtype="text"id="address"name="address"autocomplete="street-address">

This triggers the validation error because street-address requires a multiline control.

✅ Fix: Use a <textarea> with street-address

<labelfor="address">Street Address</label>

<textareaid="address"name="address"autocomplete="street-address"></textarea>

The <textarea> supports multiline text, so street-address is valid here.

✅ Fix: Use line-specific tokens on <input> elements

<labelfor="address1">Address Line 1</label>

<inputtype="text"id="address1"name="address1"autocomplete="address-line1">

<labelfor="address2">Address Line 2</label>

<inputtype="text"id="address2"name="address2"autocomplete="address-line2">

The address-line1, address-line2, and address-line3 tokens are single-line autofill fields and are perfectly valid on <input> elements. This approach is common in forms that break the address into separate fields for apartment numbers, building names, or other details.

Summary of allowed pairings

Choose the approach that best fits your form layout. If you prefer a single address field, use <textarea> with street-address. If you prefer structured, separate fields, use <input> elements with the appropriate address-line tokens.

The HTML specification defines specific rules about which autocomplete autofill field names can be paired with which input types. The tel-national token (which represents a phone number without the country code) is classified as requiring a text-based input control. Meanwhile, <input type="tel"> is a specialized control that the spec treats differently from a plain text field. When the validator encounters tel-national on a type="tel" input, it flags the mismatch because the autofill field name is not allowed in that context.

This might seem counterintuitive — a national telephone number value on a telephone input feels like a natural fit. However, the distinction exists because type="tel" already implies a complete telephone number, and the spec maps the broader tel autocomplete token to it. The more granular telephone tokens like tel-national, tel-country-code, tel-area-code, tel-local, tel-local-prefix, and tel-local-suffix are designed for type="text" inputs where a phone number is being broken into individual parts across multiple fields.

Getting this right matters for browser autofill behavior. When the autocomplete value and input type are properly paired according to the spec, browsers can more reliably populate the field with the correct portion of the user's stored phone number. An invalid pairing may cause autofill to silently fail or behave unpredictably across different browsers.

How to fix it

You have two options:

1. Change the input type to text — Use type="text" if you specifically want the national portion of a phone number (without the country code). This is the right choice when you're splitting a phone number across multiple fields.
2. Change the autocomplete value to tel — Use autocomplete="tel" if you want a single field for the full phone number. This pairs correctly with type="tel".

Examples

❌ Invalid: tel-national on type="tel"

<labelfor="phone">Phone number</label>

<inputid="phone"name="phone"type="tel"autocomplete="tel-national">

This triggers the validation error because tel-national is not allowed on a type="tel" input.

✅ Fix option 1: Change input type to text

<labelfor="phone">Phone number (without country code)</label>

<inputid="phone"name="phone"type="text"autocomplete="tel-national">

Using type="text" satisfies the spec's requirement for the tel-national autofill token. This is ideal when collecting just the national portion of a number.

✅ Fix option 2: Change autocomplete to tel

<labelfor="phone">Phone number</label>

<inputid="phone"name="phone"type="tel"autocomplete="tel">

Using autocomplete="tel" is the correct pairing for type="tel" and tells the browser to autofill the complete phone number.

✅ Splitting a phone number across multiple fields

When you need separate fields for different parts of a phone number, use type="text" with the granular autocomplete tokens:

<fieldset>

<legend>Phone number</legend>

<labelfor="country-code">Country code</label>

<inputid="country-code"name="country-code"type="text"autocomplete="tel-country-code">

<labelfor="national">National number</label>

<inputid="national"name="national"type="text"autocomplete="tel-national">

</fieldset>

The autocomplete attribute does not accept "telephone" as a valid value — the correct value is "tel".

The autocomplete attribute helps browsers autofill form fields with previously saved user data. Each field type has a specific token defined in the HTML specification. For phone numbers, the valid token is "tel", not "telephone". Other related tokens include "tel-country-code", "tel-area-code", "tel-local", and "tel-extension" for more granular phone number parts.

Using the correct token ensures that browsers can properly suggest stored phone numbers to users, improving the form-filling experience.

Invalid Example

<labelfor="phone">Phone number</label>

<inputtype="tel"id="phone"name="phone"autocomplete="telephone">

Valid Example

<labelfor="phone">Phone number</label>

<inputtype="tel"id="phone"name="phone"autocomplete="tel">