Pagination

You’re shopping for a tent. You scroll to the bottom of page 1, tap 2, and the first tent on page 2 is… the last tent from page 1. You open a promising one on page 3, press Back, and you’re on page 1 again. You give up and buy somewhere else.

Pagination looks like a row of small numbers. Underneath, it’s arithmetic (which items belong on page 3?), state (where was the user?) and boundaries (page 1, the last page, page 0, page 999). Those three are exactly where testers find bugs.

What is it?

PaginationPaginationSplitting a long list into pages that load one at a time.Open in glossary → splits a long list (products, search results, orders, transactions) into pages that load one at a time. The user moves with Previous / Next and page numbers. Pages keep each request small and fast, and give users a sense of where they are: page 5 of 16.

You’ll meet it in web shops and search results, bank transaction histories, admin tables, and in the API behind almost every list in a mobile app, even when the app hides it behind a “Load more” button or infinite scrollInfinite scrollLoading more items automatically when the user reaches the bottom of a list.Open in glossary →.

Anatomy

Numbered pages, “Load more” or infinite scroll?

There are three common ways to reveal the rest of a long list. Each one is valid in the right place. Switch between them and try to reach the footer:

Numbered pages“Load more” buttonInfinite scroll

9:41

Tents & packs

• Alpine Backpack€9.99
• Breeze Backpack€46.99
• Cedar Backpack€83.99
• Dune Backpack€120.99
• Ember Backpack€157.99
• Fjord Backpack€14.99
• Glacier Backpack€51.99
• Harbor Backpack€88.99

Numbered pages

Scroll down and use Prev / Next. The footer is right below the pager.

• + You always know where you are (page 3 of 8)
• + Page can live in the URL: share, refresh, Back
• + Footer is always reachable

• − Extra taps to see more
• − Small targets on phones if done badly

Items on screen: 8 of 60 · page 1 of 8

Pattern	Best for	Watch out for
Numbered pages	Search results, shops, tables, anything users compare or come back to	Tiny targets on phones, wrong page math
“Load more” button	Mobile lists, product grids	Losing loaded items and position after Back
Infinite scroll	Social feeds, photo streams, “just browsing”	Unreachable footer, no sense of position, memory, accessibility

Designs & variants

• Full pager (web, desktop): ‹ 1 … 4 5 6 … 16 ›. Shows first, last, the current page and its neighbors, with an ellipsis for the gaps.
• Compact pager (phones): ‹ Prev · Page 5 of 16 · Next ›. Fewer, bigger targets. Material and Apple’s guidelines don’t define a numbered pager; mobile apps usually prefer “Load more” or infinite scroll.
• Prev / Next only: for feeds or cursor-based APIs where the total isn’t known.
• With a page size selector: “Per page: 20 / 50 / 100”, common in tables and admin tools.
• With a result summary: “Showing 81–100 of 312”. Small text, many bugs.

When to use it

• Users need to find, compare and come back to items: shops, search results, statements, admin tables.
• The list is long (hundreds or thousands of items) and loading everything would be slow.
• The page should be shareable or bookmarkable (“look at page 3 of the sale”).
• There is important content below the list: a footer, filters, contact details.

Good and bad uses

How good pagination behaves

The page lives in the URL

On the web, the current page (and page size, sort, filters) belongs in the address: a query parameterQuery parameterData in a URL after the ?, like ?q=mug&sort=price, often used to keep search and filter state.Open in glossary → like shop.example.com/products?page=3&size=20. That single decision makes Back, Refresh, bookmarks and shared links all work. If the URL never changes, Back from a product takes the user to page 1, and a refresh throws away their place.

In apps, the same idea applies: after opening an item and going back, the list must be exactly where it was: same page, same loaded items, same scroll position.

The math is right at every boundary

Page n shows items (n − 1) × size + 1 to n × size, but never more than the total. Classic boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → applies; test these pages every time:

Page	What should happen
1	Prev disabled. Items 1–20.
2	Starts with item 21. Nothing from page 1 repeats.
Last (16)	Next disabled. “Showing 301–312 of 312”. Only 12 items.
0, −1, abc	Redirect to page 1 (or a clear error). Never a crash.
999	A helpful “This page doesn’t exist” with a link to the last page. Not an endless spinner.

