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

<form action="/submit" method="post">
  <input type="hidden" name="token" value="abc123" autocomplete="off">
  <button type="submit">Submit</button>
</form>

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

<form action="/submit" method="post">
  <input type="hidden" name="session-id" value="xyz789" autocomplete="on">
  <button type="submit">Submit</button>
</form>

Correct: removing the autocomplete attribute

<form action="/submit" method="post">
  <input type="hidden" name="token" value="abc123">
  <button type="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:

<form action="/checkout" method="post">
  <input type="hidden" name="txn" value="TXN-001" autocomplete="transaction-id">
  <button type="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>
    <input type="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>
    <input type="checkbox" name="terms"> I agree to the terms
  </label>
</form>

❌ Invalid: autocomplete on radio buttons

<form>
  <fieldset>
    <legend>Preferred contact method</legend>
    <label>
      <input type="radio" name="contact" value="email" autocomplete="off"> Email
    </label>
    <label>
      <input type="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>
      <input type="radio" name="contact" value="email"> Email
    </label>
    <label>
      <input type="radio" name="contact" value="phone"> Phone
    </label>
  </fieldset>
</form>

❌ Invalid: autocomplete on a file input

<form>
  <label for="resume">Upload resume:</label>
  <input type="file" id="resume" name="resume" autocomplete="off">
</form>

✅ Fixed: remove autocomplete from the file input

<form>
  <label for="resume">Upload resume:</label>
  <input type="file" id="resume" name="resume">
</form>

✅ Valid: autocomplete on supported types

<form>
  <label for="email">Email:</label>
  <input type="email" id="email" name="email" autocomplete="email">

  <label for="bday">Birthday:</label>
  <input type="date" id="bday" name="bday" autocomplete="bday">

  <label for="query">Search:</label>
  <input type="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:

<form autocomplete="off">
  <label for="username">Username:</label>
  <input type="text" id="username" name="username">

  <label>
    <input type="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

<label for="company">Company Name</label>
<input type="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

<label for="company">Company Name</label>
<input type="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:

<label for="work-org">Employer</label>
<input type="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

<label for="email">Contact Email</label>
<input type="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

<label for="email">Contact Email</label>
<input type="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:

<label for="work-tel">Work Phone</label>
<input type="tel" id="work-tel" name="work-tel" autocomplete="work tel">

<label for="home-email">Personal Email</label>
<input type="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.

An empty string is not a valid value for the autocomplete attribute on an input element.

The autocomplete attribute controls whether the browser can autofill input values, and it requires a valid, non-empty value according to the HTML specification. Acceptable values are on, off, or specific autocomplete tokens such as name, email, username, etc. Leaving it empty, like autocomplete="", causes validation errors.

Incorrect example:

<input type="text" name="username" autocomplete="">

Correct examples: Enable browser autocomplete:

<input type="text" name="username" autocomplete="on">

Disable browser autocomplete:

<input type="text" name="username" autocomplete="off">

Use a specific token (recommended for forms that collect particular data):

<input type="email" name="useremail" autocomplete="email">

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>
  <label for="user">Username</label>
  <input type="text" id="user" name="username" autocomplete="none">
</form>

Correct: using "off" to disable autofill

<form>
  <label for="user">Username</label>
  <input type="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>
  <label for="user">Username</label>
  <input type="text" id="user" name="username" autocomplete="username">

  <label for="email">Email</label>
  <input type="email" id="email" name="email" autocomplete="email">

  <label for="pwd">New Password</label>
  <input type="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>
  <label for="ship-zip">Shipping postal code</label>
  <input type="text" id="ship-zip" name="ship_zip" autocomplete="shipping postal-code">

  <label for="bill-zip">Billing postal code</label>
  <input type="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

<form autocomplete="nope" action="/submit" method="post">
  <label for="username">Username</label>
  <input type="text" id="username" name="username">
  <button type="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

<form autocomplete="off" action="/submit" method="post">
  <label for="username">Username</label>
  <input type="text" id="username" name="username">
  <button type="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:

<form action="/submit" method="post">
  <label for="username">Username</label>
  <input type="text" id="username" name="username" autocomplete="username">

  <label for="secret">One-time code</label>
  <input type="text" id="secret" name="secret" autocomplete="off">

  <button type="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

<input type="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"

<input type="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:

<input type="text" name="firstName" autocomplete="given-name">

Fixed: common valid autocomplete values in a form

<form method="post" action="/register">
  <label for="name">Full Name</label>
  <input type="text" id="name" name="name" autocomplete="name">

  <label for="email">Email</label>
  <input type="email" id="email" name="email" autocomplete="email">

  <label for="newpass">Password</label>
  <input type="password" id="newpass" name="password" autocomplete="new-password">

  <label for="tel">Phone</label>
  <input type="tel" id="tel" name="phone" autocomplete="tel">

  <button type="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":

<input type="text" name="search" autocomplete="off">

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

<input type="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>
  <label for="firstName">First name</label>
  <input type="text" name="firstName" id="firstName" autocomplete="nothanks">

  <label for="userEmail">Email</label>
  <input type="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>
  <label for="firstName">First name</label>
  <input type="text" name="firstName" id="firstName" autocomplete="off">

  <label for="userEmail">Email</label>
  <input type="email" name="userEmail" id="userEmail" autocomplete="off">
</form>

✅ Valid: using proper autofill field names

<form>
  <label for="firstName">First name</label>
  <input type="text" name="firstName" id="firstName" autocomplete="given-name">

  <label for="userEmail">Email</label>
  <input type="email" name="userEmail" id="userEmail" autocomplete="email">

  <label for="newPass">New password</label>
  <input type="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>

<label for="address">Street Address</label>
<input type="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

<label for="address">Street Address</label>
<textarea id="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

<label for="address1">Address Line 1</label>
<input type="text" id="address1" name="address1" autocomplete="address-line1">

<label for="address2">Address Line 2</label>
<input type="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"

<label for="phone">Phone number</label>
<input id="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

<label for="phone">Phone number (without country code)</label>
<input id="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

<label for="phone">Phone number</label>
<input id="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>
  <label for="country-code">Country code</label>
  <input id="country-code" name="country-code" type="text" autocomplete="tel-country-code">
  <label for="national">National number</label>
  <input id="national" name="national" type="text" autocomplete="tel-national">
</fieldset>