Design a tag (multi-select) input

Requirements: what to ask before drawing anything

A tag input is a text box that collects many values. Each value you commit turns into a small pill called a chip (or a tag, or a token), sitting in the same box as the text you're typing. You've used it when adding topics to a GitHub repository, recipients in the Gmail To field, labels on a Jira issue, or tags on a Stack Overflow question.

It looks like one widget, but it is really three ideas in one box: a list of chosen values, a text box for the next value, and often a popup of suggestions. Interviewers like it because it's small enough to finish in 45 minutes yet touches data rules, a big keyboard model, accessibility, async loading, layout, and forms.

The first question decides almost everything: where do the values come from? There are three families.

• Free-form tags: the user can type anything, and each committed string becomes a tag. Repository topics and blog post tags work like this. The danger is mess: "React", "react " and "reactjs" all end up as different tags.
• Choose from a list: values must already exist. Assigning people, picking Jira components, or choosing countries. Typing only filters the list. This is a multi-select combobox.
• Both, with rules: pick from a list or create a new value, sometimes only if it passes validation. Email recipients are the classic case: pick a contact, or type any address that looks valid.

Then ask the questions below. Each answer changes the design. The middle column is what this guide assumes.

Functional requirements

• Show committed values as chips inside the field, each with a remove button, followed by a text input.
• Commit the typed text with Enter, comma, or Tab (configurable), and split pasted text into many tags.
• Remove tags with the chip's button, or with Backspace from an empty input.
• Suggest matching options while typing, from a static list or an async search, hiding values already chosen.
• Offer "Create 'foo'" when creating is allowed and nothing matches exactly.
• Enforce rules: trimming, case-insensitive duplicates, max length, custom validation, and a max number of tags.
• Edit a committed tag by clicking it or pressing Enter on it (free-form mode only).
• Submit all values in forms and support required, disabled, and error messages.

Non-functional requirements

• Accessible: every action works from the keyboard, and screen reader users hear what each key did: "React added", "React removed", "3 tags selected".
• Responsive to typing: each key press updates the input and the local filter within one frame (about 16 ms), even with 200 local options.
• Fast suggestions: server results appear within about half a second of the last key press (a 200 ms pause plus the request), and an old, slow response never overwrites a newer one.
• Small: the core under about 5 KB compressed. The virtualized list and the mobile sheet load only when needed.
• Safe: tag text is always rendered as text, never as HTML, because tags come from users.

Out of scope, and why

• Search ranking and the search API itself: the backend owns ranking. We only call it well.
• Rich mentions inside a text editor ("@Ana" in a comment): that's a rich text editor problem, where tags sit inside paragraphs.
• A single-value select: covered in the dropdown select guide. We reuse its listbox ideas.
• Managing the tag catalog (renaming a label for everyone, merging duplicates): an admin feature, not part of the input.

What makes a tag input hard

A first attempt usually looks like this: an array in useState, an input, and an onKeyDown that pushes the text into the array on Enter. It demos well. Then real people use it, and five things go wrong. Each later chapter answers one of them.

1. Many ways in, one set of rules

A value can arrive by typing and pressing Enter, typing a comma, pressing Tab, clicking a suggestion, choosing "Create", pasting a list, or editing an existing chip. If each path checks duplicates its own way, they drift apart. A classic bug: typed tags are trimmed and lowercased before the duplicate check, but pasted tags are not, so pasting "React, react" gives two chips. The fix is one pipeline that every path goes through.

2. The same keys mean different things

Backspace deletes a letter while there's text, and deletes a whole tag when the box is empty. Left arrow moves the caret inside the text, and moves to the chips when the caret is at the start. Enter picks the highlighted suggestion, or creates a tag from the raw text, or submits the form.

Tab moves focus, but some products also commit on Tab. So every key needs a rule that depends on where focus is, where the caret is, and whether the popup is open.

3. Two widgets share one box

The chips are a list of removable items. The text box with its suggestions is a combobox, the pattern from the autocomplete guide. Focus has to move between them in a way that keyboard users can predict and screen readers can follow. Most homemade versions make chips reachable by mouse only.

