<datalist> offers a genuinely useful middle ground between a plain text input and a restrictive <select> dropdown — native, browser-handled suggestions that never prevent free-text entry.
1Connecting An Input To Its Suggestions
A <datalist> element contains a series of <option> elements, each representing one suggested value. It's connected to a specific <input> via the input's list attribute, whose value must match the datalist's id — an id-reference pairing structurally similar to how <label for> connects to an input's id, covered in the Accessible Forms lesson earlier in this course.
The datalist itself doesn't need to be visually adjacent to or nested within the input; it can live anywhere in the document, as long as the id reference is correct, similar to the flexibility label/for pairing offers.
2Suggestions, Never A Restriction
The single most important thing to understand about datalist is what it *doesn't* do: it never restricts the field's actual acceptable values. Unlike <select>, where the submitted value must be one of the defined <option>s, an input connected to a datalist remains a genuinely free-text field — a user can ignore every suggestion and type something else entirely, and it submits normally.
This makes datalist semantically and functionally distinct from <select>: it's purely a UX convenience for speeding up common entries, never a data-integrity or restriction mechanism. Actual value restriction, if needed, still requires pattern or other validation constraints layered on top.
3A Lightweight, Native Combobox Alternative
Building a fully custom autocomplete combobox from scratch — correct keyboard navigation (arrow keys, Enter, Escape), correct ARIA roles and states, correct screen reader announcement behavior — represents genuine implementation effort, as covered in the ARIA Roles lesson's discussion of widget patterns requiring manual keyboard handling.
datalist provides a native, zero-JavaScript approximation of this pattern for many simpler use cases: suggest common cities, common search terms, common tags — where the visual customization limitations of the native browser dropdown are an acceptable tradeoff for the significant implementation and accessibility effort saved.
4Step-by-Step Breakdown
Suggestions, Not Restrictions. <datalist> gives an <input> a native dropdown of suggested values as the user types — but crucially, unlike <select>, the user isn't restricted to the listed options; they can still type anything else entirely. It's autocomplete, not a picker.
list Connects An Input To Its Suggestions. An <input>'s list attribute references a <datalist>'s id, and each <option> inside that <datalist> becomes a suggested value the browser offers as the user types — connected purely by id reference, similar to label/for association.
Connecting input To datalist. How is an <input> connected to its <datalist> of suggestions?
- →The <datalist> must be nested directly inside the <input>
- →The input's list attribute references the datalist's id
- →They must be immediately adjacent sibling elements
Users Can Still Enter Any Value, Not Just Suggestions. This is the core distinction from <select>: datalist options are pure suggestions to speed up common entries, but the field remains a free-text input — a user can type a value not in the list at all, and it submits normally.
datalist vs select Restriction. If a datalist's options are 'Chrome', 'Firefox', and 'Safari', can a user still submit the value 'Opera'?
- →No, only listed options can be submitted, like <select>
- →Yes, the field remains free-text; suggestions don't restrict what can be entered
- →Only with additional JavaScript to bypass the restriction
A Lightweight Alternative To A Custom Combobox. Building a fully custom autocomplete combobox with JavaScript and ARIA requires significant implementation effort to get keyboard navigation and screen reader behavior right (recall the ARIA Roles lesson's widget patterns). datalist provides a native, zero-JS approximation for many simpler use cases.
datalist vs Custom Combobox. For a simple 'suggest common values but allow anything' use case, why might <datalist> be preferable to a custom JavaScript combobox?
- →It's more visually customizable than a custom combobox
- →It requires zero JavaScript and gets correct native keyboard/accessibility behavior for free
- →It only has an advantage specifically on mobile devices
Datalist Mastered. You now know how to connect an input to a datalist via the list/id reference, understand that datalist provides suggestions without restricting free-text entry, and when it serves as a lightweight, zero-JS alternative to a custom combobox implementation.
Suggest Cities As The User Types. Connect an input to a datalist of city suggestions via the list attribute.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1datalist Suggestions Are Announced Natively By Screen Readers Without Additional ARIA Work
Because it's a native HTML mechanism, browsers handle the accessible announcement of available suggestions automatically, unlike a custom combobox which requires careful manual ARIA implementation to achieve the same result.
SEO Implications
- 1
datalist Has No Direct SEO Impact But Reduces JavaScript Bundle Weight Versus A Custom Combobox
Choosing a native solution over a JavaScript library for simple suggestion use cases avoids unnecessary bundle size, indirectly supporting page performance metrics.
Best Practices
Use datalist Specifically When Suggestions Should Speed Up Entry Without Restricting It
This is its precise, correct use case — for genuinely restricted choices, <select> remains the correct, simpler element instead.
Consider A Custom Combobox Implementation Only When datalist's Visual/Behavioral Limitations Are A Genuine Blocker
The native browser dropdown styling can't be customized, and behavior varies somewhat across browsers — reserve the significantly larger custom implementation effort for cases where this genuinely matters.
Frequent Bugs
A developer expects a datalist-connected input to reject values not in the suggestion list, similar to a <select>.
This is expected behavior — datalist never restricts input. Add pattern or other validation constraints if actual value restriction is required.
A datalist's suggestions never appear for a connected input.
Verify the input's list attribute value exactly matches the datalist's id attribute value.
Real-World Examples
A Search Field With Common Term Suggestions
A site search input suggesting popular search terms while still accepting any free-text query.
<input type="search" list="popular-searches" name="q">
<datalist id="popular-searches">
<option value="pricing"></option>
<option value="documentation"></option>
</datalist>