Also check the edges of the data, not just of the pager: 0 results (an empty state, no pager), exactly one page (no pager, or both arrows disabled), exactly 20 items with 20 per page (one page, not two with an empty second one), and a last page with exactly one item.

Changing the page size lands somewhere sensible

On page 8 with 20 per page, the user switches to 50 per page. There are now only 7 pages, so “page 8” doesn’t exist. Good apps go back to page 1, or better, to the page that contains the item the user was looking at (item 141 → page 3). Same rule when a filter reduces the results: never leave the user on a page that no longer exists.

Data that changes between pages

Lists aren’t frozen. While you read page 1, new listings get posted and others sell out. With offset pagination (“skip 20, take 20”), that shifts everything: you see duplicates when items are added, and miss items when items are removed. Cursor pagination (“20 items after item X”) largely avoids it, because each page starts right after the last item you actually received. Try both:

New listing posted A page-1 item sells outNext page Reset

Page 1 (what you saw)

newest first

1. City bike
2. Desk chair
3. Coffee grinder
4. Guitar

Since then: 0 new, 0 removed

Change the data with the buttons above, then press “Next page”.

As a tester you can’t choose the strategy, but you can find the bug: open page 1, have someone (or an admin tool, or a second device) add or delete items, then go to page 2. Report duplicates and missing items with the exact items involved.

Common bugs

#	Bug	What you see	Typical severity
1	Off-by-one offset	Last item of page 1 repeats on page 2, or one item is never shown	High
2	Wrong result summary	“Showing 301–320 of 312” on the last page	Low
3	Next enabled on the last page	Leads to an empty page or an error	Medium
4	Out-of-range page	?page=999 shows an endless spinner, a crash or a blank page	Medium
5	Page size change keeps the page	Page 8 of 7: an empty list	Medium
6	Page not in the URL	Back, refresh or a shared link always open page 1	Medium–High
7	Duplicates or gaps after data changes	The same item twice, or items missing across pages	Medium
8	Wrong total	“16 pages” but page 16 is empty, or the count ignores a filter	Medium
9	Tiny targets on phones	24 px page numbers, users hit 4 instead of 5	Medium
10	Filters/sort reset when paging	Page 2 shows unsorted, unfiltered results	High

Stress-test it

A correct pager on a correct list. The page and page size are in the URL. Try the browser Back and Reload buttons, type ?page=999, ?page=0 or ?page=abc in the address, switch Results to 0 or 7, and change Per page while you’re on the last page.

Results

073125,000

Per page

102050

Layout

DesktopPhone

shop.example.com/products…/productsQuery stringGo

Outdoor gear

HTTP 200 OK

Showing 1–20 of 312

• #1Alpine Backpack€9.99
• #2Breeze Backpack€46.99
• #3Cedar Backpack€83.99
• #4Dune Backpack€120.99
• #5Ember Backpack€157.99
• #6Fjord Backpack€14.99
• #7Glacier Backpack€51.99
• #8Harbor Backpack€88.99
• #9Indigo Backpack€125.99
• #10Juniper Backpack€162.99
• #11Kestrel Backpack€19.99
• #12Lagoon Backpack€56.99
• #13Maple Backpack€93.99
• #14Nova Backpack€130.99
• #15Onyx Backpack€167.99
• #16Pine Backpack€24.99
• #17Quartz Backpack€61.99
• #18Ridge Backpack€98.99
• #19Sierra Backpack€135.99
• #20Tundra Backpack€172.99

Screen reader on the pager

“Pagination, navigation” … “Page 1, current page, button”

Try these

• Go to page 3, then browser Back and Reload
• Type ?page=999, ?page=0 or ?page=abc
• Open the last page, then switch Per page to 50

Find the bug

This web shop lists 312 products, 20 per page, and has six bugs. Explore it like a tester:

• Compare the last product on page 1 with the first one on page 2.
• Go to the last page (16) and read everything on it. Then look at the arrows.
• Use the links panel: a bookmark to ?page=3 and an old link to ?page=999. Watch the Network log.
• Go to page 8 and change Per page.
• Go to page 3, open a product, then use the browser’s Back (and try Reload).

🐞 Bug hunt: Outdoor gear list

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

Address

Loading products…

Links from emails & bookmarks

