Dev

Mock Pagination Response Generator

A mock pagination response generator solves one of the most common friction points in frontend development: building list views, data tables, and infinite scroll components before a real API exists. Instead of hardcoding dummy arrays or waiting on backend engineers, you can generate a complete, realistic JSON pagination response in seconds. The output includes all the metadata a real API would return — total item count, total pages, current page, page size, has_next, has_prev, next_page, prev_page, and from/to range indicators. Pagination logic is deceptively tricky to test. Edge cases like the last page returning fewer items than the page size, a single-page result set, or navigating to a page beyond the total range all behave differently. This generator handles those scenarios automatically, so you can validate your UI components against realistic data rather than discovering bugs after integration. Frontend developers can paste the generated JSON directly into mock service workers, JSON Server configs, or test fixtures. Backend developers can use it as a reference contract when designing REST or GraphQL pagination schemas. Technical writers get accurate, runnable examples for API documentation without needing a live environment. Configure three inputs — items per page, current page, and total items — and the generator computes every derived field for you. Change total items to 1 to test an empty-adjacent edge case, set current page past the last page to verify your error handling, or dial in a realistic 25-per-page product listing. The output is copy-paste ready JSON that drops straight into your development workflow.

How to Use

  1. Set 'Items per Page' to the page size your real API will use, such as 10, 25, or 50.
  2. Enter the 'Current Page' number you want to simulate, starting at 1 for the first page.
  3. Set 'Total Items' to your expected dataset size, including odd numbers to test partial last pages.
  4. Click Generate to produce a complete JSON response with all pagination metadata computed.
  5. Copy the output and paste it into your test fixture, MSW handler, or API documentation example.

Use Cases

  • •Populating a React Table or AG Grid component before API is ready
  • •Creating MSW (Mock Service Worker) handler responses for paginated endpoints
  • •Testing last-page behavior when item count doesn't divide evenly
  • •Generating JSON Server fixture files for local development mocking
  • •Writing Postman collection examples for paginated REST endpoints
  • •Validating infinite scroll trigger logic at the final page boundary
  • •Providing runnable code samples in API documentation for pagination
  • •QA testing a search results UI with one result versus hundreds

Tips

  • →Test page 1, a middle page, and the exact last page separately — UI bugs often appear only at boundaries.
  • →Use a total like 101 with page size 10 to force an 11-page scenario and quickly spot off-by-one errors in your page count display.
  • →If your framework uses 0-indexed pages internally, generate with page 1 and adjust the current_page value in your fixture before committing.
  • →Pair the generated JSON with MSW's runtime handler so different page parameters return different generated responses without maintaining multiple files.
  • →Set total items to 0 to generate an empty-state response and verify your UI shows the correct 'no results' message instead of broken pagination controls.
  • →Match your real API's field naming conventions — if your backend uses camelCase (totalPages vs total_pages), do a quick find-and-replace on the output before using it in tests.

FAQ

How do I mock a paginated API response for Jest or Vitest tests?

Generate a response with your desired page size, current page, and total items, then paste the JSON into a fixture file or inline it in your test. Import it as the mock return value for your API call. Because the metadata fields like total_pages and has_next are already computed, your test assertions can check pagination state without any extra setup logic.

What pagination fields does the generated JSON include?

The response includes data (an array of placeholder items), total_items, total_pages, current_page, page_size, has_next, has_prev, next_page, prev_page, from (first item index on this page), and to (last item index). These cover the fields most REST APIs and frontend pagination libraries expect, including React Query, SWR, and TanStack Query patterns.

How do I simulate the last page with a partial set of items?

Set total items to a number that doesn't divide evenly by your page size — for example, 97 items with 10 per page. Then set current page to 10. The generator returns only 7 items in the data array, sets has_next to false, and calculates the correct from/to range. This lets you test how your UI handles a shorter-than-expected final page.

Can I test what happens when current page exceeds total pages?

Yes. Enter a current page number higher than the computed total pages. The generator handles this edge case gracefully, which helps you confirm your frontend or API layer returns an appropriate empty or error response rather than crashing. This is a common integration bug caught too late without explicit edge-case testing.

Is this output compatible with JSON Server or MSW?

The output is plain JSON, so it works anywhere JSON is accepted. For MSW, wrap the generated object in a json() response handler. For JSON Server, paste the data array into your db.json file and configure pagination via query parameters. You may need to rename a field like total_items to total if your tooling expects a specific key.

What's the difference between from/to fields and page/pageSize fields?

Page and page_size describe the pagination parameters themselves. From and to are derived convenience fields showing the absolute item index range on the current page — for example, items 21 to 30 on page 3 of a 10-per-page result set. Many table UIs display 'Showing 21–30 of 97 results' directly from these fields without extra calculation.

Can I use this to mock cursor-based pagination?

This generator produces offset/page-number pagination, which is the most common pattern for REST APIs. Cursor-based pagination uses opaque tokens instead of page numbers and has a different metadata structure. If your API uses cursors, you'll need to adapt the output manually or look for a cursor-pagination-specific mock tool.

How many items appear in the data array of the response?

The data array contains exactly as many placeholder items as would appear on that page. For all pages except the last, that equals your page size. For the last page, it equals the remainder after dividing total items by page size. If total items is an exact multiple of page size, the last full page contains exactly page_size items.