Brief: If you are looking to migrate from PDF.js, or if you’re just curious about other options, here are some of the best PDF.js alternatives to embed a PDF viewer in a website or an application.
PDF.js is proven to be one of the easiest ways developers can embed a PDF viewer in their software. But the JavaScript library is not suited to everyone, especially those with more advanced UX and document feature needs.
In this article, you’ll learn about some of the key reasons why developers consider switching from PDF.js and how these factors may impact your decision-making, as well as what other open-source, open-source wrappers, and commercial SDK options you can try.
First step: understanding why you want to switch
When evaluating an alternative to PDF.js, a good first step is to define what success looks like. This process typically starts by outlining the problems you are facing and what an expected solution will look like. From here you can define objectives and then work backwards to determine the steps needed to achieve your desired outcome.
But even when you go through this process, there can be some uncertainty about choosing the right alternative - what if there is a use case or factor you haven’t considered? Thankfully a recent survey gives us a bit more insight into why businesses and developers move away from PDF.js.
Top reasons organizations switch from PDF.js include:
- Adding new features
- Reliability & performance issues
- Rendering issues
- Adding additional file types
Adding new features to PDF Viewer
The most common reason developers move away from PDF.js is the challenge faced when trying to add more features or customizations on top of PDF.js. In the previously mentioned survey, over 71% of respondents attempted to add custom features to PDF.js but eventually abandoned their efforts because of the complexity of the PDF spec and the resource time required (learn more about the challenges of customizing PDF.js). The top 5 most common features attempted were:
- Annotations
- Signature
- Parsing & extraction
- Improved search
- Form filling
Adding custom features in a PDF.js viewer is no simple task. A good alternative to building and maintaining these features yourself would be to deploy PDF.js Express as your viewer. PDF.js Express wraps a customizable UI around the PDF.js rendering engine with 26 out-of-the-box annotations, form filling and e-signatures (see the demo). Keep in mind this solution provides the same performance and rendering accuracy as the vanilla PDF.js viewer.
Reliability issues
A recent benchmark shows that PDF.js opened 98.6% of PDFs found in the wild. For simple PDFs like invoices or text-based documents, you can expect near perfect reliability. If your workflows include MS Office documents and images, large architectural design or construction plans generated from CAD and BIM solutions, Engineering PDFs generated from Modelling Software or a topographic map with satellite raster backing, you can expect some reliability and performance issues (1-3% of documents failing to open).
Reliability can also be impacted by user behavior. If a user uploads or submits their own files into your workflow, you have likely experienced issues with corrupt PDFs (your viewer may throw an exception and close the document down). This scenario can be especially frustrating as your viewer is perceived as unreliable when in fact it is the user’s corrupt document that has caused the issue.
If reliability is a priority, then it’s important to look for an alternative viewer that has PDF tiling, linearization and parallelization to improve rendering performance. If your workflows encounter corrupt PDFs, look for a viewer that can repair document content on the fly.
Rendering Issues
10.5% of survey respondents cited PDF.js rendering issues as the main reason for looking for an alternative. In fact, 29% of open issues on GitHub for PDF.js are related to a PDF rendering feature. The cause for these rendering issues was recently investigated in a guide to evaluating PDF.js rendering, which outlines the key factors that result in poor rendering in the PDF.js viewer. Font conversion, image conversion, transparencies, patterns & gradients, OCG layers, color management & zoom are all listed as sources of rendering issues within PDF.js.
| Incorrect Rendering | Correct Rendering |
|---|---|
 |  |