Restart

/products?page=3 /products?page=999

Network

• API requests appear here…

1. 1

   Hint: Note the last product on page 1, then go to page 2.

   The last product of page 1 appears again on page 2

   The app requests offset=19 for page 2 (see the Network log) instead of offset=20. The code computes (page − 1) × size − 1, an off-by-one error. Every page after page 1 starts one item early, so users see duplicates.

   Reveal answer✓ I found this
2. 2

   Hint: Go to page 16 and read the text under the title.

   The result summary is wrong on the last page

   It says Showing 301–320 of 312, although there are only 312 products. The end of the range must be min(page × size, total): 301–312. (And because of bug 1, page 16 actually shows 13 items.)

   Reveal answer✓ I found this
3. 3

   Hint: On page 16, look at the › arrow and tap it.

   Next is enabled on the last page and leads to an empty page

   Next is only disabled when page > totalPages, so on page 16 it still works and opens a blank “page 17”: the API answers 404 and the app shows an empty grid. Expected: Next is disabled on the last page.

   Reveal answer✓ I found this
4. 4

   Hint: Open the shop.example.com/products?page=999 link and wait. Check the Network log.

   ?page=999 shows an endless spinner

   The API answers 404 out_of_range, but the first-load code ignores errors, so “Loading products…” spins forever. Old bookmarks and links from emails hit this. Expected: a message like “Page 999 doesn’t exist, there are 16 pages” with a link to the last page.

   Reveal answer✓ I found this
5. 5

   Hint: Go to page 8, then set Per page to 50 or 100.

   Changing the page size keeps a page that no longer exists

   With 50 per page there are only 7 pages, but the app stays on page 8 and shows an empty list (and a summary like 351–400 of 312). Expected: go to page 1, or to the page that contains the first item the user was looking at.

   Reveal answer✓ I found this
6. 6

   Hint: Go to page 3, open a product, press the browser Back button.

   Back from a product (and Reload) returns to page 1

   The address never changes while paging: it stays /products. So Back, Reload and shared links all start at page 1. The app even reads ?page=3 when you open that link, it just never writes it. Expected: the URL updates to ?page=3 and Back returns there.

   Reveal answer✓ I found this

How to test it

Checklist

Pagination test checklist

0 of 14 checked

Copy

• Page 1: Prev disabled, items 1 to N, summary correct
• Last item of each page is not repeated on the next page, and no item is skipped
• Last page: Next disabled, summary ends at the total (301–312 of 312), only the remaining items shown
• Totals at the edges: 0 results (empty state, no pager), exactly one page, a last page with one item
• URL contains the page: refresh, Back, Forward, bookmarks and shared links keep it
• Invalid pages (?page=0, -1, abc, 3.5) redirect to page 1 or show a clear error
• Out-of-range pages (?page=999) show a helpful message, not a spinner or blank screen
• Changing the page size, sort or filters never leaves you on a page that does not exist
• Sort order and filters are kept when moving between pages
• Adding or removing items between page loads does not cause duplicates or gaps (or it is a known, accepted risk)
• After opening an item and going back, the list is on the same page and scroll position
• Pager targets are at least 44×44 pt (iOS) / 48×48 dp (Android) on touch screens
• Keyboard: every control reachable with Tab, visible focus, Enter activates
• Screen reader: pager is a navigation landmark, current page announced as current, ellipsis not read

Example test cases

Tools

• The URL bar is your best tool: edit ?page= and ?size= by hand to hit every boundary in seconds.
• DevTools › Network (see DevTools for testers): filter by the API path and check page, offset, limit or cursor for each click. An offset=19 on page 2 is a bug you can prove.
• API directly (Postman): request the last page, page=0, a negative page and a huge page; check status codes and the total field.
• Mobile apps: use a proxy tool (Charles, Proxyman) to see the paging requests behind “Load more” and infinite scroll.

Accessibility

• Landmark. The pager is a navigation landmark, so screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → users can jump straight to it. If there are two pagers (top and bottom), label them differently or keep only one.
  Dev note

  Wrap the pager in <nav aria-label="Pagination">.
• Current page. Mark it with a visual style that isn’t only color (bold, filled background). Screen readers then say “Page 3, current page”.
  Dev note

  Mark it with aria-current="page".
