Pagination vs. Infinite Scroll vs. Load More

Interactive example · Pagination vs. load more vs. infiniteCompare the three

PaginationLoad moreInfinite

Item 1

Item 2

Item 3

Item 4

Item 5

Item 6

Prev1234Next

Pagination — best when users need to find a known item, jump around, or remember a position. Keeps the page bounded and footers reachable.

The full lesson

How you display large collections of content matters more than it seems. Watch a user frantically scroll trying to find a job listing they saw yesterday, and you’ll understand why. Or ask your SEO team why indexed product pages have disappeared from search results.

Pagination, infinite scroll, and load more are not interchangeable. Each one makes a promise to users about how they can find and return to content. Pick the wrong one, and you exhaust your users instead of helping them.

The Three Patterns at a Glance

Before comparing, here are crisp definitions.

Pagination splits content into numbered pages. Users navigate explicitly — clicking “Next”, “Previous”, or a page number. Each page has its own stable URL. It is the oldest pattern and still the right choice in many situations.

Infinite scroll automatically loads the next batch of content as the user nears the bottom of the page. The user doesn’t click anything — the feed just keeps growing. Social media made this popular in the early 2010s. Since then, it has been widely misapplied.

Load more is a hybrid. Content loads in batches on the same page. A button — usually labeled “Load more” or “Show more results” — triggers each new batch. The user stays in place and sees more content appear below what they’ve already read.

	Pagination	Infinite Scroll	Load More
User control	High (explicit)	Low (automatic)	Medium (deliberate)
URL addressability	Per-page	Usually none	Usually none
Scroll position persistence	None	Often lost on back	Often preserved
SEO-friendly	Yes (with rel prev/next signals)	Requires extra work	Requires extra work
Task type fit	Goal-directed	Exploratory/browsing	Mixed
Accessibility	Well-understood	Complex to implement	Simpler than infinite scroll

When to Use Pagination

Pagination works best when users need to reference, return to, or share a specific place in a dataset.

Use it for:

• Search results and filtered product catalogs. Users scan, leave, return, and compare. A stable URL like /results?q=running+shoes&page=3 lets them bookmark, share, and backtrack.
• Data tables and admin interfaces. Operators process rows in batches and often need to jump to a specific page. “Where was that order?” is a question answered by a page number, not by scrolling.
• Any context where the total result count matters. “Page 3 of 47” tells users how much is left. They can decide whether to refine their search or keep browsing.
• Content with a defined sequence — documentation chapters, lesson modules, multi-step forms.

A common mistake is using pagination for everything just because it feels familiar — and then implementing it carelessly: no keyboard focus management on page change, no aria-label on the navigation, and no scroll-to-top so users land mid-page after clicking “Next”.

Good pagination does four things:

1. Moves keyboard focus to the first result after a new page loads (or announces the change with a live region).
2. Marks the current page with aria-current="page" on the active link.
3. Wraps the controls in a nav element with a descriptive aria-label like “Search results pages”.
4. Adds link rel="prev" and link rel="next" in the document head for SEO crawlers. Google retired these as a ranking signal but still uses them for crawl discovery.

When Infinite Scroll Actually Works

Infinite scroll gets a bad reputation, but most of that criticism is aimed at misuse. There are genuine cases where it’s the right choice:

• Chronological or algorithmic feeds where no specific item is the goal. Think social media timelines, activity logs, or news rivers. The user is browsing, not searching. They have no destination — just an appetite. Automatic loading removes friction from that browsing motion.
• Media galleries with uniform visual items. A photographer’s portfolio, a wallpaper app, a mood board. Visual skimming is fast, stopping is easy, and re-finding a specific image isn’t the use case.
• Contexts where scroll position is preserved on back navigation. This is the critical implementation detail most teams get wrong. If the user taps an item, reads it, and presses back, they should return to exactly where they were. Browsers handle this automatically when content stays in the DOM — but it breaks when items are virtualized or when the back button loads a new URL.

Where infinite scroll routinely fails:

• E-commerce product listings. Users compare, leave, and return. Losing their position means losing the sale. A 2024 Baymard Institute study found that 76% of users who lost their scroll position on a product listing abandoned or started over rather than trying to relocate the item.
• Search results. Users need to know how many results exist and how far through them they are. Infinite scroll communicates neither.
• Any page with important footer content. The footer becomes unreachable when the page keeps growing. Teams patch this with sticky footers or footer-above-the-fold tricks — but those are band-aids on a wrong pattern choice.

When Load More Is the Right Compromise

Load more gives users a sense of control — they decide when to see more — while keeping everything on one scrollable canvas. That makes it the best default for many mid-complexity situations.

Best fits:

