Table vs Sort controls vs Filter panel vs Pagination

Choose table when users need to compare multiple records by the same visible attributes, scan row and column intersections, or read numeric and textual values in aligned columns.

Table live example Sort controls live example Filter panel live example Pagination live example

Decision dimensions

Dimension	Table	Sort controls	Filter panel	Pagination
UI or UX	UI + UX - Semantic row-and-column data comparison surface	UI + UX - Control for changing the order of an existing result set	UI + UX - Grouped filter control panel for narrowing a current result set	UI + UX - Paged navigation control
UI guidance	Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.	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 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 tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.	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 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 payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.	A search results page shows Sort by with options like Relevance, Due date (oldest first), and Amount (highest first) above the results.	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 div layout looks like columns but has no caption, table semantics, or header associations.	A menu labelled Sort contains Status: Open, Last 30 days, and Owner, which are filters rather than ordering rules.	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 sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.	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 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	Filtering the table removes selected rows without explaining why or offering a clear-filter path.	Changing sort clears the search box and removes active filters.	Applying a filter silently resets the query, sort order, current page, and view density.	Changing page resets filters.
Best fit	Records share comparable attributes that users need to scan in aligned columns.	Users need to compare or act on a result set in different orders.	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	The content is layout, not data.	Users need to narrow which records are shown rather than change their order.	The result set is small enough that scanning is faster than filtering.	Users need uninterrupted reading or comparison.
Required state	Default table state with caption, visible headers, row values, and result count or context.	Default sort state that identifies the initial order and why it is appropriate.	Default state with no user-applied filters and an explicit result count.	First page with disabled previous control.
Accessibility burden	Use native table semantics for tabular data rather than div-only rows.	Use a native select, radio group, or correctly implemented menu button for standalone sort controls.	Use semantic form controls with fieldsets, legends, labels, and accessible names for filter categories and values.	Use a labeled navigation region.
Common misuse	Using table markup to create page columns or layout spacing.	Putting filtering criteria such as date ranges, status, category, or owner inside a sort menu.	Hiding active filters inside a closed panel with no count, chips, or result-state summary.	Using pagination for a tiny collection.

Table

UI or UX: UI + UX - Semantic row-and-column data comparison surface
UI guidance: Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance: Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI: A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI: A div layout looks like columns but has no caption, table semantics, or header associations.
Good UX: A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX: Filtering the table removes selected rows without explaining why or offering a clear-filter path.
Best fit: Records share comparable attributes that users need to scan in aligned columns.
Avoid when: The content is layout, not data.
Required state: Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden: Use native table semantics for tabular data rather than div-only rows.
Common misuse: Using table markup to create page columns or layout spacing.

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 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

Choose table when users need to compare multiple records by the same visible attributes, scan row and column intersections, or read numeric and textual values in aligned columns.
Choose sort controls when the records already exist and the task is changing order by a named attribute such as due date, amount, status, or owner.
Choose filter panel when the task is excluding records by criteria such as status, date range, owner, type, or amount band rather than changing their row order.
Choose pagination when the same table has too many rows for one page and users need stable page position, result range, previous and next controls, or shareable page state.
A table may include sortable headers, filters, and pagination, but those controls must preserve the table caption, column meanings, current sort, active filters, row selection, and result count together.
Do not make the table itself responsible for open-ended search, broad filtering, or page traversal without labelled controls and state feedback around the table.
Use a data grid rather than a basic table when cells are directly editable, rows contain keyboard-managed widgets, or arrow-key navigation across interactive cells is central to the task.
Use list view or card layout instead of table when rows do not share comparable columns or when each item needs a rich object summary more than column-by-column comparison.
When a table is sorted or filtered, keep row headers, selected rows, expanded rows, and focus stable unless the affected row is intentionally removed.
On narrow screens, preserve header-to-cell meaning through horizontal scroll, responsive stacking, or column reduction rather than dropping headers or turning cells into unlabeled text.

Inspect live examples

Table Sort controls Filter panel Pagination

Failure modes

A table is used for page layout or visual alignment instead of related data.
Column headers disappear on mobile, leaving values such as Open, 42, and May 14 with no meaning.
Sort and filter controls update rows but the caption, result count, active sort, and active filters disagree.
Pagination changes pages and loses selected rows, expanded detail, or the current sort order.
A table becomes a spreadsheet-like data grid with editable widgets but still uses simple table keyboard behavior.
Long text, actions, and status tags are packed into columns until the table is unreadable and no detail route or expandable-row pattern exists.