In certain scenarios, rendering accuracy is especially important: for example -- measuring blueprints on a job site, collaborating on advertising / branding documents or printing to a particular specification. For these use cases, successfully finding an alternative viewer hinges on your ability to assess the underlying rendering engine. Start by asking if the rendering engine is built internally; some commercial solutions build features on top of open-source, where rendering accuracy will stay largely the same. In other situations, rendering occurs after converting to an image server side, resulting in fixed resolutions and mounting infrastructure costs.
A good practice when evaluating a rendering engine is to test a wide assortment of documents. Select a random assortment from your workflows (the more complex the documents, the better) and combine them with public test suite documents. You can find one such test suite released by the Ghent Workgroup, an international body of graphic designers supported by Adobe.
Adding additional file types
As your application grows, you can expect user requirements to increase in parallel. One of the most common requirements for document viewers is the ability to accept different file types - the most popular file types including MS Office (Word, Excel, PPT), image files (JPG, PNG, TIFF, etc) and in some cases CAD formats.
For a PDF.js, an option exists to use an external solution to convert different file types on-the-fly to PDF and then display them in the viewer. Alternatively you could go with an all-in-one viewer that handles both file conversion and viewing.
Key considerations when supporting additional file types:
- The cost and effort required to manage 2 separate solutions vs an all-in-one solution
- How accurately the solution converts file types to PDF
- Number of file types supported (important to meet future user requirements when scaling the application)
PDF.js Alternatives
When choosing a PDF.js alternative, you have three options to consider: open-source, open-source wrappers, and commercial SDKs.
Open-source alternative to PDF.js
PDFium
One solution developers might consider when evaluating alternatives to PDF.js is PDFium - Google’s native open source PDF library and Chrome’s PDF rendering engine. One important note is that PDFium does not provide out-of-the-box client-side rendering in a web app and to enable it requires significant developer resources.
When comparing PDF.js to PDFium, there has been some evidence that rendering performance and accuracy improve with PDFium. In 2017, Dropbox made the switch from PDF.js to a server-side PDFium solution. Their lead developer Jingsi Zhu explains the results:
“The render quality of PDFium surpasses PDF.js on many documents, especially those that use obscure PDF features.”
To gain these performance improvements, Dropbox was willing to allocate developer resources to building a custom PDFium viewer from scratch.This involved customizing text extraction and positioning in PDFium, which Jingsi Zhu noted was trickier than in PDF.js. For example, they encountered challenges accurately drawing text overlays, which required careful study of the PDF standard. To improve performance, they employed multiple optimization techniques, including techniques such as batching requests for metadata and text, rendering more pages than currently visible, and deferring text overlay rendering.
Another consideration when integrating PDFium is that it can be problematic for web applications. PDFium is a native library and the C++ code is required to be compiled into WebAssembly or Asm.js in order to render PDFs client-side, a massive undertaking.. If you are currently using pdf.js within a mobile app, switching to client-side PDFium solution would require integration of nearly 500,000 lines of native code into your solution/codebase.
PDFium has also had its share of security issues, with 88 major vulnerabilities reported within the Common Vulnerabilities and Exposures (CVE) database - roughly 1.5 new vulnerabilities each month.
These vulnerabilities are especially important if you use a commercial SDK that leverages PDFium. In this scenario, patching your application directly is not possible. Those who embed a library that uses PDFium in it will first have to wait on their vendor to update their library, and then update their code. Depending on the responsives of the SDK vendor and customer in patching their solutions, this can leave an organization and users exposed to possible attacks, potentially for months or even years at a time.
Commercial open-source wrappers
SDKs that wrap features around an open-source rendering engine:
PSPDFKit
Founded in 2011, PSPDFKit developed their solution around the PDFium open-source rendering engine. A fully remote company based in Austria, they provide a wide variety of features within a closed-source viewer that can be customized via API calls.
PDF.js Express
Launched in 2019, PDF.js Express wraps the PDF.js rendering engine around a customizable viewer. Key features include annotations, form filling and e-signatures (see full PDF.js vs PDF.js Express comparison). The viewer UI is open-source and allows unlimited customizability.
Commercial SDKs
SDKs that provide custom-built rendering engines:
PDFTron
Founded in 1998, PDFTron was recently ranked the top choice for those considering a commercial PDF SDK by Stax. Located in Vancouver, BC, PDFTron SDK offers a wide variety of features and cross-platform compatibility. The company has recently moved into the AI document analysis and recognition space. They also offer a free document application Xodo that has been downloaded over 11 million times on the Google Play Store.
Foxit
Founded in 2001, Foxit is a chinese-based company that offers a robust feature-set across a variety of platforms. The original developers of PDFium, Foxit worked with Google in 2014 to open-source their proprietary rendering engine. Along with the SDK, they currently have several B2C products including Phantom PDF, Studio Photo, and Foxit Reader.
Datalogics
Datalogics is an enterprise software company formed in 1967 and the official reseller of the Adobe PDF library. In 2010, Adobe selected Datalogics to resell the Adobe Reader Mobile SDK. Datalogics also offers a PDF Java Toolkit and a customized eReader (DL Reader) for iOS, Android, and Windows.
Conclusion
Finding the right PDF.js alternative is largely dependent on your needs and objectives. If you are primarily dealing with simple documents like invoices or receipts and need to add features like annotations, then PDF.js Express could be a good first step. If you have workflows with complex documents, require reliable and fast rendering, or need to support additional document file formats, then a commercial SDK might be your best option. If you are considering a commercial SDK, we've put toghether a how to choose a pdf.js alternative guide to help you with your evaluation.