4. Changes are silent

A sighted user sees a chip appear or vanish. A screen reader user who presses Enter hears nothing at all, unless we say "React added". Same for Backspace removing a tag, a duplicate being ignored, or the limit being reached. Silent rejections are the worst: the user types, presses Enter, the text disappears, and they don't know why.

5. Phones and foreign keyboards break the obvious code

On Android, many virtual keyboards send keydown events with key set to "Unidentified" and keyCode 229 while they compose text, so a handler waiting for event.key === "," may never fire. Chinese, Japanese, and Korean users type through an IME (input method editor), where Enter confirms the chosen characters; if that Enter also commits a tag, they get half a word as a chip. The commit logic must read the text itself, not just the key.

The value model: what a tag is, and when two tags are the same

Before keys and popups, decide what the component holds. Everything else, from duplicate checks to form submission, reads this value. A weak value model leaks bugs into every later chapter.

Normalization: one function decides sameness

Normalization means turning raw text into a standard form before comparing it. Every value goes through the same steps, in this order, whether it was typed, pasted, picked, or edited.

1. Unicode form: text.normalize("NFC"). The letter "é" can be stored as one code point or as "e" plus a combining accent. They look identical but compare as different strings until normalized.
2. Trim and collapse spaces: remove spaces at both ends and turn runs of spaces into one. " web perf " becomes "web perf".
3. Check emptiness and length: drop empty strings silently; refuse anything over the limit (50 characters here) with a message.
4. Mode-specific validation: an email check, a pattern like GitHub topics (lowercase letters, numbers, and hyphens), or the caller's own validate function.
5. Build the comparison key: lowercase for case-insensitive fields. Use toLowerCase(), not toLocaleLowerCase(), for keys, so the key doesn't change with the user's locale (in Turkish, uppercase "I" lowercases to a dotless "ı").
6. Deduplicate and cap: skip the tag if its key is already selected (or appeared earlier in the same paste), and stop once maxTags is reached.

Two finer points about the key. NFC keeps compatibility characters apart: the full-width "ＲＥＡＣＴ" that some East Asian keyboards type is a different string from "REACT". NFKC, a stronger normal form, folds such look-alikes together (it also turns the ligature "fi" into "fi"). So a field can build its key from NFKC text while still showing the user's NFC text as the label.

Lowercasing is also not full case folding: "Straße" lowercases to "straße", which still differs from "strasse". Intl.Collator with sensitivity: "base" treats "a", "A", and "á" as equal, which suits matching suggestions as the user types. But it only compares two strings and produces no key for a Set, and it merges accents, so "resume" and "résumé" would count as one tag. For dedupe, a lowercased NFC or NFKC key is the predictable choice.

Which spelling wins for the label? For an existing option, show the server's spelling: the user typed "javascript", the chip says "JavaScript". For a new tag, keep the user's first spelling, after trimming. If the field forces a format, like GitHub topics which must be lowercase, apply it to the label too, so the chip shows exactly what will be saved.

type Tag = { key: string; label: string; id?: string };
type Rejection = { text: string; reason: string };

function commitMany(raw: string[], selected: Tag[], rules: Rules) {
  const keys = new Set(selected.map((t) => t.key));
  const added: Tag[] = [];
  const rejected: Rejection[] = [];
  for (const text of raw) {
    const label = text.normalize("NFC").trim().replace(/\s+/g, " ");
    if (!label) continue;
    const error = rules.validate(label);
    if (error) { rejected.push({ text: label, reason: error }); continue; }
    const key = rules.caseSensitive ? label : label.toLowerCase();
    if (keys.has(key)) { rejected.push({ text: label, reason: "Already added" }); continue; }
    if (keys.size >= rules.maxTags) { rejected.push({ text: label, reason: `Limit is ${rules.maxTags}` }); continue; }
    keys.add(key);
    added.push({ key, label });
  }
  return { added, rejected };
}

Counting length the way people do

string.length counts UTF-16 code units, not visible characters. A family emoji made of four people joined together is one visible character but 11 code units. If the limit is for humans, count graphemes (what a person sees as one character) with Intl.Segmenter.

