HTML Datalist

Previously, select forced a closed pick — one known option value from a fixed list. Datalist is a different job: you still type into a normal input, but the browser can offer suggestions. Users may choose a hint or keep typing something the list never listed.

Why datalist exists

Search boxes, “favorite color,” and city fields often need common answers without forbidding uncommon ones. A closed <select> rejects anything off-list. A plain text input offers no hints. <datalist> fills the gap: suggestion chips or a dropdown of hints while the field stays free text. The suggestions live in <option value="…"> children; the input points at the list with list="…".

Direct answer

1) Write <datalist id="browsers"> with nested <option value="Firefox"> (and siblings).
2) On the text control, set list="browsers" so the ids match.
3) Keep a visible <label> and a name on the input — the datalist itself does not submit.
4) The user can pick a suggestion or type a custom string; both are valid.
5) Use <select> when the answer must be one of the listed values only — that was the previous lesson.

📊 Datalist pieces beginners use

Piece	Role	Beginner tip
datalist	Suggestion container	Hidden list of hints; not a visible form control alone
option (inside datalist)	One suggestion	Prefer value= for the hinted string
list (on input)	Points to datalist	Must equal the datalist’s id
id (on datalist)	Hook for list=	Unique on the page
input	Typed field that submits	Owns name=; suggestions are optional help
label	Accessible name	Still required — list suggestions are not a label
name (on input)	Submit key	What posts is whatever is in the input

Browser suggestions demo

A classic demo pairs a labeled browser field with a datalist of common names. Focus or type and the browser may show Firefox, Chrome, Edge, or Safari. Typing “Brave” still works — the list never blocked it.

Input with browser datalist

html

<label for="browser">Browser</label>
<input id="browser" name="browser" list="browsers" placeholder="Type or choose">
<datalist id="browsers">
<option value="Firefox">
<option value="Chrome">
<option value="Edge">
<option value="Safari">
</datalist>

Reading the browser demo

The control that submits is the input, not the datalist
list="browsers" must match datalist id="browsers"
Each option value="…" is a suggestion string
name="browser" keys whatever ends up in the input
label for="browser" names the field for assistive tech
Unlike last lesson’s select, nothing forces the user to stay on the four names

City suggestions with datalist

A second snippet shows a shipping-style city field: suggestions for Tehran, Isfahan, and Shiraz, while the courier can still type a village name. Contrast this mentally with the previous closed city <select> — same topic, different contract.

City input with datalist

html

<form action="/ship" method="post">
<label for="city">City</label>
<input id="city" name="city" list="cities" placeholder="Start typing a city" autocomplete="off">

<datalist id="cities">
<option value="Tehran">
<option value="Isfahan">
<option value="Shiraz">
</datalist>

<button type="submit">Continue</button>
</form>

Reading the city demo

Same label + name pattern as other inputs
list / id pairing wires the hints
Submitted value is the input’s text — chosen or typed
autocomplete="off" can reduce the browser’s own history colliding with your list (optional)
Next lesson moves to broader accessibility — labeling and structure beyond one control

Choosing datalist vs select vs plain input

Must pick from a fixed set (plan tier, country code you validate): <select> + <option>
Hints welcome, custom text OK (browser, city, tag): <input> + list + <datalist>
No suggestions needed: plain <input type="text">
Datalist does not replace label or name on the input
Do not nest the datalist inside the input; place it as a sibling (or elsewhere) and link by id
Support varies slightly by browser UI — teach the pairing, not pixel-perfect chrome

Practice — wire suggestions

Copy the browser demo; add a fifth option value="Opera".
Break the match once (list="browsers" vs id="browserz") and confirm suggestions vanish — then fix it.
Type a custom browser name that is not in the list; confirm the input still holds it.
Build the city datalist; add Mashhad as a fourth suggestion.
Rewrite the city field as a closed <select> with the same three cities — write one sentence on how submit rules differ.
Write one sentence: datalist suggests; select restricts.
Peek ahead: accessible naming and structure across the page belong in the next accessibility lesson.

Easy mistakes

Mismatched list and datalist id so no suggestions appear
Expecting datalist to reject custom typing (that behavior is closer to select)
Forgetting label on the input
Forgetting name on the input so nothing posts
Putting name on the datalist instead of the input
Empty <option> tags with no value (and no useful text)
Copying a select-only mental model into a free-text field

Summary

<datalist> + <option value> = suggestions for an input
Connect with list on the input and matching id on the datalist
Users may still type values outside the list
Label and name stay on the input
Use <select> when the choice must be closed
Next: accessibility basics for clearer, usable pages

🧠 Test Your Knowledge

Ready to Start

Test Your Knowledge

Challenge yourself with this interactive quiz and see how well you understand the topic

❓

Questions

🎯

70%

To Pass

♾️

∞

Time

🔄

∞

Attempts

📝 Instructions

Read each question carefully
Select the best answer for each question
You can retake the quiz as many times as you want
Your progress will be shown at the top