Sort controls vs Filter chips vs Filter panel vs Pagination

Prefer sort controls when the user needs the same matching items arranged by relevance, date, name, distance, price, priority, or another meaningful ordering attribute.

Sort controls live example Filter chips live example Filter panel live example Pagination live example

Decision dimensions

Dimension	Sort controls	Filter chips	Filter panel	Pagination
UI or UX	UI + UX - Control for changing the order of an existing result set	UI + UX - Compact chip set for toggling or removing result filters	UI + UX - Grouped filter control panel for narrowing a current result set	UI + UX - Paged navigation control
UI guidance	Place the active sort control above or inside the result region it affects, with a visible label such as Sort by and an option name that includes both the attribute and direction.	Render filter chips as a compact set of short, consistently styled controls near the content they filter, with clear selected, unselected, focused, disabled, and removable states.	Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.	Render a labeled pagination nav near the affected results with current page, previous, next, nearby pages, optional first/last or ellipsis, and clear disabled edge states.
UX guidance	Use sort controls when users need to rearrange the same matching results by a meaningful attribute while preserving the current search query, filters, page size, and view context.	Use filter chips for quick, low-cost filtering when users can understand the available criteria at a glance and combine a few chips without opening a larger panel.	Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.	Help users move through an ordered result set with a stable sense of position, progress, and returnability.
Good UI	A search results page shows Sort by with options like Relevance, Due date (oldest first), and Amount (highest first) above the results.	A search results page shows chips for Open, Urgent, Appeals, and Benefits below the search box, with selected chips using a checkmark and stronger background.	A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.	Current page, previous/next, disabled edges, page numbers, result range, and total count are visually clear.
Bad UI	A menu labelled Sort contains Status: Open, Last 30 days, and Owner, which are filters rather than ordering rules.	A single pill labelled Filter sits alone and behaves like a vague button.	A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.	Tiny numbers with no current state.
Good UX	A user searches for case, changes Sort by from Relevance to Due date (oldest first), and the same filtered records reorder while the query and filters remain.	A user taps Urgent and Appeals, sees the result count drop immediately, then removes Appeals without losing the search query or sort order.	A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.	Users move through pages while query, filters, and sort persist.
Bad UX	Changing sort clears the search box and removes active filters.	Tapping a chip changes the page route and clears the result context.	Applying a filter silently resets the query, sort order, current page, and view density.	Changing page resets filters.
Best fit	Users need to compare or act on a result set in different orders.	A few common filters should stay visible and directly toggleable near the content.	Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.	The collection has many ordered results.
Avoid when	Users need to narrow which records are shown rather than change their order.	There are many criteria, ranges, dates, or grouped fields that need a panel or form.	The result set is small enough that scanning is faster than filtering.	Users need uninterrupted reading or comparison.
Required state	Default sort state that identifies the initial order and why it is appropriate.	Unselected chip set state with no active filters and a clear result count.	Default state with no user-applied filters and an explicit result count.	First page with disabled previous control.
Accessibility burden	Use a native select, radio group, or correctly implemented menu button for standalone sort controls.	Use button semantics for interactive chips and expose selected state with aria-pressed or equivalent semantics.	Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.	Use a labeled navigation region.
Common misuse	Putting filtering criteria such as date ranges, status, category, or owner inside a sort menu.	Using a lone chip as a generic Filter button.	Hiding active filters inside a closed panel with no count, chips, or result-state summary.	Using pagination for a tiny collection.

Sort controls

UI or UX: UI + UX - Control for changing the order of an existing result set
UI guidance: Place the active sort control above or inside the result region it affects, with a visible label such as Sort by and an option name that includes both the attribute and direction.
UX guidance: Use sort controls when users need to rearrange the same matching results by a meaningful attribute while preserving the current search query, filters, page size, and view context.
Good UI: A search results page shows Sort by with options like Relevance, Due date (oldest first), and Amount (highest first) above the results.
Bad UI: A menu labelled Sort contains Status: Open, Last 30 days, and Owner, which are filters rather than ordering rules.
Good UX: A user searches for case, changes Sort by from Relevance to Due date (oldest first), and the same filtered records reorder while the query and filters remain.
Bad UX: Changing sort clears the search box and removes active filters.
Best fit: Users need to compare or act on a result set in different orders.
Avoid when: Users need to narrow which records are shown rather than change their order.
Required state: Default sort state that identifies the initial order and why it is appropriate.
Accessibility burden: Use a native select, radio group, or correctly implemented menu button for standalone sort controls.
Common misuse: Putting filtering criteria such as date ranges, status, category, or owner inside a sort menu.

Filter chips

