Jacob Collins Jacob is a Java developer and the product manager of JPedal

Testing PDF Merging: Performance and Content Integrity

2 min read

(PDF logo)

We’ve been making progress on improving our PDF merge tool JPedal (JPedal is the best Java PDF library for developers), and I was curious to run some tests in order to see how well it does against alternatives. The merging tool is capable of merging entire documents, including large files.

How We Tested the PDF Merge Output

We ran these comparison tests on our sample files, you can replicate using your own files.

One of the techniques I use during testing involves Adobe Reader. If Adobe Reader prompts a save dialog immediately upon opening a file (even if no changes were made), it’s usually a sign that the file has underlying issues—often related to structure or validity.

While this isn’t a definitive check, it serves as a practical early warning system for detecting problematic output files.

The goal is to ensure that our merged PDFs open seamlessly across all standard PDF viewers without triggering repair prompts.

First Test: Large Document

In the first test case, I aimed to evaluate how well each tool could handle merging an extremely large document—specifically merged with itself to create a 265,000-page PDF.

This test was focused entirely on performance: processing time, memory usage, and whether the tool could successfully generate an output file.

iText 9 failed to complete the merge, and ran for 2 minutes before experiencing an memory error. It ended up using up to 4GB of memory and failed to produce an output file.

JPedal handled the task reliably, completing the merge in 5 minutes and 20 seconds. It used a relatively modest 1.8GB of memory and successfully produced an output file. This makes it the only tool in the test to complete the merge without crashing or running out of memory.

PDFBox completed its run in 5 minutes and 44 seconds, which was comparable to JPedal in terms of speed. However, it also suffered from a memory error, reaching around 4.2GB of memory usage, and ultimately did not create an output file.

PDFSam was the slowest, taking 11 minutes before encountering a memory-related failure. It consumed 5GB of memory, and like iText, was unable to generate an output file.

 

ToolDurationMemory UsageResultNotes
JPedal5:201.8GB✅ SuccessSuccessfully completed merge
iText 92:004GB❌ Memory ErrorFailed before creating output
PDFSam11:005GB❌ Memory ErrorFailed during processing
PDFBox5:444.2GB❌ Memory ErrorFailed during processing

 

Second Test: Content Focused

The second test was based on the integrity of the content and how well the merge process took place from a content perspective. This would help us better understand the quality of the merge using different alternatives.

I merged a 39 page document with no form fields with a single page document with multiple form fields having a total of 40 pages. The test helped understand how different software handled form fields specifically when merging documents.

First on the list was iText 9 which resulted in the files being merged. However some of the form fields were not visible and appeared to have a clickable area but didn’t do anything.

Adobe asked if the file should be saved which further indicated there were issues with the output.

itext9 Merge
Second we tested on JPedal, where the documents were successfully merged. All the pages and forms were visible and interacted normally.

Adobe asked if the file should be saved, however during testing there were no issues reported with appearance and functionality.

JPedal Merge
Next was PDFSam, the forms page was merged successfully; however, there is an issue where a specific form remains hidden unless its value is updated. Additionally, if another value is updated, the form disappears entirely.

The original files did not behave this way and Adobe did not ask for the file to be saved, which would indicate the fields were considered broken by Adobe Readers.


Lastly with PDFBox the pages and forms were merged with no noticeable problems. The open action seems to have been affected by the merge however.

The resulting document’s open action made it open on page 40, this was due to the original document being 1 page. This would not be desired once merging large files, as user would find hard to maintain context.

JPedal Merge

 

Conclusion

In our testing of the PDF merge feature, JPedal was the only tool to complete both the large-scale merge and the form-based content test without major issues. Other tools showed strengths in speed or basic merging but encountered memory errors or problems with form functionality and document structure.



The JPedal PDF library allows you to solve these problems in Java


Jacob Collins Jacob is a Java developer and the product manager of JPedal