HTML attribute: autocomplete

The HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field.

It is available on <input> elements that take a text or numeric value as input, <textarea> elements, <select> elements, and <form> elements.

Try it


The autocomplete attribute provides a hint to the user agent specifying how to, or indeed whether to, prefill a form control. The attribute value is either the keyword off or on, or an ordered list of space-separated tokens.

<input autocomplete="off" />
<input autocomplete="on" />
<input autocomplete="shipping street-address" />
<input autocomplete="section-user1 billing postal-code" />

If an <input>, <select> or <textarea> element has no autocomplete attribute, the browser will use the autocomplete attribute of the element's owning form. The owning form is either the <form> matching the id specified by the form attribute of the element (if present) or, more commonly, the <form> the element is nested in.

Note: In order to provide autocompletion, user-agents might require <input>/<select>/<textarea> elements to:

  1. Have a name and/or id attribute
  2. Be descendants of a <form> element
  3. Be owned by a form with a submit button

If the same list of tokens is used in more than one form control, the user-agent will autocomplete all occurrences of the same autocomplete value with the same data value.

Some tokens may be used more than once with potentially different expected values, such as the zip-code token in a form that contains both shipping and billing addresses. Including multiple different tokens in a space-separated list causes the associated form controls to be given unique autocomplete values: in this case, autocomplete="shipping zip-code" and autocomplete="billing zip-code".

Some autocomplete values may need to be re-used multiple times. For example, a form may contain multiple shipping addresses and therefore multiple occurrences of "shipping zip-code" while still expecting different values. To make the autocomplete value unique in these cases, the first token in the space-separated list of tokens can be a section-* token, where the token's first eight characters are always the string "section-", followed by an alphanumeric string. All form fields given the section-* token with the same alphanumeric string belong to the same named group.

If including the autocomplete attribute on hidden input elements (<input type="hidden">), its value must be an ordered list of space-separated tokens; the on and off keywords are not allowed.

The source of the suggested values is generally up to the browser; typically values come from past values entered by the user, but they may also come from pre-configured values. For instance, a browser might let the user save their name, address, phone number, and email addresses for autocomplete purposes. The browser may also offer the ability to save encrypted credit card information, for autocompletion following an authentication procedure.


The attribute value is either the keyword off or on, or a space-separated <token-list> that describes the meaning of the autocompletion value.


The browser is not permitted to automatically enter or select a value for this field. It is possible that the document or application provides its own autocomplete feature, or that security concerns require that the field's value not be automatically entered.

Note: In most modern browsers, setting autocomplete to "off" will not prevent a password manager from asking the user if they would like to save username and password information, or from automatically filling in those values in a site's login form. See the autocomplete attribute and login fields.


The browser is allowed to automatically complete the input. No guidance is provided as to the type of data expected in the field, so the browser may use its own judgement.


An ordered set of space-separated tokens consisting of autofill detail tokens. The detail tokens include:


Defines the name for a group of form controls. A token whose first eight characters are the string "section-", case-insensitive, followed by additional characters. If present, this token must be the first token in the space-separated list of tokens. All form controls that start with the same token belong to the named group.


The field expects the value to be a person's full name. Using "name" rather than breaking the name down into its components is generally preferred because it avoids dealing with the wide diversity of human names and how they are structured; however, you can use the following autocomplete values if you do need to break the name down into its components:


The prefix or title, such as "Mrs.", "Mr.", "Miss", "Ms.", "Dr.", or "Mlle.".


The given (or "first") name.


The middle name.


The family (or "last") name.


The suffix, such as "Jr.", "B.Sc.", "PhD.", "MBASW", or "IV".


A nickname or handle.


An email address.


A username or account name.


A new password. When creating a new account or changing passwords, this should be used for an "Enter your new password" or "Confirm new password" field, as opposed to a general "Enter your current password" field that might be present. This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password (see also Preventing autofilling with autocomplete="new-password").


The user's current password.


A one-time password (OTP) for verifying user identity that is used as an additional factor in a sign-in flow. Most commonly this is a code received via some out-of-channel mechanism, such as SMS, email, or authenticator application.


A job title, or the title a person has within an organization, such as "Senior Technical Writer", "President", or "Assistant Troop Leader".


A company or organization name, such as "Acme Widget Company" or "Girl Scouts of America".


A street address. This can be multiple lines of text, and should fully identify the location of the address within its second administrative level (typically a city or town), but should not include the city name, ZIP or postal code, or country name.


The street address to send the product. This can be combined with other tokens, such as "shipping street-address" and "shipping address-level2".


The street address to associate with the form of payment used. This can be combined with other tokens, such as "billing street-address" and "billing address-level2".

"address-line1", "address-line2", "address-line3"

Each individual line of the street address. These should only be present if the "street-address" is not present.


The finest-grained administrative level, in addresses which have four levels.


The third administrative level, in addresses with at least three administrative levels.


The second administrative level, in addresses with at least two of them. In countries with two administrative levels, this would typically be the city, town, village, or other locality in which the address is located.


The first administrative level in the address. This is typically the province in which the address is located. In the United States, this would be the state. In Switzerland, the canton. In the United Kingdom, the post town.


A country or territory code.


A country or territory name.


A postal code (in the United States, this is the ZIP code).


