How to Design a Website Search Bar: Placement, Size, and Autocomplete UX

Most articles about search bar design give you a gallery of pretty screenshots. That is fine for mood boards, but it will not tell you how wide the input should be, what the placeholder should say, or what to show when a shopper types “blu jumpr” and gets nothing back.

This guide is the opposite. It is a build-ready walkthrough of site search UX: placement, size, placeholder copy, autocomplete behaviour and zero-result states, plus accessible HTML and CSS you can paste into your project today.

The short answer: what a good search bar looks like

If you only remember five things about search bar design, remember these:

1. Always show the input on desktop. A magnifier icon that expands on click hides your most valuable feature.
2. Make it wide enough for real queries. Roughly 27 to 30 visible characters is the sweet spot.
3. Put it in the header, top right or centre, on every page, in the same position.
4. Give it a real label (visible or visually hidden) and a focus ring that passes contrast checks.
5. Never return a dead end. A zero-result page must offer spelling help, alternatives and a route back to browsing.

Where to place the search bar on desktop

Users scan the top of a page in an F shape, and they have been trained by two decades of e-commerce to look in one of two places: the top right corner of the header, or the horizontal centre of the header.

Header top right

The safest default for content sites, SaaS marketing sites, blogs and small catalogues. It sits near the account and cart icons and does not compete with the logo or main navigation.

Header centre, full width

The right call when search is the product: marketplaces, large e-commerce catalogues, documentation portals, media libraries. A centred bar of 400 to 600 pixels signals “start here”.

Hero search

A large search field inside the hero section works for travel, real estate, job boards and directories, where the first action is always a query. Keep a smaller version in the sticky header so users can search again after they scroll.

Sidebar or footer only

Avoid it. Search hidden in a sidebar or footer gets a fraction of the usage of header search, and mobile users will almost never find it. Related reading: 10+ Best Examples of Search Bar Designs.

Site type	Recommended placement	Input state
Large e-commerce catalogue	Centred in header, full width	Always expanded
Small shop (under 100 products)	Top right of header	Always expanded
Blog or content hub	Top right, plus in-page search on archive pages	Expanded or icon that opens a modal
SaaS app dashboard	Top bar, left aligned near the logo	Expanded with keyboard shortcut hint
Directory, jobs, travel	Hero search plus sticky header search	Expanded, multi-field
Documentation	Top of the sidebar or centred header	Expanded, with slash shortcut

Where to place the search bar on mobile

Mobile is where most search bar design goes wrong. Screen space is tight, so teams bury search inside the hamburger menu. That is the single most expensive mistake in mobile site search, because a query typed on a phone is usually a high-intent query.

In order of preference:

• A persistent search field under the header. Best for e-commerce. Costs about 48 pixels of vertical space and pays for itself.
• A visible magnifier icon in the header that opens a full-screen search overlay with the keyboard focused automatically. Good compromise for content sites.
• Search inside the hamburger menu, as the first item. Acceptable only if search is a minor feature.
• Search icon in a bottom tab bar for app-like progressive web apps, where the thumb zone matters more than the header.

Mobile rules that are easy to forget

• Tap target of at least 44 x 44 CSS pixels for the icon and the submit button.
• Font size of 16px minimum on the input, otherwise iOS zooms the page on focus.
• Auto-focus the field when the overlay opens, and show the keyboard immediately.
• Set enterkeyhint="search" so the virtual keyboard shows a Search key instead of Return.
• Disable autocorrect and autocapitalize for product codes and names.

How wide should a search input be?

Width is a usability decision, not a decorative one. If users cannot see their whole query, they cannot check it before submitting, and they abandon or make errors.

The practical target: the input should display around 27 to 30 characters without truncation. That covers the vast majority of real queries.

Context	Recommended width	Height
Desktop header, content site	280px to 360px	40px to 44px
Desktop header, e-commerce	400px to 600px	44px to 52px
Hero search	560px to 720px	52px to 64px
Mobile persistent bar	100% minus 32px of padding	44px to 48px

Use a fluid width with sensible limits rather than a fixed pixel value:

