"Best JavaScript PDF library" has no answer, because the six most-recommended options do six different jobs. Most bad choices come from picking on GitHub stars rather than on task. This page sorts them by what you are trying to do, and says where Polotno fits and where it does not.
Start with the verb, not the library
Displaying a PDF
pdf.js. Mozilla's renderer, the engine inside Firefox's viewer, and the basis of nearly every in-browser viewer including the parsing layer in Polotno's own importer. If the job is "show a document to a user", stop here.
Modifying an existing PDF
pdf-lib. Edits at the document-object level, so form fields, bookmarks, and internal links survive. The right pick when the input file's structure must be preserved. See the detailed comparison.
Drawing a PDF from code
PDFKit for Node, jsPDF for the browser. Imperative drawing APIs. Ideal when a developer owns a fixed layout that comes out of data and never passes a designer. See the PDFKit comparison.
Turning HTML into a PDF
Puppeteer, or wkhtmltopdf and WeasyPrint outside Node. The right answer when you are capturing a real page or rendering flowing text you already maintain as HTML. See the Puppeteer comparison.
Letting users design a document
Polotno SDK. A visual editor plus a JSON schema that imports and exports PDF. The pick when a non-developer authors the layout, or when your users edit documents inside your product. See PDF SDK.
Viewing with annotation and forms
PSPDFKit or Apryse. Commercial document platforms with annotation, AcroForms, signatures, redaction, and native mobile SDKs. Nothing open source covers that surface properly.
The distinction people get wrong most often
Generating a PDF and editing a PDF are not the same problem, and most of the confusion in this category comes from treating them as one.
Generating means producing a document from data. PDFKit, jsPDF, Puppeteer, and Polotno all do it, and they differ on who writes the layout: a developer in code, a developer in HTML, or anyone in an editor.
Editing means opening a file someone else made and changing it. pdf-lib does it structurally, preserving what was there. Polotno does it visually, by reinterpreting the page as a design. Those produce different results and neither is a substitute for the other.
Where Polotno does not fit
Worth being direct, because the list is short and specific:
- No OCR. A scanned document imports as images with no text to edit.
- No AcroForm support. Interactive fields are not parsed.
- No annotation layer. No comments, highlights, or markup.
- No certified redaction. Deleting an element is an edit, not a compliance operation.
- No HTML input. It renders its own schema, not arbitrary markup.
- JavaScript and TypeScript only. No Java, .NET, or Python bindings.
If any of those is a requirement, one of the other libraries on this page is your answer.
A quick decision path
- Do users need to see a PDF? → pdf.js
- Do users need to annotate or sign it? → PSPDFKit or Apryse
- Do you need an existing file's structure intact? → pdf-lib
- Is the layout fixed and developer-owned? → PDFKit or jsPDF
- Is the source genuinely HTML? → Puppeteer
- Does a non-developer own the design, or do your users edit it? → Polotno
FAQ
Which library is most popular?
pdf.js and jsPDF by downloads, but popularity tracks how common the job is, not how well any of them fits yours. jsPDF is widely used partly because it is the first result for "generate PDF javascript", not because it is the best pick for every case.
Can one library do everything?
No. Apryse comes closest and is priced accordingly. Most products end up with two: one for viewing or structural work, one for generating.
Are the open-source ones production ready?
pdf.js, pdf-lib, and PDFKit are all mature and widely deployed. The gaps are in features they never set out to have, not in stability.
Where does Polotno's PDF support come from?
@polotno/pdf-import is built on pdf.js for parsing, and @polotno/pdf-export writes vector PDF including PDF/X. See PDF import and PDF export.
