Research - 8 min read
What a 5,000-Row Excel-to-PDF Test Taught Us
A measured QuickerConvert case study covering a 5,000-row workbook, a 267-page PDF, conversion timing, the timeout we found, and the limits of one test.
By QuickerConvert Team (organizational author) - Published
Large spreadsheets expose problems that a five-row demo never will. On July 18, 2026, we ran one publicly available sample workbook through QuickerConvert's Accurate local Excel-to-PDF workflow. The run produced a usable 267-page PDF, but it also revealed that the website's original six-minute browser deadline was shorter than the real end-to-end job. This case study records the fixture, device, timers, result, defect, and limits so the numbers are useful rather than promotional.
The fixture was verified before conversion
The source was file_example_XLSX_5000.xlsx from File Examples, whose sample downloads are provided for testing and demonstration at https://file-examples.com/. We inspected the workbook rather than trusting its filename. It contained one worksheet with used range A1:H5001: one header row, 5,000 data rows, eight columns, 40,007 non-empty cells, and no formulas. Its size was 188,887 bytes and its SHA-256 was 678B8763910394479084F263667D45FCF2B7E345BEF274CCFC1C7F8C5E36ADCD. We did not redistribute the workbook or use personal documents.
- Fixture: one legally usable public testing sample.
- Input: 5,000 data rows plus one header row, not 50,000 rows.
- Structure: eight columns and no formulas in the used range.
- Privacy: no customer, employee, or private user file was involved.
The test used one documented Windows setup
We tested on Windows build 10.0.26200 x64 with Chrome 150.0.7871.125, QuickerConvert local helper 0.1.8-dev, an Intel Core i5-10300H, eight logical processors, and about 23.8 GiB of RAM. Accurate mode sends the selected workbook to the QuickerConvert helper on the same device, receives the completed PDF back in the browser, and keeps the source workbook unchanged. These environment details matter because another processor, memory budget, office runtime, workbook, or browser build can change the result.
The output was large but usable
The resulting PDF contained 267 pages and was 11,140,873 bytes, about 10.63 MiB. We opened the output and confirmed that it was a readable PDF. That does not prove perfect cell-by-cell fidelity: a thorough layout study would need expected print areas, repeated headers, charts, formulas, merged cells, and side-by-side reference images. This fixture mainly tested a long tabular export and the reliability of returning a large result to the browser.
- Output page count: 267.
- Output size: 11,140,873 bytes, about 10.63 MiB.
- Observed result: the PDF opened and its pages were countable.
- Not measured: universal fidelity across all Excel features.
Two timers described two different parts of the job
The browser-observed interval ran from 18:16:38 to 18:23:37, approximately 6 minutes 59 seconds end to end. The helper log separately recorded 119,285 milliseconds, about 1 minute 59 seconds, for its engine phase. Queueing, preparation, transfer, browser polling, and final collection can sit outside that narrower event duration. Reporting only the shorter number would make the user experience look faster than it was; treating the wall time as pure conversion time would also be inaccurate.
- End-to-end observation answers: how long did the user wait?
- Helper event duration answers: how long did the recorded engine phase take?
- The measurements are both valid for their scopes, but they are not interchangeable.
The run exposed a real product defect
The website originally stopped waiting after six minutes. The local helper stayed healthy and finished the PDF at roughly 6 minutes 59 seconds, but the browser had already abandoned the request. That made a successful conversion look like a failure. We replaced the fixed deadline with progress-aware handling and a longer safety limit, then added regression coverage so an active helper can finish a long Accurate job. This is the most useful negative result from the test: successful engine work is not enough if the browser gives up first.
- Failure seen by the user: the browser timed out before collecting the result.
- What did not fail: the helper remained healthy and produced the PDF.
- Product response: progress-aware waiting, a longer safety limit, and timeout regression tests.
What this single run cannot tell you
This was one run of one simple workbook on one device. It is not a speed promise, a maximum-size claim, or proof that every formula, font, chart, print area, legacy XLS file, or damaged workbook will convert correctly. Accurate mode also depends on the supported Windows helper being available. Users should keep the original workbook, leave the tab open during long jobs, and review the first page, last page, repeated headers, page breaks, and any charts before sharing the PDF.
- Do not estimate another workbook's time by multiplying this result by row count.
- Complex layout can matter more than file size or row count.
- Review the exported PDF; conversion success is not the same as verified fidelity.
- Use Browser visual only when its appearance-first tradeoff fits the job.
Conclusion
This test did not prove that QuickerConvert handles every large workbook. It did something more useful: it found a timeout that made a completed conversion appear broken, documented the real waiting time, and produced a regression target. For a large Excel job, choose Accurate mode when layout matters, keep the tab open, and review the downloaded PDF before relying on it.