.search-field {
  width: 100%;
  min-width: 16rem;   /* keeps ~27 characters visible */
  max-width: 38rem;   /* stops it swallowing the header */
}

Placeholder copy: small text, big impact

A placeholder is not a label. It disappears the moment someone types, so it must never carry essential instructions. What it should do is set expectations about what is searchable.

Weak placeholder	Better placeholder	Why
Search	Search 4,200 products	Communicates scope and depth
Type here…	Search by name, SKU or brand	Tells users which query types work
Enter keyword	Try “winter tyres 205/55 R16”	Models a good query
Search the site	Search articles, guides and docs	Clarifies the content types indexed

Rules: keep it under 40 characters so it does not truncate on mobile, use sentence case, and make sure the placeholder colour still reaches a 4.5:1 contrast ratio against the field background. Grey on grey placeholders are one of the most common accessibility failures in search bar design.

Icon, button, or both?

Three patterns work, and they are not interchangeable:

• Magnifier icon inside the field on the left. Clean and universally understood, but it is decorative, not clickable. Use when the primary submit action is the Enter key.
• Icon button on the right, inside the field. Best all-round choice. Give it an accessible name such as “Submit search”.
• Labelled button with the word Search. Highest click-through rate on e-commerce, especially with older audiences. Use a solid, high-contrast fill.

Add a clear (x) button that appears once the field has content. It saves users from long-pressing backspace on mobile and it is essential in faceted search interfaces. There is a detailed walkthrough elsewhere.

Autocomplete UX: rules that actually improve conversion

Autocomplete, sometimes called autosuggest or type-ahead, is where a search bar stops being an input and starts being a navigation system. Get these details right.

1. Trigger after two characters, not one

Suggestions on the first keystroke are noise. Wait for 2 to 3 characters and debounce requests by 150 to 250 milliseconds so you are not firing a query on every keypress.

2. Show between 6 and 10 suggestions

More than ten and the list becomes a scroll trap, especially on mobile where the dropdown competes with the keyboard. On phones, five to six suggestions above the keyboard is the practical limit.

3. Mix suggestion types, but group them

A strong autocomplete panel for an e-commerce site contains:

• Query suggestions (completions of what the user is typing)
• Product results with thumbnail, name and price
• Category and brand shortcuts such as “Running shoes in Men”
• Content results like guides or help articles, kept in a separate group

Label each group with a small heading. Never blend a category link and a product into the same visual row.

4. Highlight the difference, not the match

When a user types “run”, bold the completion (running shoes vs running shoes). Bolding the unmatched part makes the new information scannable. Pick one convention and apply it everywhere.

5. Support full keyboard control

• Arrow down and arrow up move through suggestions
• Enter selects the highlighted suggestion, or submits the raw query if none is highlighted
• Escape closes the panel and keeps the typed text
• Tab moves focus onward without silently swallowing the query

6. Do not overwrite what the user typed

Inline auto-completion that rewrites the field mid-typing causes errors. Highlight the suggestion in the list instead, and only fill the input when the user explicitly moves to it with the arrow keys.

7. Show recent and popular searches on focus

An empty state for the dropdown is free real estate. On focus, before any typing, display the user’s last three to five searches plus three or four popular or trending queries. This alone lifts search usage on repeat-visit sites.

8. Announce results to screen readers

Use the combobox pattern with aria-expanded, aria-controls, aria-activedescendant and a polite live region that reports how many suggestions are available.

Zero results: turn a dead end into a detour

A blank “No results found” page is the most damaging screen in the whole search experience. Design it as a real page, with a hierarchy.

1. Confirm the query in plain language: We could not find anything for “blu jumpr”.
2. Offer a spelling correction with a one-click link: Did you mean blue jumper? Better still, auto-correct and show results with an “showing results for X, search instead for Y” note.
3. Explain how to broaden the query: remove filters, use fewer words, try a brand or category name.
4. Show fallback content: best sellers, most-read articles, recently viewed items, or the closest partial matches.
5. Keep the search field visible and pre-filled so the user can edit rather than retype.
6. Give an escape route: category links, a contact link, or a “request this product” form.

