The <datalist> element attaches a list of suggested autocomplete values to a text input — while still letting the user type any value they want, not just the suggestions.
Syntax
<input type="text" list="suggestions">
<datalist id="suggestions">
<option value="Suggestion One">
<option value="Suggestion Two">
</datalist>Basic Example
<label for="course-search">Search a course</label>
<input type="text" id="course-search" name="course-search" list="course-options">
<datalist id="course-options">
<option value="Data Science">
<option value="Full Stack Development">
<option value="Cloud & DevOps">
</datalist>Browser output: as the user starts typing, a native dropdown of matching suggestions appears beneath the field — but unlike <select>, they can still submit any freely typed value, not just one of the listed suggestions.
How It Works
The list attribute on the <input> connects it to a <datalist>'s id — matching the same for/id-style pairing pattern used elsewhere in HTML.
Important Attributes
| Attribute | Purpose |
|---|---|
list | On the input — connects it to a <datalist>'s id |
id | On the datalist — the target the input's list points to |
Comparison: select vs datalist
<select> | <datalist> + <input> | |
|---|---|---|
| Free typing allowed? | No — must pick from the list | Yes — suggestions are optional hints, not a hard constraint |
| Use when... | Only a fixed set of values is genuinely valid | Common values exist, but custom input should still be accepted |
Real-World Example
<label for="city">City</label>
<input type="text" id="city" name="city" list="cities">
<datalist id="cities">
<option value="Delhi">
<option value="Noida">
<option value="Gurugram">
</datalist>A city field that suggests common options but still accepts any city the user actually types — exactly the flexible middle ground <datalist> is built for.
Common Mistakes
- Assuming
<datalist>restricts input the way<select>does — it never does; any typed value is still valid and will be submitted - Forgetting the
list/idconnection, leaving the datalist orphaned and having no effect at all
Best Practices
- Use
<datalist>when common suggestions exist but the field shouldn't be strictly limited to them - Use
<select>instead when only a fixed, closed set of values is genuinely valid
Accessibility Considerations
Support quality for datalist suggestions varies somewhat across screen readers — always ensure the field remains fully usable by plain typing alone, since that's the guaranteed, universal fallback.
SEO Considerations
No direct ranking effect.
Browser & Modern HTML Notes
Well-supported in modern browsers, though the exact visual styling of the suggestion dropdown is largely outside CSS's control, similar to <select>.
Mini Practice
- Build a text input with a datalist of 4 suggested values.
- Explain, in your own words, why datalist suggestions don't restrict what a user can actually submit.
