Comparison
PDFops vs pdf-lib
pdf-lib is one of the most-downloaded PDF libraries in the JavaScript ecosystem — ~10.25M downloads/week on npm — and it has been effectively unmaintained since 2021, with roughly 279 issues sitting open. That's a confusing combination: massive adoption, dead upstream. This page is the honest answer to “pdf-lib is unmaintained, what now” — real maintained forks if you need to stay in-process, and where a hosted, deterministic PDFops API fits a narrower job instead.
The honest framing
pdf-lib's download count is a legacy signal, not a maintenance signal. The library (MIT, free, in-process) was the default recommendation for years, and most of that traffic is projects that adopted it while it was active or are still on it because the PDF spec hasn't moved and the code still runs. The repo itself hasn't shipped a real release since 2021, and ~279 open issues — bugs, edge-cases, feature requests — sit without maintainer response.
That doesn't make pdf-lib broken for every use case; it means new bugs, security reports, and PDF edge-cases you hit won't get fixed upstream. Whether that matters depends on what you're doing with it.
PDFops isn't a pdf-lib replacement the way a fork is — it's a different shape entirely. In-process library vs. hosted API is a real trade-off, not a strict upgrade in either direction. A library keeps everything in your process: no network dependency, no third party in the trust chain, full control. A hosted API keeps a PDF-manipulation library and its font/parser edge cases out of your bundle and your maintenance burden, at the cost of a network round-trip and trusting someone else's runtime. If you need arbitrary in-process PDF construction, pick a maintained library — see below. If your job is narrower — fill an AcroForm template, merge PDFs, or generate an invoice, deterministically, from an edge or serverless function — that's what PDFops does.
If you just need a maintained pdf-lib
Not every pdf-lib user needs to change shape. If the in-process library model is right for your app and you just want it kept alive, these are the honest options — evaluated purely as pdf-lib alternatives, not as arguments against them:
- @cantoo/pdf-lib (~388k downloads/week) — the most-downloaded active fork, close to a drop-in replacement for the original API. It's also what PDFops itself runs on internally: our fill, merge, and invoice engines are built on
@cantoo/pdf-libunder the hood. - @pdfme/pdf-lib (~209k downloads/week) — maintained by the pdfme project, used inside their own PDF-generation tooling.
- LibPDF by Documenso (~98k downloads/week) — a newer, clean-room successor rather than a fork, built to move past pdf-lib's internals instead of patching around them.
Any of the three is a reasonable answer if an in-process library is still what you need. None of them need PDFops to be a fit — they solve a different problem than the one PDFops solves.
Side-by-side
| PDFops | pdf-lib | |
|---|---|---|
| Primitive | Hosted HTTP API: fill-form, merge, inspect, invoice | In-process JS library: build & manipulate PDFs in your own code |
| Shape | Network call, returns PDF bytes | npm install, runs inside your process |
| License / access | Free tier + paid API keys | MIT, free |
| Weekly npm downloads | n/a — not an npm package | ~10.25M/week |
| Maintenance | Actively developed | Effectively unmaintained since 2021 |
| Open issues | — | ~279 open, no maintainer response |
| Determinism | Byte-identical output (same sha256), incl. flatten=true | Not guaranteed — depends on your code |
| Cold-start / bundle cost | Zero — no PDF lib in your function | 1MB+ added to your edge/serverless bundle |
| Font & parser maintenance | PDFops's responsibility | Yours — and pdf-lib's own bugs go unfixed |
| Network dependency | Yes — HTTP round-trip | No — runs in-process |
| Free tier | 250/mo with a free key (no card); 100 req/IP/month keyless | Free (MIT), unlimited local use |
| SDK / ecosystem | pdfops-sdk (TS), pdfops-mcp (MCP server), n8n-nodes-pdfops | Raw library API only |
| Best for | Deterministic fill/merge/invoice from edge or serverless, zero maintenance burden | Arbitrary in-process PDF construction, no network dependency |
pdf-lib and fork download/issue figures per npm and GitHub as of 2026-07-30. PDFops pricing is live at /pricing.
If the hosted primitive fits, try it in 30 seconds
Drop a form PDF into the Form-Field Inspector to see its AcroForm fields and the exact call. The fill shape is one HTTP request:
curl -X POST https://pdfops.dev/api/fill-form \
-F "pdf=@template.pdf" \
-F 'fields={"customer_name":"Acme Co","total":"$1,250.00"}' \
-F "flatten=true" \
-o filled.pdfNo API key needed for the first 100 calls per IP each month — or skip the terminal and run the same call in the playground. flatten=true bakes the values into the page content and drops the AcroForm; output is still byte-identical for identical input (same sha256), so you can hash-compare in CI or use it as a cache key. Full parameter reference in the fill-form docs (full API surface at /docs); the pdfops-sdk npm package, the pdfops-mcp MCP server, and the n8n-nodes-pdfops n8n node wrap the same endpoints if you'd rather not hand-roll the HTTP calls.
Frequently asked
Is pdf-lib actually unmaintained?
Yes, functionally. ~10.25M downloads/week on npm, but no real release since 2021 and ~279 open issues with no maintainer response. The download count is a legacy-adoption signal, not a vote of active support — new bugs and PDF edge-cases go unaddressed upstream.
What should I use instead of pdf-lib for in-process work?
If you just need it maintained: @cantoo/pdf-lib (~388k downloads/week) and @pdfme/pdf-lib (~209k downloads/week) are the established maintained forks, largely API-compatible with the original. Documenso's LibPDF (~98k downloads/week) is a newer clean-room successor. All three are legitimate answers if an in-process library is what you need.
Is PDFops a drop-in replacement for pdf-lib?
No. pdf-lib and its forks run in-process, no network call; PDFops is a hosted HTTP API. If you need in-process PDF construction, a library (see above) is still the right shape. PDFops fits a narrower job — fill AcroForm fields, merge PDFs, generate invoices, deterministically — from a function that doesn't want a PDF library in its bundle.
Why use a hosted API instead of an in-process library?
Zero cold-start-size cost (no 1MB+ library in your function bundle) and no font/parser maintenance on your side. In exchange: a network round-trip, and trusting PDFops's runtime instead of code you can read. Worth it for template-fill and merge jobs from edge functions; not for heavy in-process document construction.
Does PDFops guarantee byte-identical output?
Yes — identical input to /api/fill-form or /api/merge produces the same sha256 output every time, including with flatten=true. No wall-clock timestamps or non-deterministic metadata get stamped in. pdf-lib and its forks don't guarantee this natively; it depends on how you use them.
Move when ready
If the deterministic fill + merge primitive matches your usage, grab a free API key (250 req/mo) at /pricing — email in, key out, no card. Indie ($16/mo, 4,000 calls) and Pro ($79/mo, 25,000) are live when you outgrow it.