How many pages will a list have?

The total divided by the page size, rounded up. 105 items at 20 per page is 6 pages, the last holding 5.

What is the exact-division trap?

When the total divides exactly, an off-by-one in the page count shows a phantom empty page after the last real one.

Does this cover cursor pagination?

No — this is offset and limit. Cursor pagination has different failure modes, chiefly items shifting between requests.

Pagination Test Case Generator

Give it a total and a page size and it works out every page — offset, first and last item, and how many that page holds — plus the specific cases where pagination goes wrong: exact divisions, partial last pages, and requests past the end.

Total items

How many rows the list holds altogether.

Page size

How many items each page shows.

105 items at 20 per page · 6 pages · last page holds 5

Cases worth testing

Partial last page: Page 6 holds 5 of 20. Check the UI does not pad it or report the wrong total.
First page: Offset 0, items 1 to 20. Check there is no previous link.
Last page: Offset 100, items 101 to 105. Check there is no next link.
Past the end: Request page 7. Decide deliberately whether that is an empty page, a 404, or a redirect to the last page — all three are defensible and picking none of them is the bug.

Totals worth testing around this page size

0, 1, 19, 20, 21, 39, 40, 41, 59, 60, 61

Page	Offset	Items	Count
1	0	1–20	20
2	20	21–40	20
3	40	41–60	20
4	60	61–80	20
5	80	81–100	20
6	100	101–105	5(partial)

What this generator does

Names the cases rather than just listing pages. Anyone can divide a total by a page size; the useful output here is the four or five totals where pagination reliably breaks — an exact division that produces a phantom empty page, a single item, an empty list, and one either side of a boundary.

How to use this tool

Enter how many items the list holds.
Enter the page size.
Read the edge cases first, then the page table.
Copy the CSV into your test fixture.

Understanding the controls

Total items: How many rows the list holds. Zero is a legitimate value and produces the empty-list case, which is one of the commonest pagination bugs.
Page size: How many items each page shows. The relationship between this and the total is what decides whether the last page is full, and that is where the interesting cases are.

Worked examples

105 items at 20 per page: 6 pages, the last holding 5. Offsets 0, 20, 40, 60, 80, 100.
100 items at 20 per page: Exactly 5 pages — and the case where an off-by-one shows a phantom empty page 6.
Boundary totals for a page size of 10: 0, 1, 9, 10, 11, 19, 20, 21, 29, 30, 31 — the values worth testing.

Common use cases

Writing tests for a paginated API endpoint
Checking a UI handles the last page and the empty case
Producing fixture sizes that exercise the boundaries
Reviewing pagination in code review with the numbers to hand
Debugging an off-by-one that only appears at certain totals

How this generator works

The page count is the total divided by the page size, rounded up. Each page's offset is its zero-based index times the page size, its first item is that offset plus one, and its last is the smaller of the offset plus the page size and the total — which is what makes the final page partial when the division is inexact. The edge cases are then derived from the relationship between the two numbers rather than being a fixed list, so an exact division raises the phantom-page warning and an inexact one raises the partial-page warning instead.

Randomness and fairness

Nothing here is random. Every figure is arithmetic on the two numbers you enter, so the same inputs always give the same plan — which is what makes it usable as a source of test fixtures.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

This covers offset-and-limit pagination. Cursor or keyset pagination has entirely different failure modes — chiefly items shifting between requests — and none of them are modelled here.
It assumes the list is stable while being paged. Insertions and deletions during paging cause items to be skipped or repeated, which is a real bug this tool cannot show you.
Sort order is not considered, though an unstable sort is a common cause of items appearing on two pages.
The page table is capped at 50 rows on screen for very large lists, though the edge cases and counts remain exact.

Common mistakes

Not testing the exact-division case: When the total divides exactly, an off-by-one produces an empty page after the last real one. It is the single commonest pagination bug.
Leaving the past-the-end behaviour undecided: Requesting page 11 of 10 should be an empty page, a 404, or a redirect. All three are defensible; not choosing is the bug.
Forgetting the empty list: Zero items should give an empty page rather than an error, and the UI should say so rather than showing a blank grid.

Practical tips

Use the boundary totals as your fixture sizes — they exercise the interesting cases with the fewest rows.
Test page 0 and negative pages too; both are common inputs and neither should crash.

Privacy and your data

Only two numbers are entered and both are handled in your browser. Nothing is uploaded, stored or written into the page address. Analytics records nothing about the values.

Frequently asked questions

How many pages will a list have?: The total divided by the page size, rounded up. 105 items at 20 per page is 6 pages, the last holding 5.
What is the exact-division trap?: When the total divides exactly, an off-by-one in the page count shows a phantom empty page after the last real one.
Does this cover cursor pagination?: No — this is offset and limit. Cursor pagination has different failure modes, chiefly items shifting between requests.