jsPDF

jsPDF lets you build PDF documents entirely in JavaScript, without a server round-trip. It covers the core primitives needed for real documents — text with custom fonts and Unicode/TTF embedding, vector shapes, images (JPEG, PNG, WebP, BMP, GIF), tables, and outlines — and runs equally well in the browser or under Node.js, switching automatically between file-system and browser APIs.

Originally MrRio’s project, jsPDF is now co-maintained with the yWorks fork, which added an “advanced” API mode alongside the original “compat” mode. Advanced mode unlocks patterns, transformation matrices, and FormObjects for more sophisticated layouts, while compat mode preserves full backward compatibility with the large ecosystem of existing jsPDF plugins. A companion html method (backed by optional html2canvas/dompurify dependencies) renders arbitrary DOM content straight into a PDF page.

What You Get

• A jsPDF class with methods for text, lines, shapes, images, and page management, usable identically in the browser and Node.js
• Support for embedding custom TrueType fonts and Unicode glyphs via a bundled fontconverter tool
• Built-in decoders for JPEG, PNG, WebP, BMP, and GIF so images can be dropped straight into a document
• An html() method that renders live DOM content to PDF using the optional html2canvas/dompurify dependencies
• Dual API modes — a backward-compatible “compat” API and an “advanced” API with patterns, FormObjects, and transformation matrices
• TypeScript typings, AcroForm support, and plugin points (annotations, outlines, viewer preferences) for extending core functionality

Common Use Cases

• Generating downloadable invoices, receipts, or reports directly in the browser with no backend PDF service
• Exporting user-created content (forms, certificates, tickets) to PDF from a web app
• Producing printable documents from an existing HTML page via the html() renderer
• Building PDF export features in Node.js server routes without a headless-browser dependency
• Embedding custom fonts and non-Latin scripts (e.g. Arabic, CJK) into generated documents

Under The Hood

Architecture The core is a single large class defined in the main source file that composes behavior from a directory of independently loadable feature modules (acroform, add-image, annotations, canvas, cell, context2d, html, SVG, outline, viewer preferences, and more), each extending the core instance through an internal plugin-registration mechanism rather than formal dependency injection. A lightweight PubSub-style event system mediates cross-module hooks such as page-added or font-set events, and rendering state (fonts, page, transformation matrices, output buffer) is threaded through closures captured by the returned API object. The split between “compat” and “advanced” API surfaces is implemented by swapping which method set is exposed at runtime, so changes to the core PDF-writing primitives would ripple through nearly every module, since they all call back into the same instance’s shared internal helpers.

Tech Stack Written in plain JavaScript (hand-written TypeScript typings are shipped separately rather than compiled from TS source), built with a modern bundler and transpiler to produce ES, UMD, and Node-targeted output plus polyfill bundles for older browsers. Runtime dependencies are kept minimal — a small compression helper and a PNG decoder — while heavier capabilities like HTML rendering, sanitization, SVG rasterization, and legacy-browser polyfills are pulled in only as optional dependencies so consuming bundlers can tree-shake what isn’t used. Tests run against multiple browser targets plus a Node target, and CI runs a browser suite, a multi-version Node matrix, and a separate TypeScript-typings compatibility matrix.

Code Quality An extensive spec suite covers the majority of feature modules (image handling, canvas/context2d rendering in several variants, encryption, forms, annotations, and more), so this is a genuinely tested codebase rather than an untested one. Error handling favors plain thrown errors for invalid arguments over typed or result-style errors, consistent with the plain-JavaScript (not TypeScript) implementation, and a caught-and-logged path exists for internal event-dispatch failures. Linting and formatting are configured and enforced, and module naming is consistent with the feature each file implements, though the core file itself is very large and mixes many concerns rather than being split further.

What Makes It Unique The public API is intentionally low-ceremony — construct once, then chain calls to add text, shapes, and images — and this ergonomic default has stayed stable for years, which is a major part of the library’s appeal versus alternatives that require a build pipeline or server round-trip. Its clearest differentiator versus other JavaScript PDF libraries is the dual compat/advanced API design, letting the long-running plugin ecosystem built on the original API keep working unmodified while newer code opts into more powerful primitives (patterns, transformation matrices, form objects) merged in from a parallel fork — a deliberate technical choice to avoid a breaking-change split, rather than a novel PDF-generation technique in itself.