Infinite Scroll

Also called endless scroll, continuous scroll, load more, lazy list

A list that loads additional items automatically as the user approaches the end, rather than splitting them into pages.

Example

Scroll inside the box. The first batches load on their own, then it hands over to the button — the hybrid that keeps the bottom of the list reachable.

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Loading on its own while you scroll.

The button is present the whole time; the observer only presses it for you. The count is announced in a live region, and focus never moves when new items arrive — someone reading mid-post should not be thrown to the newest batch.

When to use it

The content is a browsing feed with no natural end — a timeline, a photo grid, a discovery surface.
Nobody needs to return to item 240. The value is in what is next, not in what was.
There is nothing below the list. If the page ends with the feed, nothing gets buried.
The primary context is mobile, where scrolling is cheaper than tapping small page numbers.

When not to

There is a footer. It becomes practically unreachable, and people do go looking for terms, contact links and settings.
The user will want to come back to a specific item. Without page URLs, returning means scrolling from the start.
The list is search results or working data — anything where “where was I” is a real question.
The set is large and each item is heavy. Memory grows without limit unless you virtualise, and the page degrades the longer someone stays.

Trade-offs

No interruption between batches, which suits casual browsing.
Natural on touch, where scrolling costs nothing.
Removes the decision of whether to continue — which is precisely why engagement metrics like it.

The footer becomes unreachable, and this is the complaint users actually voice.
Back and forward stop being useful; leaving and returning loses the position.
Screen reader and keyboard users have the hardest time — the list simply grows underneath them with no announcement unless you build one.
Unbounded DOM growth hurts memory and scroll performance without virtualisation.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard: Provide a real “Load more” button as well as, or instead of, automatic loading. It is the single change that makes the pattern usable by keyboard.
After loading, leave focus where it is and announce the new count — do not jump the user to the first new item.
Never let the load trigger be reachable only by scrolling; a keyboard user may never fire it.
Roles and state: Announce additions through a polite live region: “20 more items loaded, 60 total.” Without it the list grows silently.
Set `aria-busy` on the list while a batch is in flight.
If the page count is known, say so somewhere — “60 of 340” gives back the orientation the pattern removed.
Focus: Focus must never move on its own when new items arrive. The user could be mid-sentence in a post; stealing focus to the newest batch is disorienting and, with a screen reader, actively hostile.

In the wild

Instagram — The canonical case — a browsing feed with no end and nothing below it.
Google Photos — Infinite, but paired with a date scrubber so position is not entirely lost.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.

Infinite Scroll vs Pagination