Product pages often state limits — “up to 25MB,” “up to 300 pages” — without anyone actually testing the boundary. We did, using NexKit’s Add Page Numbers tool, which publishes an unusually specific and testable claim: PDFs up to 25MB and up to 300 pages are accepted; password-protected PDFs, damaged PDFs, and oversized files are “rejected with a clear error.”
What we tested
Five generated fixtures, run through the live Add Page Numbers tool in a scripted browser session:
- A 299-page PDF (just under the stated limit)
- A 300-page PDF (exactly at the stated limit)
- A 301-page PDF (just over the stated limit)
- A password-protected PDF (AES-256 encrypted with qpdf, a real encrypted file, not a mislabeled one)
- A deliberately damaged PDF (a valid PDF truncated mid-stream, so it’s genuinely corrupt, not just renamed)
The page-count boundary held exactly where stated
The 299-page and 300-page files were both accepted. The tool correctly read and displayed the page count before processing (“This PDF has 300 pages”), processed both files successfully, and reported real output: 299 pages numbered 299 (2.1 MB output), 300 pages numbered 300 (2.11 MB output). Both completed in well under a second of processing time, with only two network requests recorded in either run — both GET requests for the tool’s own PDF-processing script and its worker file, not anything resembling a file upload.
The 301-page file was rejected before processing began, with this exact on-screen message: “This PDF has too many pages for this MVP. Please use a PDF with 300 pages or fewer.” The boundary is exactly where the product page says it is — 300 pages accepted, 301 rejected, with a specific and accurate error rather than a generic failure.
Password-protected and damaged files were both rejected, each with a distinct message
Our AES-256-encrypted test file was rejected immediately with: “Password-protected or encrypted PDFs are not supported yet.” Our deliberately truncated (corrupt) file was rejected with a different, appropriately hedged message: “This PDF may be encrypted, damaged, or unsupported and cannot be edited in your browser.” Both matched the product page’s claim of clear-error rejection, and neither one was silently accepted or produced a broken output — they were stopped before the processing step even became available.
What we did not test
We tested the page-count boundary precisely (299/300/301 pages). We did not, in this round, generate and test a file at the exact 25MB byte-size boundary — that would require a different fixture-generation approach to hit a precise byte target, which we’re flagging as follow-up work rather than skipping silently. Nothing in this article should be read as confirming the size limit as rigorously as the page-count limit.
Known limitations
- This tests one tool (Add Page Numbers) under one set of conditions (desktop Chromium, production, 2026-08-01).
- The size-in-MB boundary was not tested in this round, only the page-count boundary.
- We did not test every possible malformed-PDF scenario — only one specific truncation method for “damaged” and one specific encryption method for “password-protected.”
Bottom line
For the specific claims tested — the 300-page limit and the password-protected/damaged rejection behavior — NexKit’s Add Page Numbers tool did exactly what its own product page says it does, with clear, specific error messages rather than silent failures or generic errors. The 25MB size boundary remains untested and is a natural next step.
Related tools: Add Page Numbers · Full methodology