PDF SDK Evaluation Checklist

You’re ready to add PDF functionality to your software and your team is undertaking technical due diligence⁠ — analyzing a PDF SDK checklist to ensure you get the best solution for your organization.

Evaluating a PDF SDK before you buy is harder than it seems, and many customers end up regretting their first choice despite the due diligence step. According to 2019 market research by global management consulting firm Stax Inc., 70% of the customers of most leading PDF SDKs expressed an interest in switching SDKs despite the high costs of doing so.

PDF SDKs are indeed challenging to tell apart at the surface; vendors seem to support the same core features, such as viewing and annotating PDFs. And there is little guidance to help you navigate between competing vendor claims.

In this post, we spotlight areas of difference so you avoid choosing a PDF SDK that isn't a good fit, which may force your organization to switch libraries later at signficant cost. Switching is non-trivial: developers have to re-learn the new library, re-adjust the backend, customize the UI to match what users are accustomed to, as well as migrate documents, form data, annotations, and more.

This post offers 10 criteria you can add when evaluating your PDF SDK checklist.

Bottom line:

Your future PDF SDK must provide your business with the flexibility and control required to create powerful PDF-based applications without compromising on quality or security standards. It is constantly being updated and leverages innovative technologies, giving developers access to the latest features and APIs as soon as they are released. Your PDF SDK must scale cost effectively as you grow, while delivering best-in-class support.

Let's get started with the PDF SDK checklist.

A PDF SDK must be suitable for any size of business or project, able to evolve and scale up seamlessly and cost effectively with your business.

A first mistake organizations make when selecting their first PDF library is to assume fixed feature requirements.

Then, users begin asking for more functionality as they grow dependent upon a PDF SDK. You don't want to:

Instead, ensure all the functionality you'll ever need is available through a single partner who can enable seamless, long-term growth, including:

Keeping features integrated in a single application via a single vendor keeps the workflow streamlined and eliminates application and licensing sprawl.

End-users may also require more file formats and platforms as well as conversion options.

Check the following:

A professional PDF SDK should provide optimization and compression features such as PDF tiling, linearization, and parallelization to greatly improve performance. These technologies reduce file size and optimize files for faster retrieval times and better performance on mobile devices. This enhances file sharing and reduces user network data consumption. (Linearization is crucial for users who expect to tap into massive documents remotely from their mobile devices.)

Without these features, you might encounter behavior such as slow rendering and long wait times times for your users, as well as memory consumption and network data transfer issues. Document interactions such as scrolling and panning across, or zooming into content, may also become slow and frustrating.

Test the PDF SDK on your users’ preferred documents and processes, browsers, and devices. Try interacting heavily with documents: e.g., scroll to the middle, zoom in and out, and pan side to side repeatedly and in various places.

Also test the PDF SDK at a heavy usage and server load if it is server-based. Some solutions perform excellently on a small number of documents and users but impose unexpected hidden costs later when later scaled up. Doing a heavy test now may shed light on whether your PDF SDK can meet growth demands in the future.

Your PDF reader must be reliable. This means it must open all documents, always. Certain PDF documents are memory-intensive or may be corrupted, failing to open or crashing some viewers.

For your end users, a single document that fails to open at a critical time could mean the difference between success or failure. Users may abandon your app for third-party workarounds if it seems unreliable. (See our Construction Computer Software success story to learn more.)

When you test a PDF SDK, use a large body of documents that capture the variety of what your users expect to open, and include their most demanding documents, such as documents with very large file sizes (1GB+), complex graphics, or many pages (e.g., 1,000+).

(We tested JavaScript library PDF.js and found documents crashed or failed to open at rates of 1-3% with certain document subsets.)

Not all SDKs render PDFs the same way. Why? The PDF file format supports many fonts, embedded formats, languages, and graphics. And PDF files are generated in manifold ways by literally thousands of different tools.

Your business requires high-quality rendering. For certain industries, such as construction, architecture, and engineering, accuracy and precision are non-negotiable requirements.

Image quality may suffer at higher zoom factors when a lower-quality library renders content as raster images rather than as precise, scalable PDF vector.

Rendering errors may include text with the wrong font, spacing, and kerning, or colors that display without their true brightness or hue. Sometimes these issues are subtle; other times, they are dramatic:

Another consideration is that not all PDF viewers implement the full 1,000-plus-page PDF specification. And when a viewer encounters a PDF graphic or image compression type it does not support, it will not render content correctly or may not render content at all.

Don’t take a vendor’s claims that their SDK is mature and battle-tested at face value. Test the rendering engine yourself on your most demanding and largest documents to evaluate whether your documents render as expected, at any magnification.