Also handle the near-zero state, where you return one or two weak results. In that case, show the matches and then a clearly separated “You may also like” block, so the page does not look broken.

Instrument it

Log every zero-result query. That list is a free product and content roadmap. Review it monthly and fix the top twenty with synonyms, redirects or new content.

Accessible search input: HTML and CSS you can copy

Here is a complete, accessible search component with a visible label, a clear focus state, an icon, and a clear button. It uses no framework.

The markup

<form class="site-search" role="search" action="/search" method="get">
  <label class="site-search__label" for="site-search-input">
    Search the site
  </label>

  <div class="site-search__field">
    <svg class="site-search__icon" aria-hidden="true" focusable="false" viewBox="0 0 24 24">
      <path d="M10 2a8 8 0 105.29 14.03l4.84 4.84 1.41-1.41-4.84-4.84A8 8 0 0010 2zm0 2a6 6 0 110 12 6 6 0 010-12z"/>
    </svg>

    <input
      id="site-search-input"
      class="site-search__input"
      type="search"
      name="q"
      placeholder="Search guides, docs and products"
      autocomplete="off"
      autocapitalize="none"
      spellcheck="false"
      enterkeyhint="search"
      aria-describedby="site-search-hint">

    <button class="site-search__submit" type="submit">Search</button>
  </div>

  <p id="site-search-hint" class="site-search__hint">
    Try a product name, SKU or brand.
  </p>
</form>

The CSS

.site-search {
  --search-border: #c9ced6;
  --search-focus: #1b6ef3;
  --search-text: #1a1d21;
  --search-radius: 8px;

  width: 100%;
  max-width: 38rem;
  font-family: system-ui, sans-serif;
}

.site-search__label {
  display: block;
  margin-bottom: 6px;
  font-size: 0.875rem;
  font-weight: 600;
  color: var(--search-text);
}

.site-search__field {
  display: flex;
  align-items: center;
  gap: 8px;
  padding: 0 4px 0 12px;
  background: #fff;
  border: 1px solid var(--search-border);
  border-radius: var(--search-radius);
  transition: border-color 120ms ease, box-shadow 120ms ease;
}

/* Focus ring on the wrapper, driven by the real input */
.site-search__field:focus-within {
  border-color: var(--search-focus);
  box-shadow: 0 0 0 3px rgba(27, 110, 243, 0.35);
}

.site-search__icon {
  flex: 0 0 auto;
  width: 20px;
  height: 20px;
  fill: #6b7280;
}

.site-search__input {
  flex: 1 1 auto;
  min-width: 0;
  height: 44px;
  padding: 0;
  border: 0;
  background: transparent;
  font-size: 1rem; /* 16px stops iOS zoom */
  color: var(--search-text);
}

.site-search__input::placeholder {
  color: #5f6b7a; /* passes 4.5:1 on white */
}

.site-search__input:focus {
  outline: none; /* the wrapper shows the ring */
}

/* Native clear button in WebKit */
.site-search__input::-webkit-search-cancel-button {
  cursor: pointer;
}

.site-search__submit {
  flex: 0 0 auto;
  min-height: 36px;
  padding: 0 16px;
  margin: 4px;
  border: 0;
  border-radius: 6px;
  background: var(--search-focus);
  color: #fff;
  font-size: 0.9375rem;
  font-weight: 600;
  cursor: pointer;
}

.site-search__submit:focus-visible {
  outline: 3px solid #0b1f45;
  outline-offset: 2px;
}

.site-search__hint {
  margin: 6px 0 0;
  font-size: 0.8125rem;
  color: #5f6b7a;
}

@media (prefers-reduced-motion: reduce) {
  .site-search__field { transition: none; }
}

