Pagination math:
counting pages, offsets and the last page

The page-count formula and why it rounds up

Splitting a list into fixed-size pages seems simple until the last page is partly full. A list of 100 items at 20 per page makes exactly five pages. Add one item and it makes six, because the extra item needs a page of its own.

Rounding to nearest or truncating are the usual bugs here. Truncating drops the final partial page, which means the last records can never be reached through the interface.

Page numbers, offsets and limits

Most APIs accept either a page number or an offset. They are related by one multiplication, and the only trap is whether pages count from 0 or 1.

Item range on page p is from (p − 1) × size + 1 up to the smaller of p × size and the total. The final row of the table follows that rule: 42 × 25 would be 1,050, but only 1,037 exist.

How page size changes page count and latency

Page size trades the number of requests against the weight of each one. With 1,037 records the count moves a lot.

The timings are idealised, since larger pages take longer to build and send, and they hold memory on both sides. For a screen, the right size is what fits comfortably and loads quickly. For an export job, larger pages with a sensible cap are fine. Whatever you pick, enforce a maximum on the server so a client cannot request everything at once.

Edge cases that break pagers

• Zero results: ceil(0 ÷ 25) is 0 pages. Show an empty state, not a page 1 of 0.
• Exact multiples: 100 items at 25 per page is 4 pages, not 5. A formula that adds 1 before dividing will invent a blank page.
• Page size larger than the total: you still get 1 page.
• Requested page beyond the last: return an empty list or a clear error, not wrapped data.
• Changing page size mid-browse: convert the current offset to the new page size instead of keeping the page number.

Computing it safely in code

Floating point division usually works for page counts, but integer arithmetic is cleaner and avoids surprises in languages where division of integers truncates. Adding size − 1 before dividing turns truncation into rounding up.

Also validate inputs. Reject a page size of 0 to avoid a division by zero, and cap it so one request cannot ask for a million rows.

When page numbers are the wrong tool

Offset pagination makes the database count and skip rows, so deep pages get slower, and records inserted or deleted while someone browses can cause duplicates or gaps between pages. For feeds and big tables, cursor or keyset pagination, which asks for items after a given identifier, is steadier.

The trade-off is that cursors cannot jump straight to page 37 and often have no cheap total. If you do show a total page count, compute it from a count query and accept that it can be stale by the time the reader reaches the end. Quick checks with a pagination calculator help when you are verifying an API that returns only a total and a size.

What to show in the interface

The page numbers should serve the reader, who usually wants to know where they are and what is left. A summary such as Showing 1,026 to 1,037 of 1,037 is clearer than a bare page 42.

• Show a small window of page links around the current page, plus first and last, instead of all 42.
• Disable previous on page 1 and next on the final page.
• Where a total is expensive, fetch one more item than the page size to learn whether another page exists, and skip the count.
• Keep page and page size in the address so a result can be bookmarked or shared.

If an API returns the total in a header or field, treat it as a snapshot. Items can be added while someone browses, and the last page may change before they get there.

Boundary cases worth testing

Most pagination bugs live at the edges, so test the totals just either side of a page boundary. With a page size of 25, these are the answers a correct implementation gives.

The step from 25 to 26 and from 50 to 51 is where a rounding-down or add-one error shows up. Add checks for a page request below 1, above the last page, and a non-numeric value, and decide in advance what each returns: an error, an empty list or a redirect to the nearest valid page. Whatever you choose, apply it the same way across every list in the product, so that clients can rely on it.

One more consideration is consistency between client and server. If both compute the page count, make sure they use the same rule and the same source of the total, because a mismatch produces a final link that leads to an empty page. Where possible, let the server return the page count or a has-next flag and have the interface trust it, instead of repeating the arithmetic in several places.