The “full-address” autocomplete token

syntax

A token for the autocomplete attribute, extending the HTML autofill field names. The spec’s own usage example (§5, quoted verbatim):

<form autocomplete="full-address">
  <input name="country" autocomplete="country">
  <div id="dynamic-address-fields"></div>
</form>

Documented divergence (2026-10-04): the spec prose says the token applies “when a form control has the autocomplete attribute set”, while its only example sets it on the <form> element itself. The draft does not reconcile the two; both readings are recorded here rather than silently picking one.

inputs

The token itself is the only input: it is written statically (or via script) into the autocomplete attribute. It takes no arguments or modifiers, and the spec defines no combination grammar with the existing HTML autofill detail tokens (e.g. shipping/billing) — unspecified as of the 25 September 2026 draft (verified 2026-10-04).

outputs

Two observable effects, both normatively SHOULD-level: the browser requests permission to access the user’s complete address data (beyond the rendered fields), and — granted that — the page receives comprehensive address information through the AutofillEvent’s autofillValues, enabling it to add the fields the address actually needs. There is no return value or reflected state; the spec defines no way to query whether permission was granted other than observing the event.

errors

The spec defines no error surface for the token (verified against the full draft, 2026-10-04). In a browser that does not implement it, "full-address" is simply not a recognized autofill field name, so autofill processing behaves as if no hint were given — a silent degradation, not an exception. If the permission is declined, the spec does not say what (if anything) is reported to the page; that is a documented unknown.

context and exposure

Markup-level: usable on autofill-capable form markup in any document where the parent feature is enabled (experimental flag / origin trial — see the overview). It pairs with a document-level autofill listener; without one, requesting the full address has no consumer, since extra fields arrive via the event.

lifecycle

Intended flow per §5 combined with §4: the user invokes autofill on a form carrying the token → the browser SHOULD request permission for the complete address → the autofill event fires at the document carrying entries for the full data set → the page builds the missing fields (the example’s dynamic-address-fields container) and calls refill() → the browser fills the completed form. The permission’s persistence (one-shot vs. remembered) is not specified in the draft (2026-10-04).

examples

WICG draft-intended flow, not verified Chrome behavior: the spec’s verbatim markup plus an illustrative event-side consumer. It inspects tuple entries, inserts labelled country-specific controls, and requests a refill only after changing the form (JS part gendn-derived from spec §1.2). Pinned Chromium uses object entries instead of the tuples this draft example destructures:

<form autocomplete="full-address">
  <input name="country" autocomplete="country">
  <div id="dynamic-address-fields"></div>
</form>

<script>
document.addEventListener('autofill', async (event) => {
  // With full-address, autofillValues may carry MORE fields than the
  // form currently renders. Build inputs for them, then refill.
  const holder = document.getElementById('dynamic-address-fields');

  let countryValue = null;
  for (const [element, value] of event.autofillValues) {
    if (element.autocomplete === 'country') countryValue = value;
  }

  // US addresses need a state and a ZIP code this form doesn't render yet.
  let changed = false;
  if (countryValue === 'US' &&
      !holder.querySelector('[autocomplete="address-level1"]')) {
    const stateLabel = document.createElement('label');
    stateLabel.textContent = 'State ';
    const state = document.createElement('input');
    state.name = 'state';
    state.autocomplete = 'address-level1';
    stateLabel.append(state);

    const zipLabel = document.createElement('label');
    zipLabel.textContent = 'ZIP code ';
    const zip = document.createElement('input');
    zip.name = 'zip';
    zip.autocomplete = 'postal-code';
    zipLabel.append(zip);

    holder.append(stateLabel, zipLabel);
    changed = true;
  }

  // Request a second fill only if the form actually changed; refill()
  // rejects with InvalidStateError after the refill timeout, and is null
  // on the retry dispatch.
  if (changed && event.refill !== null) await event.refill();
});
</script>

browser compatibility

Interim table — explicit unknowns. Neither BCD api/AutofillEvent.json nor any BCD html.* key records the token, and webstatus.dev has no web-features entry (both checked 2026-10-04):

security and privacy

This token widens disclosure by design — it asks for address data beyond the rendered fields — which is why §5 couples it to a permission request rather than silent access. The general rules of §6 still apply: values flow only after explicit user consent to autofill, and the post-refill consent note covers the newly added fields.

see also

• Autofill event — overview
• AutofillEvent() and AutofillEventInit
• Autofill Event specification (WICG)
• HTML Living Standard — Autofill field names
• chromestatus — Autofill event (5137581018841088)