The full name as printed on or associated with a payment instrument such as a credit card. Using a full name field is preferred, typically, over breaking the name into pieces.


A given (first) name as given on a payment instrument like a credit card.


A middle name as given on a payment instrument or credit card.


A family name, as given on a credit card.


A credit card number or other number identifying a payment method, such as an account number.


A payment method expiration date, typically in the form "MM/YY" or "MM/YYYY".


The month in which the payment method expires.


The year in which the payment method expires.


The security code for the payment instrument; on credit cards, this is the 3-digit verification number on the back of the card.


The type of payment instrument (such as "Visa" or "Master Card").


The currency in which the transaction is to take place.


The amount, given in the currency specified by "transaction-currency", of the transaction, for a payment form.


A preferred language, given as a valid BCP 47 language tag.


A birth date, as a full date.


The day of the month of a birth date.


The month of the year of a birth date.


The year of a birth date.


A gender identity (such as "Female", "Fa'afafine", "Hijra", "Male", "Nonbinary"), as freeform text without newlines.


A full telephone number, including the country code. If you need to break the phone number up into its components, you can use these values for those fields:


The country code, such as "1" for the United States, Canada, and other areas in North America and parts of the Caribbean.


The entire phone number without the country code component, including a country-internal prefix. For the phone number "1-855-555-6502", this field's value would be "855-555-6502".


The area code, with any country-internal prefix applied if appropriate.


The phone number without the country or area code. This can be split further into two parts, for phone numbers which have an exchange number and then a number within the exchange. For the phone number "555-6502", use "tel-local-prefix" for "555" and "tel-local-suffix" for "6502".


A telephone extension code within the phone number, such as a room or suite number in a hotel or an office extension in a company.


A URL for an instant messaging protocol endpoint, such as "".


A URL, such as a home page or company website address as appropriate given the context of the other fields in the form.


The URL of an image representing the person, company, or contact information given in the other fields in the form.


Passkeys generated by the Web Authentication API, as requested by a conditional navigator.credentials.get() call (i.e., one that includes mediation: 'conditional'). See Sign in with a passkey through form autofill for more details.

See the WHATWG Standard for more detailed information.

Note: The autocomplete attribute also controls whether Firefox will — unlike other browsers — persist the dynamic disabled state and (if applicable) dynamic checkedness of an <input> element, <textarea> element, or entire <form> across page loads. The persistence feature is enabled by default. Setting the value of the autocomplete attribute to off disables this feature. This works even when the autocomplete attribute would normally not apply by virtue of its type. See Firefox bug 654072.


  <label for="cc-number">Enter your credit card number</label>
  <input name="cc-number" id="cc-number" autocomplete="off" />

Administrative levels in addresses

The four administrative level fields (address-level1 through address-level4) describe the address in terms of increasing levels of precision within the country in which the address is located. Each country has its own system of administrative levels, and may arrange the levels in different orders when addresses are written.

address-level1 always represents the broadest administrative division; it is the least-specific portion of the address short of the country name.

Form layout flexibility

Given that different countries write their address in different ways, with each field in different places within the address, and even different sets and numbers of fields entirely, it can be helpful if, when possible, your site is able to switch to the layout expected by your users when presenting an address entry form, given the country the address is located within.


The way each administrative level is used will vary from country to country. Below are some examples; this is not meant to be an exhaustive list.

United States

A typical home address within the United States looks like this:

432 Anywhere St Exampleville CA 95555

In the United States, the least-specific portion of the address is the state, in this case "CA" (the official US Postal Service shorthand for "California"). Thus address-level1 is the state, or "CA" in this case.

The second-least specific portion of the address is the city or town name, so address-level2 is "Exampleville" in this example address.

United States addresses do not use levels 3 and up.

United Kingdom

Address input forms in the UK should contain one address level and one, two or three address lines, depending on the address. A complete address would look like so:

103 Frogmarch Street Upper-Wapping Winchelsea TN99 8ZZ

The address levels are:

  • address-level1: The post town — "Winchelsea" in this case.
  • address-line2: The locality — "Upper-Wapping" in this case.
  • address-line1: The house/street particulars — "103 Frogmarch Street".

The postcode is separate. Note that you can actually use just the postcode and address-line1 to successfully deliver mail in the UK, so they should be the only mandatory items, but usually people tend to provide more details.


China can use as many as three administrative levels: the province, the city, and the district.

The 6 digit postal code is not always needed but when supplied it is placed separately with a label for clarity. For example:

北京市东城区建国门北大街 8 号华润大厦 17 层 1708 单元 邮编:100005


An address in Japan is typically written in one line, in an order from the least-specific to more-specific portions (in reverse order to the United States). There are two or three administrative levels in an address. Additional line can be used to show building names and room numbers. The postal code is separate. For example:

〒 381-0000 長野県長野市某町 123

"〒" and following seven digits shows the postal code.

address-level1 is used for prefectures or the Tokyo Metropolis; "長野県" (Nagano Prefecture) is in this case. address-level2 is typically used for cities, counties, towns and villages; "長野市" (Nagano City) in this case. "某町 123" is address-line1 which consists of an area name and a lot number.


No specification found

No specification data found for html.global_attributes.autocomplete.
Check for problems with this page or contribute a missing spec_url to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Browser compatibility

BCD tables only load in the browser

See also