Pagination (UI)

Pagination splits a long list into pages and gives you controls to move between them. It is the oldest pattern for handling more data than fits, and in products where people work with data rather than browse it, it has not been improved on.

Its advantages are structural rather than aesthetic. Every item has a stable address. The size of the set is visible. Somebody can jump to a known position, leave, and come back to the same place.

Pagination, infinite scroll, load-more

The deciding question is whether anybody ever needs to get back to exactly where they were. In consumer feeds the answer is no, which is why infinite scroll suits them. In a support queue, an invoice list or a customer table the answer is yes, several times a day.

Infinite scroll also has a specific cost that is easy to miss: it makes the footer unreachable, which in a B2B product is often where support, settings and export live.

Getting the details right

Page and sort in the URL. Everything about the current view: page, sort column, direction, filters. This is what makes a view shareable, refreshable and compatible with the back button.

Say how many there are. "Page 3 of 47" tells somebody whether to page or to filter. "Page 3" alone tells them nothing about how much is left.

This is not a preference. Checked against shipped products in September 2026, the pattern is near-universal in tools that page through records: Supabase puts "Page 1 of 1 · 100 rows · 21 records" in the footer bar, Xero writes "Page 1 of 1 (13 total items)" beside a page-size control, and Profound uses the plainest version of all, "Showing 21 – 30 of 151 items". Three different products, three phrasings, one decision: the total is on screen.

A page-size control that is remembered. Somebody triaging and somebody auditing want different amounts, and being asked to set it on every visit is a small charge levied constantly.

Keep the controls in reach. Pagination only at the bottom of fifty rows means scrolling to the end to move on. Top and bottom, or a sticky footer.

Do not renumber underneath people. In a list that changes while being read, page boundaries shift and items get seen twice or missed. Cursor-based paging avoids this and is worth the implementation cost on anything live.

The B2B case

Selection has to survive paging. Selecting rows on page one, moving to page two and finding the selection gone is a common and expensive defect. Either preserve it and show the running count, or say plainly that selection applies to this page only.

Bulk actions need to be honest about scope. "Select all" almost always means the visible page, and people read it as the whole set. Say which, and offer both.

Deep pages get slow. Offset-based paging degrades badly at page four hundred. Cursor-based paging is the usual answer, and it removes the ability to jump to an arbitrary page, which is a real trade to make deliberately.

Export is the pressure valve. Somebody paging through hundreds of pages is doing something the product should let them do another way.

Paging, filtering and search together

Pagination is rarely used alone, and the three controls have to agree with each other.

Filtering resets the page. Applying a filter while on page seven should return to page one, because page seven of the new set is meaningless. Products that keep the page number here show an empty screen and look broken.

Sorting does not reset it, and probably should. Sorting while paged deep leaves somebody at an arbitrary position in a newly ordered set. Returning to the first page is usually right and worth stating in the interface.

Search replaces paging semantics. A search result set is usually short enough not to need pages at all, and where it is not, the count matters more than the page controls.

The underlying rule: whenever the set changes, the position in it is no longer meaningful. Products that treat page number as independent of the query produce views nobody asked for.

In practice

A support queue uses infinite scroll, on the reasoning that agents scan rather than search.

In use, they do both. An agent scrolls to find a ticket, opens it, resolves it, and returns to a list that has reset to the top. There is no way to share "the ticket I was looking at" with a colleague except by name. The export link in the footer is unreachable because new tickets load faster than the page can be scrolled.

Moving to pagination with the page and filters in the URL fixes all three. Agents return where they were, links can be pasted into chat, and the footer exists again.

The list is no faster. It is simply usable by people who leave it and come back, which was always what they were doing.

Where teams get it wrong

• No state in the URL. Nothing can be shared, refreshed or returned to.
• Infinite scroll on working data. Position lost, footer unreachable.
• "Page 3" with no total. No basis for deciding whether to filter instead.
• Selection lost on page change. A defect people work around by never paging.
• Ambiguous select-all. Read as the whole set, meaning the page.
• Controls only at the bottom. A scroll charged on every page turn.