• Product listings with moderate depth. Users see 24 products, want more options, click “Show 24 more”, and keep scanning. Their scroll position is preserved. The URL doesn’t need to change. The experience feels lighter than pagination.
• Comment threads and review sections. Showing 10 reviews with a “Show all 84 reviews” button respects the page hierarchy — the product is the focus, not the reviews — while giving motivated readers full access.
• Mobile-first surfaces with natural thumb zones. A button at the end of a list is a natural resting spot after a scroll gesture and an easy thumb tap. It’s more accessible than infinite scroll and less disruptive than paginating to a new page.

Implementation details that matter:

• Label the button with a count. “Load 20 more results” is more useful than “Load more”. Users can gauge the effort.
• After new content loads, move keyboard focus to the first newly added item. This is the most commonly missed accessibility requirement in load-more implementations.
• Show progress: “Showing 48 of 132 products” keeps users oriented.
• If JavaScript fails, the button should link to a paginated fallback URL. This progressive-enhancement pattern also handles sharing and bookmarking scenarios.

Accessibility Considerations Across All Three

Accessibility is where the differences between these patterns become sharpest — and where most implementations fall short.

Keyboard and focus management

Every pattern must answer the same question: after content changes, where does focus go?

For pagination (a full-page navigation), focus typically moves to the top of the page or to an h1 or skip-link target. For load more and infinite scroll, focus should move to the first new item.

For infinite scroll specifically, use an ARIA live region (aria-live="polite") to announce when new content has loaded — something like “12 more results loaded, 48 total.” Screen reader users navigating sequentially will eventually encounter the new content, but the announcement gives them context without interrupting what they’re reading.

The inert attribute and scroll traps

When content is loading (showing a skeleton or spinner), mark surrounding non-interactive content with the inert attribute. This prevents keyboard users from tabbing into partially loaded regions. It’s the modern replacement for the old tabindex="-1" and aria-hidden="true" juggling act that plagued earlier infinite-scroll implementations.

Scroll position and the WCAG 1.4.13 context

WCAG 2.2 doesn’t have a specific criterion for scroll position loss. But the principle of predictable navigation (3.2 Predictable) covers unexpected content rearrangement. If pressing “back” scrolls a user to the top instead of their last position, that’s a predictability failure — even if no specific criterion names it.

Performance and Perceived Speed

The loading pattern you choose shapes your entire performance budget.

Pagination loads a fixed, bounded payload per page. Render time is predictable and easy to budget for. The trade-off is full-page navigations — which carry a cost. Using the View Transitions API (now baseline in Chrome and Safari, with Firefox support arriving in 2025) turns those hard page swaps into smooth animated transitions, without the overhead of a single-page-app router. This is a meaningful modern upgrade to pagination UX.

Infinite scroll loads content in chunks, but those chunks pile up in the DOM. After 500 or 1,000 items, memory pressure and layout recalculation costs become real — especially on low-end Android devices. The fix is virtual scrolling: only the visible items (plus a small buffer) are rendered in the DOM at any one time. Libraries like TanStack Virtual handle this well, but the implementation is substantial. Teams frequently ship infinite scroll without virtualization and pay for it at scale.

Load more typically loads a small, fixed batch, adds it to the DOM, and stops. It has the simplest performance profile of the three and rarely needs virtualization unless batches are enormous.

SEO and Shareable URLs

This is where infinite scroll and load more create the most hidden business risk.

Pagination produces discrete, crawlable URLs. Googlebot can follow ?page=2, index the content, and surface individual pages in search results. E-commerce sites with paginated category pages get each page indexed independently — that’s a substantial amount of search surface area.

Infinite scroll produces a single URL. To make it crawlable, you need to implement a companion URL scheme that Googlebot can discover — typically via a link rel="alternate" pointing at paginated equivalents, or via a sitemap. Google’s own guidance acknowledges that infinite scroll is harder to crawl correctly.

Load more has the same limitation unless you progressively enhance the button to link to a real paginated URL. Here’s the recommended pattern:

<!-- Load more button with progressive enhancement -->
<button data-load-more data-next-url="/products?page=2">
  Load 24 more products
</button>

When JavaScript is available, the click handler intercepts and fetches more content in place. When JavaScript is absent — crawlers, failures — the button falls through to the paginated URL. You get the UX of load more and the crawlability of pagination.

Decision Framework

Use this heuristic to pick the right pattern:

1. Is the user trying to find a specific, re-findable item? Use pagination. The user needs a stable reference point.
2. Is the user browsing without a specific goal, in a feed-like context? Infinite scroll may be appropriate — but only if you can handle scroll restoration, accessibility, and virtualization correctly.
3. Is the user exploring a bounded, medium-depth collection where returning to position matters? Load more is likely the best default.
4. Does the page have a footer with important content? Infinite scroll is disqualified. Choose pagination or load more with a fixed-height scroll region.
5. Is SEO a priority? Pagination with proper link structure is the lowest-risk choice. Load more with progressive enhancement is viable. Bare infinite scroll requires significant extra work.

Most product teams should default to load more with paginated fallback for listings and pagination for search and tables — unless there’s a strong, tested reason to use infinite scroll.