If the limit is for the database, count what the server counts. The real rule: use the same counting on both sides, or the client will accept tags the server refuses.

Tags that must exist versus tags you can create

In must-exist mode, typed text only filters. Enter picks the highlighted option; with no highlight, nothing is committed and the text stays. Paste is trickier: "Design, Frontend, Nope" has to be matched against the server. Send all pieces in one request (POST /api/labels/resolve), show the matched ones as chips, and leave "Nope" in the box with "No label named Nope".

In creatable mode, a new tag is only a chip until the form is saved. Don't create it on the server the moment the chip appears. A user who types "recat" by mistake and removes it would otherwise leave a junk tag in the catalog for everyone. The server creates missing tags when the whole form is saved, and runs the same normalization, because a client check can always be skipped.

Input behavior: committing, pasting, deleting, editing

This chapter is about the keys and events that turn text into tags and tags back into nothing. Each rule here is small, but users notice every one of them, because they type into this box many times a day.

Which keys commit a tag

Enter is the obvious commit key. Comma is the second, because people already type lists with commas. Tab is the debated one: committing on Tab saves a key press, but Tab also means "leave this field".

A good default: Tab commits the text if there is any, and focus then moves on normally (we don't call preventDefault). With an empty box, Tab just moves focus.

function onKeyDown(e: React.KeyboardEvent<HTMLInputElement>) {
  if (e.nativeEvent.isComposing) return;
  const caretAtStart = e.currentTarget.selectionStart === 0
    && e.currentTarget.selectionEnd === 0;
  switch (e.key) {
    case "Enter":
      if (e.nativeEvent.keyCode === 229) return; // Safari: the IME's confirming Enter
      if (popup.activeOption) { e.preventDefault(); pick(popup.activeOption); }
      else if (draft.trim()) { e.preventDefault(); commitDraft(); }
      return; // empty draft: let Enter submit the form
    case "Tab":
      if (draft.trim()) commitDraft(); // no preventDefault: focus still moves
      return;
    case "Backspace":
      if (caretAtStart && draft === "") { e.preventDefault(); backspaceOnEmpty(); }
      return;
    case "ArrowLeft":
      if (caretAtStart && tags.length) { e.preventDefault(); focusChip(tags.length - 1); }
      return;
    case "Escape":
      if (popup.open) { e.preventDefault(); popup.close(); }
      return;
  }
}

function onInput(e: React.ChangeEvent<HTMLInputElement>) {
  const parts = e.target.value.split(/[,;]/);
  const rest = parts.pop() ?? "";
  if (parts.length) commitMany(parts);
  setDraft(rest);
}

Note the empty-draft Enter. If the box is empty and no option is highlighted, let Enter do what it does in any form: submit. Swallowing it makes the user hunt for the submit button.

Paste: a list in, many tags out

Listen for the paste event, read event.clipboardData.getData("text/plain"), and call preventDefault so the raw text never lands in the box. Split on commas, semicolons, newlines, and tabs (spreadsheet cells copy as tab-separated text). Insert the pasted text at the caret if the user had a partial draft, then split the combined result.

Some items will fail. The rule that matters most: never throw away what the user pasted. Turn the good items into chips, and put the items that need fixing (invalid, or over the limit) back into the text box, joined with ", ". Duplicates need no fixing, so they are only reported.

Then show one message: "2 of 30 not added: bob.acme.com (not a valid email), carol@acme.com (already added)". The user fixes the text left in the box and presses Enter. Compare that with dropping the failures silently: the user has to diff two lists by eye to find what's missing.

Keep the email check loose. A practical rule is the one browsers use for input type="email": some characters, an @, and a domain made of letters, digits, hyphens, and dots. The HTML standard openly calls this rule a "willful violation" of RFC 5322, the email format standard, because the full format is impractical for forms. Don't demand a known domain ending or refuse plus signs: only the mail server knows whether an address exists, so the check is there to catch typos, not to prove anything.

The browser's own type="email" multiple field is no shortcut here. It splits only on commas, trims spaces around each address, and has no room for display names, so a pasted list with semicolons or quoted names fails as a whole.

Backspace on an empty box

When the box is empty and the caret is at the start, Backspace has nothing to delete in the text, so it reaches for the last tag. Libraries disagree on what happens next. React Select removes the last value at once (its backspaceRemovesValue prop is on by default), and so does MUI's Autocomplete in multiple mode.

Other products, often email recipient fields, first highlight the chip and remove it on the second press. Before you quote any product in an interview, try it yourself: their behavior changes between releases.

Editing a chip

In free-form mode, clicking a chip's label (or pressing Enter on a focused chip) turns it back into text. The simplest version removes the chip and puts its label into the draft with the caret at the end. A nicer version swaps the chip for a small inline input in the same spot, so order is kept.

Either way the edited text goes back through the pipeline, with its own old key removed from the duplicate set first, so editing "React" to "react" isn't refused as a duplicate of itself. Escape cancels and restores the original. In must-exist mode, chips aren't editable: a click on the label does nothing, and the remove button is the only action.

When the limit is reached

Don't disable the text box at the limit. A disabled input can't take focus, so keyboard users can't reach Backspace or the chips through it, and screen readers may skip it. Keep it enabled, close the suggestions and stop opening them, and change the placeholder to "Limit reached".

If the user tries to commit anyway, keep their text and say "You can add up to 5 tags. Remove one to add another." A counter like "5 of 5" linked with aria-describedby tells screen reader users the limit before they hit it.

Suggestions: searching, excluding, creating

Suggestions turn the tag input into a combobox: a text box that controls a popup list. The autocomplete guide already covers the search machinery in depth (debouncing, cancelling stale requests, caching). Here we only cover what changes when the box collects many values.

Hiding what's already chosen

Showing "React" in the suggestions when it's already a chip invites a duplicate. Filter results by the selected keys before rendering. One trap: if the server returns 8 results and 3 are already chosen, the list shows only 5. Ask for limit + selectedCount (capped, say at 20), then trim to 8 after filtering.

Some designs keep chosen options in the list with a check mark, and picking one again removes it. MUI's Autocomplete keeps chosen options in the list by default in multiple mode, and its filterSelectedOptions prop hides them instead. It suits short fixed lists like "Status", where the list is the main UI. For long searched lists, hiding chosen values keeps the list focused on what you can still add.

The "Create" option

When creating is allowed, add a row "Create 'web perf'" at the end of the list. Show it only when the draft passes validation and no option has the same key: if the user typed "javascript" and "JavaScript" exists, there's nothing to create. The row's label should show the normalized text, so the user sees exactly what will be saved.

What does Enter do with no highlighted row? In must-exist mode, highlight the first match as the user types, so Enter picks it. In creatable mode, don't auto-highlight: Enter commits what was typed, and the pipeline still swaps an exact match for the existing option, with its id and its spelling. Otherwise a user who types "react" and presses Enter would get "react-native", just because it ranked first.

Highlighting the match

Bold the part of each option that matches the query, like "React". Split the label into pieces in JavaScript and render the matched piece in a mark element. Never build an HTML string and inject it: tag labels come from users, and a label like img src=x onerror=... in angle brackets is a script waiting to run. Match on the normalized text but slice the original label, so accents and case display as stored.

Grouping

A people picker often groups rows: "Recent", "Teams", "People". Wrap each group in an element with role="group" and aria-labelledby pointing at its heading, inside the listbox. Keep the headings out of the arrow-key order: arrows move through options only. Keep groups to 3 or 4 and each one short, or the list stops being scannable.

Keyboard model and screen reader feedback

A tag input has three places the keyboard can be: the chips, the text box, and the suggestions. The text box is the home base, and the suggestions follow the WAI-ARIA Authoring Practices (APG) combobox pattern with a listbox popup. The chips have no official APG pattern, so we borrow from the ones that exist: a list, buttons, and a roving focus. The focus-management and keyboard-navigation lessons cover the general techniques.

The text box and its suggestions

• The input has role="combobox", aria-expanded (true when the popup shows), aria-controls pointing at the listbox, and aria-autocomplete="list".
• Focus stays in the input the whole time. The highlighted option is pointed to with aria-activedescendant, so the user can keep typing while arrowing, the same technique the command palette guide uses.
• Down and Up move the highlight, opening the popup if needed. Enter picks. Escape closes the popup; a second Escape clears the draft. Home and End move the caret in the text, as they do in any text box.
• Each option has role="option" and an id built from its key, like tags-opt-react, so the id survives re-renders and new results. Escape spaces and symbols in the key first, since an id can't contain spaces.

Moving through the chips

Libraries expose the chip group in different ways, which shows the question isn't settled. React Aria's TagGroup renders a grid with one row per tag, Downshift's useTagGroup marks the group as a listbox, and many hand-built inputs use a plain list of buttons like ours. Screen readers announce each one differently (a row, an option, a button), and support varies by screen reader. Pick one structure, use it across the design system, and test it with real screen readers.

In right-to-left languages like Arabic and Hebrew, the start of the text is on the right. The arrow that leaves the text toward the chips is Right, not Left. Read the direction from the element (getComputedStyle(input).direction) and swap the arrow meanings, or users will move the wrong way.

What a screen reader should hear

Chips appearing and vanishing are visual events. Make them spoken with a live region: a visually hidden element with role="status", which screen readers read politely after the current speech. Render it once when the component mounts and only change its text later; a live region added to the page at the same moment as its message is often not announced.

Also give the structure meaning. The chips sit in a ul labelled "Selected tags", so screen readers announce "list, 3 items" when entering it. The input has a visible label and aria-describedby pointing at the hint ("Press comma or Enter to add. Up to 5."), the counter, and any error.

Expect differences: NVDA, JAWS, VoiceOver, and TalkBack don't read descriptions, lists, and live regions the same way, and some versions read a description only on first focus. Test with at least two screen reader and browser pairs, and treat the plan above as a starting point, not a guarantee.

Layout: wrapping, growing, overflowing, and phones

The field looks like one text box, but it is a flex container holding chips and an input. The outer box draws the border and focus ring, so clicking anywhere in it (between chips, in the empty space) focuses the input. Use :focus-within on the box to draw the focus ring, since the input itself has no visible border.

Wrapping chips and a growing input

Give the box display: flex and flex-wrap: wrap with a small gap. Chips keep their natural width up to a maximum (say 240 px), and long labels are cut with an ellipsis, with the full text in the remove button's name so nothing is lost for screen readers.

The input gets flex: 1 1 6rem: it takes whatever space is left on the last line, and when less than about 6 rem is left, it wraps to its own line. That beats sizing the input to its text, which leaves a tiny box at the end of a line that's hard to click.

CSS field-sizing: content can also size an input to its text, but while Chrome has had it since version 123, it reached Safari only in December 2025 (26.2) and Firefox in mid-2026 (152), so check your browser targets before relying on it.

To count how many chips fit, render them all in the row once, read each chip's width, and add them up until the next one plus the "+N more" button would pass the box width. A ResizeObserver on the box reruns the count when the layout changes, such as on a window resize or a sidebar collapse. Hidden chips stay in the DOM but get the hidden attribute, so state and ids don't churn.

On phones

On a phone, the virtual keyboard takes about half the screen, so a popup of suggestions under a field near the bottom has almost no room. For must-exist pickers with long lists, like assigning people, open a bottom sheet on tap: a panel that slides up from the bottom, with its own search box at the top, the results below, and the selected chips in a row at the top.

The sheet is a modal dialog, so it traps focus and returns focus to the field on close (see the modal dialog guide). Free-form tag fields usually stay inline: there is little to pick, and a sheet just adds a step.

• enterkeyhint="enter" keeps the Enter key from showing "Go", which suggests submitting the form.
• autocapitalize="none" and spellcheck="false" stop the keyboard from capitalizing "react" and underlining every tag.
• For recipients, inputmode="email" shows the @ key. Keep type="text": type="email" adds browser validation that fights our own and can't hold a half-typed draft cleanly.
• Make the remove target at least 24 by 24 CSS pixels (WCAG 2.2's minimum target size), even if the drawn "x" is smaller.

Architecture, data flow, and state

Now put the pieces together. The main idea: one controller owns every rule, and the views only render and report. This is what keeps typed, pasted, picked, and edited tags consistent: they all reach the same commitMany.

Follow one key press through the data flow. The user types "v", TagField reports the new draft, and the controller stores it and asks the suggestion source for "v". The source checks its cache, waits for the pause, then fetches with an AbortSignal. When results return, the controller drops the selected keys and the listbox renders.

Then the user presses Enter. The controller runs the pipeline, calls onChange with the new array, and sends "Vue added. 3 tags." to the announcer, and the form bridge writes a new hidden input. The server only sees the tags when the form is saved.

Where each piece of state lives

type Tag = { key: string; label: string; id?: string; meta?: unknown };

// Owned by the form (controlled) or the controller (uncontrolled)
type TagValue = readonly Tag[];

// Owned by the controller, reset on blur
type TagInputState = {
  draft: string;
  focus: { kind: "input" } | { kind: "chip"; index: number };
  armedKey: string | null;        // two-step Backspace
  editingKey: string | null;      // chip being edited inline
  popup: { open: boolean; activeKey: string | null };
  rejected: { text: string; reason: string }[];
};

// Shared by every field on the page, keyed by source + query
type SuggestionCache = Map<string, { tags: Tag[]; at: number }>;

Why keep armedKey and editingKey as keys, not indexes? Because the array changes under them. If a paste adds tags while a chip is armed, an index would now point at a different chip, and the next Backspace would remove the wrong one. Keys stay attached to the right tag.

Component API and form integration

Three teams will use this: issue labels, a people picker, and email recipients. The API has to serve all three without three components, and without a prop for every whim. The component-api-design lesson covers the general rules; here's how they apply.

type TagInputProps = {
  label: string;
  name?: string;                     // form field name
  value?: readonly Tag[];            // controlled
  defaultValue?: readonly Tag[];     // uncontrolled
  onChange?: (tags: Tag[], change: TagChange) => void;
  options?: readonly Tag[];          // local suggestions
  loadOptions?: (q: string, opts: { signal: AbortSignal }) => Promise<Tag[]>;
  creatable?: boolean | ((label: string) => boolean);
  validate?: (label: string) => string | null; // error or null
  maxTags?: number;
  maxLength?: number;                // default 50
  caseSensitive?: boolean;           // default false
  separators?: readonly string[];    // default [",", ";", "\n", "\t"]
  commitOnTab?: boolean;             // default true
  backspaceBehavior?: "arm" | "remove"; // default "arm"
  required?: boolean;
  disabled?: boolean;
  renderTag?: (tag: Tag, state: { armed: boolean }) => React.ReactNode;
};

type TagChange =
  | { type: "add"; tags: Tag[]; source: "type" | "paste" | "pick" | "create" }
  | { type: "remove"; tag: Tag; source: "button" | "backspace" | "delete" }
  | { type: "edit"; from: Tag; to: Tag };

• renderTag lets the people picker show an avatar, but the component still wraps the result with the roles, the remove button, and the keyboard handling. Callers style chips; they can't break them.
• validate returns a message, not a boolean, because every refusal needs words the user can act on.
• creatable can be a function, so recipients can say "create if it looks like an email".
• Controlled and uncontrolled work like a native input: pass value to own the state, or defaultValue to let the component own it. Switching between them during the component's life logs a warning, as React does for inputs.

Getting many values into a form

A plain HTML form only submits form controls. Chips are li elements, so they submit nothing. There are two standard fixes.

• Hidden inputs: render one input type="hidden" per tag, all with the same name. On the server or in JavaScript, new FormData(form).getAll("labels") returns every value, in order. This works everywhere and needs no JavaScript at submit time. Two traps: Object.fromEntries(formData), a common shortcut in form actions, keeps only the last value for a repeated name, so read tag fields with getAll. And when the form resets (React 19 calls form.reset() after a successful form action), an uncontrolled tag input must listen for the form's reset event and go back to its defaultValue.
• A form-associated custom element: if the design system ships web components, the element calls attachInternals() and then internals.setFormValue(formData), where formData holds many entries under the field's name. It also gets formResetCallback for the form's reset button.

Submit the id for existing options and the label for new ones, or post both: labels=t_12&labels=t_91&newLabels=web+perf (a form encodes the space as +). The server must not trust either: it checks that each id exists and that the user may use it, and runs the same normalization on new labels.

Required with zero tags, and error messages

The browser's built-in form checks (constraint validation) skip hidden inputs, so required on them does nothing and an empty submit goes through. The required attribute on the text box is wrong too: it would demand typed text even when tags exist.

Put the rule on the visible text box instead: when the component's required prop is set and there are no tags, call input.setCustomValidity("Add at least one label"), and clear it with an empty string once a tag exists. Now native validation blocks the submit, focuses the field, and shows the message, and form libraries that read validity see it too.

Show the same text below the field, linked with aria-describedby, and set aria-invalid="true" while it applies. The input-validation and form-state lessons cover when to show errors (on submit and on blur, not on the first key press).

Performance, reordering, languages, and safety

Thousands of options

A local list of 200 labels renders fine. A must-exist list of 5,000 product codes doesn't: rendering 5,000 option rows on open can take a few hundred milliseconds on a mid-range phone, and every highlight change re-renders the lot if you're careless. Two fixes, in order of value.

1. Show fewer rows. In a long list, people usually type more letters rather than scroll far. Cap a searched list at about 50 rows with a "Keep typing to narrow 4,950 more" note. This solves most cases without any virtualization.
2. Virtualize when the full list must be scrollable. Render only the rows in view plus a small buffer, as in the virtualized-list guide. Two combobox details matter: the option named by aria-activedescendant must exist in the DOM, so scroll it into the rendered window before pointing at it; and give each rendered option aria-setsize and aria-posinset so screen readers can say "12 of 5,000".

Filtering itself is cheap. Lowercasing and testing 5,000 short strings on each key press takes about a millisecond on a laptop. Precompute each option's normalized key once, not on every key press, and keep the draft update separate from the filter (React's useDeferredValue lets the text box stay responsive while the list catches up).

With 50 recipient chips, the risk is re-rendering all 50 on every key press in the draft. Keep the draft state out of the chip list's props, and memoize each chip on its key and armed state, so typing touches only the input.

Reordering chips (optional)

Most tags have no meaningful order, so skip reordering unless order means something, like priority in a list of reviewers. If you add drag and drop, the kanban-board guide's rule applies: every drag needs a keyboard and screen reader alternative.

On a focused chip, Alt plus Left or Right (or "Move left" and "Move right" in a chip menu) moves it one place and announces "React moved to position 2 of 4". Dragging with a mouse should start only after the pointer moves a few pixels, so a click on the chip still means edit.

Languages and separators

• Arabic uses its own comma (U+060C), and Chinese and Japanese text often uses a full-width comma (U+FF0C) or the ideographic comma (U+3001). Add them to the default separators for those locales, or a user typing a natural comma never commits.
• Messages like "3 tags" need plural rules: use Intl.PluralRules or the app's i18n library, since some languages have more than two plural forms.
• Right-to-left layouts flip the chip order and the arrow keys, as covered in the keyboard chapter. Use logical CSS like margin-inline-start so chip spacing flips too.

Safety

• Render every label as text. React escapes text by default; the danger is reaching for dangerouslySetInnerHTML to highlight matches. Build the highlight from split strings instead.
• Treat tag text as untrusted on the server: same normalization, same length limits, and a cap on tags per request, because the client's maxTags is a convenience, not a guard.
• Rate limit the suggestion endpoint and require a minimum query length of 1 or 2 characters for the people directory, so a script can't page through all 40,000 employees.

Running it in the interview

Forty-five minutes is enough for this problem only if you skip what doesn't matter. Here is a plan that fits.

Draw the wireframe first, not boxes and arrows. For a component question, the interviewer wants to see you think about the person typing. Name the parts on the wireframe, then use those names for the rest of the hour.