Total records in your dataset
Ready to calculate
Enter your values and click Calculate// compute page counts, offsets, and item ranges instantly
Calculate pagination values instantly: page counts, offsets, item ranges, and visible indexes for any dataset. Free browser-based tool for developers.
Ready to calculate
Enter your values and click CalculateInput the total number of records in your dataset (e.g. total rows from a database query).
Choose how many items to display per page, or use a quick preset button (5, 10, 25, 50, 100).
Enter the page number you want to inspect. Use the ◀ ▶ arrows to navigate, then copy results or SQL.
The Pagination Calculator computes all the values you need to implement pagination in any app — total pages, SQL OFFSET/LIMIT, visible item range, neighboring pages, and boolean flags like has_next and is_last_page. Works for any backend or frontend framework.
OFFSET = (current_page − 1) × items_per_page. For example, page 3 with 10 items per page gives OFFSET 20, meaning you skip the first 20 records and fetch the next 10.
The page window shows up to 5 neighboring page numbers centered around the current page. This is the standard "pagination widget" range — useful for rendering prev/next buttons in your UI.
The last page contains total_items mod items_per_page items — unless that value is 0, in which case the last page is full. The calculator shows this as "Items on Page" for whichever page you select.
This tool is designed for offset-based pagination (the most common type). Cursor-based pagination (used by some APIs) uses a cursor token instead of page numbers and doesn't rely on OFFSET values.
The tool outputs a standard SQL clause: SELECT * FROM table LIMIT N OFFSET M; where N is items_per_page and M is the calculated offset. This works with MySQL, PostgreSQL, SQLite, and MariaDB.
Yes — append ?api=1&total=500&per_page=25¤t=3 to the tool URL to get a JSON response with all pagination values. Perfect for testing or integrating into scripts.
A pagination calculator is a developer utility that computes all the numeric values required to implement pagination in a web application. Given a total item count, the number of items displayed per page, and a current page number, it derives every value you need: total page count, SQL OFFSET, LIMIT, the visible item range, neighboring page numbers, and boolean navigation flags like has_prev, has_next, is_first_page, and is_last_page.
Whether you are building a REST API, a server-side rendered web app, or a client-side table component, pagination logic is the same math under the hood. This tool eliminates mental arithmetic and reduces off-by-one errors that are easy to introduce when writing pagination by hand.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and assets — worth checking out.
Offset-based pagination is the most widely used strategy for paginating database results. The core formula is simple:
SELECT * FROM table LIMIT {per_page} OFFSET {offset};For example, if you have 243 records and display 25 per page, you get 10 total pages (⌈243/25⌉ = 10). On page 4, the offset is (4−1)×25 = 75, meaning you skip the first 75 records. The last page (page 10) will show only 243 − (9×25) = 18 items instead of the full 25.
Displaying an item range like "Showing 76–100 of 243 results" is a common UX pattern. The values are straightforward:
The min() is critical — without it, the last page would display an incorrect upper bound like "226–250" when there are only 243 items total.
Most pagination UIs don't show every page number — they show a "window" of a few pages around the current page, plus first and last. A common pattern is a window of 5 centered on the current page:
This tool computes that window automatically. When the current page is near the beginning or end, the window is clamped to valid page numbers rather than including page 0 or pages beyond the total.
Boolean flags are essential for rendering navigation controls correctly:
has_prev — true if current_page > 1 (show the "Previous" button)has_next — true if current_page < total_pages (show the "Next" button)is_first_page — true if current_page === 1is_last_page — true if current_page === total_pagesThese flags prevent rendering a disabled or broken "Previous" button on page 1, or a "Next" button on the final page. The calculator makes all four flags visible at a glance.
The SQL clause LIMIT N OFFSET M is supported by MySQL, PostgreSQL, SQLite, and MariaDB. In PostgreSQL you can also write FETCH FIRST N ROWS ONLY OFFSET M ROWS for ANSI-compliant syntax. Microsoft SQL Server uses OFFSET M ROWS FETCH NEXT N ROWS ONLY inside an ORDER BY clause.
Always include an ORDER BY when paginating — without a deterministic sort order, the same offset can return different rows across queries, leading to duplicate or missing items in paginated results.
For large datasets (millions of rows), high OFFSET values become slow because the database must scan and discard all rows before the offset. If you paginate deeply, consider keyset (cursor) pagination instead: store the last seen ID and query WHERE id > last_id LIMIT N for O(1) performance regardless of page depth. For most applications under a few hundred thousand rows, OFFSET-based pagination is perfectly efficient with proper indexing.