@media (prefers-color-scheme: dark) {
  .site-search__field { background: #14181d; border-color: #39424e; }
  .site-search__input { color: #f2f4f7; }
  .site-search__label { color: #f2f4f7; }
}

If you must hide the label visually

A visible label is best. When your header layout cannot fit one, hide it accessibly rather than deleting it. Never use display:none, which removes it from the accessibility tree.

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

Autocomplete panel styling

.site-search__results {
  position: absolute;
  z-index: 50;
  width: 100%;
  margin-top: 4px;
  padding: 6px;
  background: #fff;
  border: 1px solid var(--search-border);
  border-radius: var(--search-radius);
  box-shadow: 0 12px 28px rgba(16, 24, 40, 0.14);
  list-style: none;
  max-height: 60vh;
  overflow-y: auto;
}

.site-search__group-title {
  padding: 8px 10px 4px;
  font-size: 0.75rem;
  text-transform: uppercase;
  letter-spacing: 0.04em;
  color: #6b7280;
}

.site-search__option {
  display: flex;
  align-items: center;
  gap: 10px;
  padding: 10px;
  border-radius: 6px;
  cursor: pointer;
}

.site-search__option[aria-selected="true"],
.site-search__option:hover {
  background: #eef4ff;
}

.site-search__option mark {
  background: transparent;
  font-weight: 700;
  color: inherit;
}

Performance targets worth holding yourself to

• Autocomplete response under 150ms perceived, 300ms absolute ceiling
• Results page render under 1 second on a mid-range phone
• Debounce of 200ms on keystrokes, with in-flight requests cancelled
• Reserve the dropdown space so opening it does not shift layout and hurt your CLS score

Search bar design checklist

Area	Check
Placement	Same position on every page, visible without scrolling
Size	27+ characters visible, 44px minimum height
Labelling	Real label element, placeholder used only as a hint
Focus	Visible ring with at least 3:1 contrast against the background
Semantics	form role=”search”, input type=”search”, name=”q”
Autocomplete	Grouped, keyboard navigable, announced to screen readers
Query handling	Typo tolerance, synonyms, plurals, partial matches
Zero results	Correction, suggestions, fallback content, pre-filled field
Results page	Query echoed, result count, sort and filter controls
Analytics	Track queries, zero results, click position and exit rate

Seven mistakes we still see on live sites

1. Icon-only search on desktop. One extra click before a user can even start typing.
2. Placeholder used as the only label. Fails WCAG and confuses anyone who pauses mid-task.
3. Removing the focus outline with outline: none and replacing it with nothing.
4. Clearing the query on the results page. Users cannot refine what they cannot see.
5. Exact-match-only engines that return zero results for a single typo.
6. Autocomplete that covers the submit button on mobile.
7. No search analytics at all, which means nobody knows what customers are asking for.

FAQ

How do you design a search bar that people actually use?

Keep it permanently visible in the header, make it wide enough to show a full query, use a placeholder that explains what is searchable, add autocomplete after the second character, and make sure the results and zero-result pages give people somewhere to go next.

What is the ideal search bar width?

Aim for roughly 27 to 30 visible characters. In practice that means 280px to 360px on a content site header, 400px to 600px for e-commerce, and full width on mobile. Use min-width and max-width rather than a hard pixel value.

Should the search bar be on the left or the right?

Top right is the conventional position and the safest default. Move it to the centre of the header, or into the hero, only when search is the primary way people use your site.

Is it OK to hide search behind an icon?

On mobile, yes, provided the icon is in the header and opens a full-screen overlay with the field focused. On desktop it costs you usage, so only do it if your search logs show search is a marginal feature.

How many autocomplete suggestions should I show?

Six to ten on desktop, five or six on mobile so the list is not fighting the keyboard. Group them by type and label each group.

What should a no-results page say?

Repeat the query, offer a spelling correction, explain how to broaden the search, show popular or related items, keep the search field pre-filled, and link out to the main categories. Never show a bare “No results” line.

Which HTML input type should I use?

Use type="search" inside a <form role="search">. It gives you the native clear control in WebKit browsers, better mobile keyboard behaviour, and clearer semantics for assistive technology.

Does search bar design affect SEO?

Indirectly, and strongly. Better internal search reduces bounce and increases pages per session, and your query logs reveal exactly what your audience wants next, which is the best possible input for content and product page planning.

Need a hand?

At FatCow Web Design we build site search that is fast, accessible and measured, from the header component down to the zero-result page and the reporting behind it. If your current search bar is buried, slow or returning empty pages, get in touch and we will audit it for you.