UI or UX: UI + UX - Compact chip set for toggling or removing result filters
UI guidance: Render filter chips as a compact set of short, consistently styled controls near the content they filter, with clear selected, unselected, focused, disabled, and removable states.
UX guidance: Use filter chips for quick, low-cost filtering when users can understand the available criteria at a glance and combine a few chips without opening a larger panel.
Good UI: A search results page shows chips for Open, Urgent, Appeals, and Benefits below the search box, with selected chips using a checkmark and stronger background.
Bad UI: A single pill labelled Filter sits alone and behaves like a vague button.
Good UX: A user taps Urgent and Appeals, sees the result count drop immediately, then removes Appeals without losing the search query or sort order.
Bad UX: Tapping a chip changes the page route and clears the result context.
Best fit: A few common filters should stay visible and directly toggleable near the content.
Avoid when: There are many criteria, ranges, dates, or grouped fields that need a panel or form.
Required state: Unselected chip set state with no active filters and a clear result count.
Accessibility burden: Use button semantics for interactive chips and expose selected state with aria-pressed or equivalent semantics.
Common misuse: Using a lone chip as a generic Filter button.

Filter panel

UI or UX: UI + UX - Grouped filter control panel for narrowing a current result set
UI guidance: Render filter categories as labelled form controls in a panel adjacent to the result set on wide layouts, with a visible result count and active-filter summary near the results.
UX guidance: Use a filter panel to help users narrow the current list or search result set while preserving orientation, search query, sort order, pagination context, and selected values.
Good UI: A desktop search page shows a left filter panel with Status, Type, and Date groups, while active chips and the result count sit above the results.
Bad UI: A filter drawer closes with no active count, leaving users unaware that filters are still hiding records.
Good UX: A user selects Status: Open and Type: Appeal, applies the batch, lands back at the result summary, and sees 12 records with both criteria removable.
Bad UX: Applying a filter silently resets the query, sort order, current page, and view density.
Best fit: Users need to narrow the current search results, browse results, table, card grid, or list by multiple criteria.
Avoid when: The result set is small enough that scanning is faster than filtering.
Required state: Default state with no user-applied filters and an explicit result count.
Accessibility burden: Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.
Common misuse: Hiding active filters inside a closed panel with no count, chips, or result-state summary.

Pagination

UI or UX: UI + UX - Paged navigation control
UI guidance: Render a labeled pagination nav near the affected results with current page, previous, next, nearby pages, optional first/last or ellipsis, and clear disabled edge states.
UX guidance: Help users move through an ordered result set with a stable sense of position, progress, and returnability.
Good UI: Current page, previous/next, disabled edges, page numbers, result range, and total count are visually clear.
Bad UI: Tiny numbers with no current state.
Good UX: Users move through pages while query, filters, and sort persist.
Bad UX: Changing page resets filters.
Best fit: The collection has many ordered results.
Avoid when: Users need uninterrupted reading or comparison.
Required state: First page with disabled previous control.
Accessibility burden: Use a labeled navigation region.
Common misuse: Using pagination for a tiny collection.

Decision rules

Prefer sort controls when the user needs the same matching items arranged by relevance, date, name, distance, price, priority, or another meaningful ordering attribute.
Prefer filter chips when a small visible set of criteria should include or exclude items directly above the current results.
Prefer a filter panel when users need grouped criteria, ranges, dates, or batch apply behavior that changes which records are present in the result set.
Prefer pagination when the ordered result set is too large to show at once and users need to move through pages without changing item order.
Do not put date ranges, status choices, categories, or ownership criteria inside a sort menu because those choices filter membership rather than reorder items.
Do not use filter chips for sorting because a selected chip implies inclusion or exclusion, while sort state should identify one active ordering rule.
When sort and pagination are combined, apply the sort to the whole data set and reset or explain the current page position so users do not think only the visible page was reordered.
When sort and search are combined, preserve the search query and filters while changing order, and announce the new result order near the result summary.
Use table header sorting when the sortable attribute is a visible column and users compare rows; use a separate Sort by control when the options apply to cards, search results, or a list without sortable columns.
Expose default, ascending, descending, loading, and unavailable states when sorting affects remote data, formatted dates, numeric values, or paginated results.

Inspect live examples

Sort controls Filter chips Filter panel Pagination

Failure modes

A sort menu includes Status: Open and Last 30 days, so users cannot tell which choices filter results and which reorder them.
Changing sort silently clears the current search query, active filters, selected view, or page size.
Only the current page is sorted, causing records on later pages to remain out of global order.
Dates are sorted as display strings, putting 10/1 before 2/20 in a newest-first list.
A table header toggles order but has no current-state icon, no aria-sort state, and no screen-reader announcement.
Sort options are labelled only Newest or A-Z even though the sortable attribute is ambiguous.