(We went in-depth on rendering issues faced by popular open-source JavaScript library PDF.js.)

You may want to optimize the UX and streamline the UI to ensure end-user adoption (a critical factor in determining the success of an application).

An open-source UI provides the highest degree of freedom to change the UI and control the UX. With an open-source UI, you get greater early-stage visibility into what can you can improve and adjust. This is crucial if you have strict or specific UI requirements. You will also acquire far greater power overall to reskin UI components and change UI behavior, such as adding new annotation types and custom annotations.

If the UI is not open-source already, ask the vendor for access to their UI source code.

With a format as complex as PDF, you might need an experienced vendor capable of dealing with new edge cases and undocumented PDF behavior as they emerge.

Can the vendor quickly pinpoint where problems originate in the core rendering engine, and quickly resolve issues? How quickly, exactly? Or do they rely on an external third party (including open-source projects) to fix bugs for them?

If the vendor is a reseller or wraps an open-source library such as PDFium, they may not have the expertise to respond as decisively as a commercial vendor who built and therefore understands their SDK’s rendering engine from the ground up. This may explain why some PDF SDK vendors rank at a higher Net Promoter Score (NPS) than others.

A PDF SDK must be secure by design. It must ensure document security by using encryption capabilities to protect sensitive and confidential data from unauthorized access or misuse.

Generally, browser, iOS, Android, and UWP apps are sandboxed to prevent attackers from taking control over the entire device. But an attacker could still steal confidential data from within such as emails, SINs, banking information, and so on⁠ — or even documents.

In contrast to mobile apps, server-based and desktop applications are not sandboxed ⁠— so a malicious actor could take control over the device via a PDF SDK weakness.

Consider the level of security provided by a PDF SDK vendor:

OSS may allow a quick time to market, but the downside is greater security risks. Hackers search public repositories and issue trackers for easy-to-exploit vulnerabilities in solutions that have not updated embedded open-source components with known vulnerabilities. (For information about OSS risks, see a FOSSAware list of 2022 trends.)

Industries that contend with strict compliance requirements may not be able to consider solutions that include third-party servers.

Finally, more eyes on code is crucial to ensuring an SDK’s continued security and stability.

In a high-volume environment, automation features, such as automated form filling, OCR processing, AI-driven text extraction, and batch processing help your business scale and support Intelligent Document Processing (IDP) workflows.

Increasing volumes of documents and data in a highly competitive landscape push businesses to eliminate manual data processing from document-centric workflows and address data automation as part of their overall digital transformation strategy.

AI capabilities can help businesses collect, classify, categorize, and extract data trapped in stored PDFs and convert the data into a structured format such as JSON before sending it to downstream business-critical systems for analysis or reporting.

If you think your business may need to make better use of its data lake and empower users in the next 12-24 months, consider a PDF SDK solution that supports IDP features. If so, you won't be alone: the IDP market is projected to reach $6.8 billion by 2027.

You may need to consider whether the PDF SDK fully protects you against third-party legal claims.

Components with certain “copyleft” or dual open-source and commercial licenses introduce some risk and uncertainty. For example, a U.S. Federal Court ruled an open-source license is an enforceable contract in the case of Artifex (PDF SDK) v. Hancom.

If you are using open source directly, make sure you understand the limitations and permissions within the license. (An extensive list of OS/S licences and permissions is available.)

With a commercial PDF SDK, you may still encounter hidden licensing risks and uncertainties where the vendor embeds open-source software with unclear copyright and patent information. This uncertainty is the case for PDFium, originally developed by an independent company and later open-sourced by Google. The agreement between that vendor and Google is not public.

To protect yourself against third-party claims, ask the vendor for a complete list of:

Don't forget to perform due diligence on the vendor. For example, ask:

Finally, you'll need to go with a PDF SDK that fits your budget. Consider the cost of the PDF SDK relative to its features and performance. A cliche fits here: when it comes to PDF SDKs, you pretty much get what you pay for.

At the end of the day, your due diligence exercise is distilled into price point vs. all the considerations listed in this post.

With so many moving parts and potentially high stakes, a PDF SDK checklist and evaluation is challenging. We hope you'll have an easier time of it with the strategies and considerations presented in this post.

If you have any questions, please contact us. We’d also be happy to provide test files to help your evaluation.

The Apryse Developer Suite and low-code solutions provide comprehensive document processing tools that allow developers, enterprises, and small businesses alike to create, edit, and convert digital documents in their applications or company workflow.

Stax Inc. survey results found Apryse to have the highest Net Promoter Score and the lowest reported desire to switch among the five leading PDF SDK vendors.

Get started with your free Apryse trial today (no email required) and see the results yourself!