Search Box in HTML: The Input Type Nobody Uses

Most search box HTML on the web is a plain text input with a magnifier icon glued next to it. HTML has had a dedicated search input type for years, and it is still the field almost nobody reaches for. Here is what it changes, what it does not, and how to build a site search form that works without JavaScript.

Sophie ParkerPublished October 16, 2026 · 9 min read

Key takeaways The short version, before the details.

An input with type search is a text field with search semantics: same attributes, different soft keyboard, a clear button in some browsers, and a searchbox role for screen readers.
It does not search anything on its own. Your form action, method and server do the searching.
Site search belongs on GET, so the query lands in the URL and stays shareable and bookmarkable.
Wrap the form in a search element or give it role search, and label the field properly instead of leaning on the placeholder.

On this page

What is input type search in HTML?
Search box HTML: the markup that works
Why should a search form use GET?
Which attributes work on a search field in HTML
How to style a search bar in HTML
Is an HTML search input accessible by default?
When input type search is the wrong choice
Frequently asked questions

What is input type search in HTML?

An input with type search is a single line text field that tells the browser what the field is for. The value behaves exactly like a text input: line breaks are stripped, there is no built in format, and nothing is validated for you.

Swapping the type costs you one word:

<!-- what most sites ship -->
<input type="text" name="q" placeholder="Search">

<!-- the input type that exists for exactly this -->
<input type="search" name="q" placeholder="Search">

Three things change, and none of them are cosmetic sugar:

The accessibility role. A text input is exposed as a textbox. A search input is exposed as a searchbox, so assistive technology can tell the user this field runs a query rather than collecting data.
The soft keyboard. On phones and tablets, browsers commonly relabel the return key as a search action for this type. It is a heuristic, not a guarantee, which is why the explicit attribute in the table below exists.
The clear button. Chromium and Safari draw a small clear control inside the field once it holds a value. Firefox does not, so treat it as a nice extra rather than a feature you depend on.

It does not search. There is no built in search engine behind this input type. It is a labelled text box. What turns it into site search is the form around it and whatever answers the request.

The full behaviour, including the value sanitisation rules, is written up on MDN and defined in the HTML standard.

A working site search box is four elements: a wrapper that marks the region, a form pointed at your results page, a labelled input, and a submit button.

<search>
  <form action="/search" method="get" role="search">
    <label for="site-search">Search this site</label>
    <input type="search" id="site-search" name="q" enterkeyhint="search">
    <button type="submit">Search</button>
  </form>
</search>

Submitting that form sends the visitor to /search?q=their+words. No JavaScript, no event handlers, no framework. Your server, your static site generator, or a script on the results page reads the query parameter and renders the matches.

The search element is the semantic wrapper for a search region. It was added to the language long after role search became the common workaround, which is why the example carries both: browsers that do not know the element still get the landmark from the role.

The name matters more than it looks. It becomes the key in the query string, and q is the convention almost every search implementation expects. Pick something else and every copied snippet you find later will read the wrong parameter.

Because a search result is a place, not an action. GET puts the query in the URL, and that single fact buys you a lot:

The visitor can bookmark a result page or paste it into a chat.
The back button returns to the results instead of triggering a resubmission warning.
The result page can be cached and, if you want, indexed.
Your logs and analytics show what people searched for, without extra tracking code.

POST throws all of that away and gains nothing, because a search query is not a state change. The trade off between the two methods, and how the destination URL is resolved, is covered in our guide to the HTML form action attribute.

The one rule GET forces on you: everything the user types ends up in a URL that gets logged, shared and stored in browser history. A search box is fine. A field that collects an email address, a message or anything private is not, and that kind of form should post to an endpoint instead.

Which attributes work on a search field in HTML

Because a search field in HTML is a text state input underneath, every text attribute applies. These are the ones worth setting:

Attribute	What it does on a search input
`name`	Becomes the query string key. Use `q` unless you have a reason not to.
`placeholder`	A hint inside the field. It disappears on typing, so it is never a substitute for a label.
`maxlength`, `minlength`	Caps the typed length. Useful when your backend rejects long queries.
`pattern`	A regular expression the value must match before the form submits. Rarely wanted on search.
`required`	Blocks an empty submit. Reasonable here, since an empty query has no results page.
`list`	Points at a datalist of suggested queries the browser shows as you type.
`autocomplete`	Controls whether the browser offers previously submitted queries for this field.
`spellcheck`	Set to `false` to stop red squiggles under product names and code terms.
`enterkeyhint`	Asks the on screen keyboard for a search key explicitly rather than relying on the type alone.
`autofocus`	Focuses on load. Right on a dedicated search page, hostile in a site header.

