When a tool has a maximum file count, file size, or page total, that limit is part of its user interface. It determines whether a workflow succeeds, so people should see it before they select and arrange files.
The public ZANCTA Merge PDF page states three limits: up to 50 PDFs, 200 total pages, and 50 MB per file. Those numbers are useful only if the interface and the processing path agree. A label that says “50 files” while the validation rejects the 50th file is a bug; a limit hidden in a tooltip is a surprise.
Test the boundary, one rule at a time
For a maximum of N, test N − 1, N, and N + 1. For a merge tool, that means checking 49, 50, and 51 files, then doing the same around the total-page and per-file-size caps. Keep each test focused on one constraint first so the failure points to the rule that broke.
Then test combinations: for example, a valid file count whose pages exceed the total, and a file that is too large even though the overall page count is small. Include awkward inputs such as encrypted or damaged PDFs as separate cases; they are different failure modes and should not be reported as “limit exceeded.”
Make rejection recoverable
A useful limit message tells the user what was selected, what the cap is, and what to do next. “You selected 51 files; this tool accepts up to 50” gives a clear repair. Preserve the current selection when possible, so removing one file does not force the user to start again.
Finally, check that the order shown in the interface matches the order in the exported PDF. A workflow can satisfy every numeric limit and still produce the wrong result if its ordering changes silently.
The same boundary tests work for uploads, batch jobs, and API payloads: test just below, at, and just above every documented cap, then verify the error and recovery path.
Which limit or edge case has surprised you most in a file workflow?