• Real links or buttons. Page numbers should be links or buttons. Give arrow-only controls an accessible name: “Previous page”, “Next page”. Hide the ellipsis from screen readers.
  Dev note

  Links like <a href="?page=3">, not clickable <span>s.
• Disabled states. Prev on page 1 and Next on the last page should be disabled and announced as dimmed or unavailable, not just greyed out with a working click.
• KeyboardKeyboard navigationUsing a website with only the keyboard: Tab to move, Enter or Space to activate, Esc to close.Open in glossary →. Everything reachable with Tab, visible focus, Enter activates. After changing page, move focus to the top of the results (or the results heading) so keyboard users don’t have to tab back up through the whole page.
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →. At least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px, and 44×44 px (2.5.5, AAA) is the comfortable target. A row of ten 24 px numbers is a classic mobile failure; a compact “Page 3 of 16” with big Prev/Next buttons is better.
• Infinite scroll is hard for keyboard and screen reader users: new items appear without notice and the footer is unreachable. Offer a “Load more” button or a way to pause loading.

Mobile vs web

iOSAndroidWeb

• No native numbered pager. Lists usually load the next page when the user nears the end (infinite scroll) or show a Load more row.
  Dev note

  UITableView, SwiftUI List.
• Test on a slow network: is there a loading row at the bottom? What happens if loading fails: a Retry button, or a silent dead end?
• Pull to refresh while on “page 3” of loaded items: does the list reset cleanly without duplicates?
• Open an item, go back: the list must keep every loaded item and the scroll position.

• Lists usually load pages as you scroll.
  Dev note

  RecyclerView with the Paging library, or a LazyColumn in Compose.
• Check rotation and process death (Developer options › Don’t keep activities): does the list come back on the same position, or restart from the top?
• Fast scrolling (“fling”) through hundreds of items: watch for duplicates, gaps, placeholders that never fill and jumps in position.
• Use airplane mode mid-scroll: a clear error row with Retry, not an endless spinner.

• Numbered pagination is most common here. The page must be in the URL: test Back, Forward, Refresh, bookmarks and shared links.
• Edit the URL by hand: ?page=0, ?page=999, ?page=abc, ?size=10000 (does the server cap the size?).
• Check the responsive layout: at 360 px, does the pager wrap neatly, switch to a compact version, or overflow the page?
• Search engines index paginated pages: every page should have its own URL and return 200; non-existent pages should return 404, not an empty 200 page.

Check your understanding

Quick quiz

0/6 answered · 0 correct

1. 1.The last product on page 1 is also the first product on page 2. What is the most likely cause?

   ASlow networkBAn off-by-one error in the offsetCA caching problem in the browserDCorrect behavior

2. 2.There are 312 products and 20 per page. What should the summary say on the last page?

   AShowing 301–320 of 312BShowing 301–312 of 312CShowing 300–312 of 312DShowing 16 of 16

3. 3.A user goes to page 3, opens a product and presses Back. They land on page 1. What is the root cause most likely to be?

   AThe page is not stored in the URLBThe server is too slowCThe page size is too bigDThe Back button is broken

4. 4.Which pattern makes the footer (Help, Contact) hard or impossible to reach?

   ANumbered pagesBLoad more buttonCInfinite scroll

5. 5.You are on page 8 (20 per page, 312 items) and switch to 50 per page. What is a good result?

   AStay on page 8BGo to page 3, which contains item 141CShow an errorDGo to the last page

6. 6.Which attribute tells screen reader users which page they are on?

   Aaria-selected="true"Baria-current="page"Caria-pressed="true"Drole="tab"

Key takeaways

• Pagination is math, state and boundaries. Always compare the last item of one page with the first of the next.
• Test page 1, page 2, the last page, page 0, page 999 and invalid values like abc.
• The page belongs in the URL so Back, refresh and shared links work. In apps, the list must keep its place after going back.
• Changing the page size, sort or filters must never leave the user on a page that doesn’t exist.
• Data that changes between page loads causes duplicates and gaps with offset paging.
• Choose the pattern on purpose: numbered pages to find and return, Load more for mobile lists, infinite scroll for feeds only.
• Accessibility: a nav landmark, aria-current="page", real links or buttons, and 44 pt / 48 dp touch targets.