UX Patterns Guide
Back to compare picker

Address entry vs Text input vs Autocomplete vs Dependent fields

Prefer address entry when the user must provide a postal, delivery, billing, service, or eligibility address that downstream systems need as line, locality, region, postal code, and country parts.

Address entry live exampleText input live exampleAutocomplete live exampleDependent fields live example

Decision dimensions

Dimension Address entryText inputAutocompleteDependent fields
UI or UX UI + UX - Structured postal or contact address capture flowUI + UX - Single-line freeform data-entry controlUI + UX - Input widget with suggestion behaviorUI + UX - Controlling and dependent form fields
UI guidance Render address capture as a labelled fieldset or page section with address line, locality, region when needed, postal code, country, and an address lookup only when its coverage is clear.Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.Place the controlling field before the dependent field, label both clearly, and explain the dependency in helper text such as Choose a category first to see valid subcategories.
UX guidance Use address entry when the service needs a complete address for delivery, billing, correspondence, identity, eligibility, routing, tax, or account records and downstream systems need reliable address parts.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Help users complete a known value faster without forcing an incorrect suggestion.Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.
Good UI A benefits claim asks for postcode lookup, lists matching addresses, includes Enter address manually, and then shows editable address line 1, address line 2, town or city, postcode, and country.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed.
Bad UI A form has one full-width Address field with placeholder-only instructions and no country, postcode, apartment, or manual recovery path.The only instruction is placeholder text that disappears when the user starts typing.Placeholder-only label that disappears after typing.A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.
Good UX A user enters SW1A1AA, sees several addresses, selects Flat 2, adds an organization name, and reviews the stored line, town, postcode, and country parts before continuing.A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.Typing filters suggestions while preserving the exact typed value.A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting.
Bad UX A user in a new building cannot proceed because the lookup cannot find the postcode and there is no manual entry option.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.Automatically forcing the first suggestion into the field.A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.
Best fit The product needs a complete postal, delivery, billing, service, or official contact address.The answer is short and user-authored.The list is long but values are known.A downstream field's valid values or requirement depend on a previous answer.
Avoid when The product only needs one short location label, room name, or delivery note.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.The task is open-ended query exploration.The choices are independent and users need to compare them together.
Required state Initial state with country or domestic coverage explained and lookup or manual entry available.Empty untouched state with persistent label and optional hint.Empty input state.No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.
Accessibility burden Group related address fields with a clear heading or legend that states which address is being requested.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Expose combobox expanded state, active descendant, and option labels.Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
Common misuse Forcing every address through a domestic postcode or ZIP lookup.Using placeholder text as the only label or instruction.Forcing the first suggestion when the user did not choose it.Leaving a stale dependent value selected after the controlling field changes.

Address entry

UI or UX
UI + UX - Structured postal or contact address capture flow
UI guidance
Render address capture as a labelled fieldset or page section with address line, locality, region when needed, postal code, country, and an address lookup only when its coverage is clear.
UX guidance
Use address entry when the service needs a complete address for delivery, billing, correspondence, identity, eligibility, routing, tax, or account records and downstream systems need reliable address parts.
Good UI
A benefits claim asks for postcode lookup, lists matching addresses, includes Enter address manually, and then shows editable address line 1, address line 2, town or city, postcode, and country.
Bad UI
A form has one full-width Address field with placeholder-only instructions and no country, postcode, apartment, or manual recovery path.
Good UX
A user enters SW1A1AA, sees several addresses, selects Flat 2, adds an organization name, and reviews the stored line, town, postcode, and country parts before continuing.
Bad UX
A user in a new building cannot proceed because the lookup cannot find the postcode and there is no manual entry option.
Best fit
The product needs a complete postal, delivery, billing, service, or official contact address.
Avoid when
The product only needs one short location label, room name, or delivery note.
Required state
Initial state with country or domestic coverage explained and lookup or manual entry available.
Accessibility burden
Group related address fields with a clear heading or legend that states which address is being requested.
Common misuse
Forcing every address through a domestic postcode or ZIP lookup.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Autocomplete

UI or UX
UI + UX - Input widget with suggestion behavior
UI guidance
Render a labeled text field, suggestion popup, highlighted option, selected value, and no-match state.
UX guidance
Help users complete a known value faster without forcing an incorrect suggestion.
Good UI
Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI
Placeholder-only label that disappears after typing.
Good UX
Typing filters suggestions while preserving the exact typed value.
Bad UX
Automatically forcing the first suggestion into the field.
Best fit
The list is long but values are known.
Avoid when
The task is open-ended query exploration.
Required state
Empty input state.
Accessibility burden
Expose combobox expanded state, active descendant, and option labels.
Common misuse
Forcing the first suggestion when the user did not choose it.

Dependent fields

UI or UX
UI + UX - Controlling and dependent form fields
UI guidance
Place the controlling field before the dependent field, label both clearly, and explain the dependency in helper text such as Choose a category first to see valid subcategories.
UX guidance
Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.
Good UI
An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed.
Bad UI
A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.
Good UX
A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting.
Bad UX
A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.
Best fit
A downstream field's valid values or requirement depend on a previous answer.
Avoid when
The choices are independent and users need to compare them together.
Required state
No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.
Accessibility burden
Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
Common misuse
Leaving a stale dependent value selected after the controlling field changes.
Decision rules
  • Prefer address entry when the user must provide a postal, delivery, billing, service, or eligibility address that downstream systems need as line, locality, region, postal code, and country parts.
  • Prefer text input only for one short address-like value such as a building name, room number, or delivery reference when the product does not need a complete address.
  • Prefer autocomplete when the main interaction is selecting one known record from suggestions; an address lookup may use autocomplete internally, but it still needs editable address fields and a manual path.
  • Prefer dependent fields when the only problem is a controlling answer changing a downstream option set, such as country changing state or province, rather than capturing the whole address.
  • Use a lookup for domestic addresses only when it clearly states the coverage, accepts common postal-code formats, lets users choose among similar addresses, and offers manual entry when the record is missing.
  • Keep address line 2, apartment, flat, unit, building, or organization details available and reviewable; do not discard secondary address information after lookup selection.
  • Use country-specific labels and validation, and avoid forcing a UK postcode, U.S. ZIP code, county, state, or province field on addresses from countries that do not use that part.
  • Validate required address parts with field-specific errors, but allow users to proceed through a review or exception path when a real address cannot be verified by the lookup provider.
  • Apply browser autocomplete tokens to individual address fields when the fields are structured, or street-address when the product intentionally accepts a single multi-line address block.
  • Route consequential address changes to review before submit when the address affects payment, delivery, eligibility, identity, tax, or official correspondence.
Inspect live examples
Address entryText inputAutocompleteDependent fields
Failure modes
  • A checkout treats the first lookup result as final and ships to the wrong flat because the user never chose a specific address.
  • A service forces every user through a postcode lookup even when international, rural, new-build, or privacy-sensitive addresses are not listed.
  • A one-line field stores an address blob, so downstream mail, tax, validation, and customer support systems cannot tell town, postcode, or country apart.
  • Changing the country leaves a stale state field and postcode rule active, causing valid international addresses to fail validation.
  • The form silently removes apartment, suite, organization, or care-of details that are needed for successful delivery.
  • The address verifier replaces user-entered text without showing the proposed correction and without letting the user keep a real but unverified address.