If you attach a list, read up on how far that control goes before you commit to it: our comparison of datalist and select covers what the browser will and will not render. And since enterkeyhint only matters on touch devices, it belongs with the rest of the choices in mobile form design.

Copy an old search box and you may inherit incremental and results. Both came from WebKit, neither is in the HTML standard, and neither is safe to build on. The same goes for the search event those attributes were paired with. If you want live filtering as the user types, listen for input and debounce it yourself.

Do you need a search button in HTML?

Add one. A form containing a single text field submits when the user presses Enter even without a submit button, but that is the only path in, and it is invisible to anyone using a touch screen.

If you want the button to be an icon only, give it an accessible name, otherwise a screen reader announces an unlabelled button:

<button type="submit" aria-label="Search">
  <svg aria-hidden="true" ...></svg>
</button>

How to style a search bar in HTML

A search bar in HTML is styled like any input, with two browser quirks to neutralise first. Safari has historically applied its own rounded appearance to this type, and both WebKit and Chromium add the clear control inside the box.

input[type="search"] {
  -webkit-appearance: none;
  appearance: none;
  width: 100%;
  padding: 10px 14px;
  border: 1px solid #ccc;
  border-radius: 8px;
  font-size: 16px;
}

That font-size: 16px is not a style choice. Mobile Safari zooms the page when a focused input uses a smaller font, and a header search box that jerks the layout on tap feels broken.

For the magnifier icon, wrap the field in a container and position the icon there. Do not build the box out of a div and drop the real input inside with no border, and never replace the focus outline with nothing.

Keep a visible focus state. Removing the outline without replacing it leaves keyboard users unable to see where they are. Restyle it if the default clashes, but always leave something behind.

How to hide the clear button

The clear control is reachable through a vendor pseudo element in WebKit and Chromium browsers. Firefox has nothing to target because it draws nothing:

input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: none;
  appearance: none;
}

Think twice before you use it. The clear button is one of the few concrete benefits this input type hands you for free, and emptying a search field by hand is a small annoyance on a phone.

Is an HTML search input accessible by default?

Partly. The type gives you the searchbox role at no cost, which is more than a text input offers. Everything else is still your job.

The field needs a real label. A placeholder is not a label: it vanishes the moment someone types, it is not reliably announced, and it fails anyone who needs to re read the field later. If the design has no room for visible label text, hide it visually and leave it in the accessibility tree:

<label class="visually-hidden" for="site-search">Search this site</label>
<input type="search" id="site-search" name="q">

The other half is the landmark. Marking the form as a search region, through the search element or the ARIA search role, lets screen reader users jump straight to it instead of tabbing through your navigation. Then make sure the results page announces how many matches came back, rather than silently swapping the content. The wider set of rules is in our guide to accessible form design.

When input type search is the wrong choice

The type carries a meaning, so it is wrong whenever the field is not a query:

It is a filter that never submits. A field that narrows a list already on the page is still a search field, but it should not sit in a form that navigates away. Give it no submit path, or handle the submit event yourself.
It is a combobox you control. If you are building a custom suggestion list with your own roles and keyboard handling, the default searchbox semantics can fight your pattern. Pick one model and follow it completely.
It is really a message, an email or a name. Those belong to their own input types and post to a real endpoint. Announcing them as a search box to assistive technology is simply wrong.

The other honest limit: a search box only helps people who find what you already published. The visitors worth hearing from are the ones whose search came back empty, and the only way to hear them is to put a form on that page.

Frequently asked questions

What is the difference between input type search and input type text?

The value behaves identically, since both are single line text fields. What differs is meaning and presentation: a search input is exposed to assistive technology as a searchbox, soft keyboards tend to show a search key for it, and Chromium and Safari draw a clear button inside the field once it holds text.

Does input type search actually search anything?

No. There is no search engine built into the browser for it. The input only collects text. What performs the search is the form wrapped around it, submitting to a results URL, and whatever reads that query on the other side, whether that is your server, your site generator or a script on the page.

Should a search form use GET or POST?

GET, in almost every case. It puts the query in the URL, so results can be bookmarked, shared, cached and reached again with the back button, and your logs show what people looked for. POST hides the query and gains nothing, because running a search does not change anything on the server.

How do I remove the clear button from a search input?

Target the vendor pseudo element and reset its appearance: the rule applies in WebKit and Chromium browsers, and Firefox needs nothing because it does not render the control at all. Before you do, remember that clearing a long query by hand on a phone is exactly the friction that button removes.

Do I still need a label if the search box has a placeholder?

Yes. A placeholder disappears as soon as someone types, is not a reliable accessible name, and cannot be re read when the user is halfway through a query. Use a label element tied to the input by id, and hide it visually with CSS if the design has no room for the text.