The pdfmake npm package is broadly safe to use, but its risk is concentrated in two places: a fragile transitive dependency chain and any server endpoint that turns user input into a document definition. If you generate PDFs entirely from data you control, pdfmake is a solid, well-maintained choice. The moment untrusted input reaches the document definition object, or you expose a generic /pdf endpoint, the calculus changes. This review covers what npm pdfmake gives you, where the sharp edges are, and how to use it without opening a hole.
What pdfmake Does
pdfmake is a declarative PDF document generation library that works both in the browser and in Node.js. You describe a document as a JavaScript object, an array of content blocks with styles, tables, images, and layout hints, and pdfmake renders it to a PDF. Its declarative model is what makes it popular: you are not drawing on a canvas, you are describing structure.
Snyk's package health signals rate pdfmake's maintenance as healthy based on release cadence and repository activity. So this is not an abandoned project. The security story is less about pdfmake's own code and more about what it depends on and how you wire it up.
The Dependency Chain Problem
pdfmake has historically pulled in a chain worth understanding: linebreak depends on brfs, which depends on static-module, which depends on static-eval. That static-eval package has carried open issues around evaluating expressions, and the whole chain exists to inline files at build time. For most users this chain is inert at runtime, but it shows up in audits and it is the kind of deep transitive dependency that teams miss until a scanner surfaces it.
This is a good example of why looking only at your direct dependencies is misleading. You installed pdfmake; you did not knowingly install static-eval four levels down. Running a dependency-tree audit makes the picture concrete:
npm ls static-eval
npm why brfs
npm audit --omit=dev
Software composition analysis is built for exactly this transitive visibility. A tool like Safeguard resolves the full graph and tells you which deep dependency introduced an advisory, rather than leaving you to trace it by hand.
Server-Side Code Injection Is the Real Danger
The most serious pdfmake-related security reports involve server deployments that accept a document definition over HTTP. One advisory described a scenario where a crafted POST request to a /pdf path could lead to arbitrary code execution, because the document definition was being evaluated with attacker-controlled content.
The root cause is not really pdfmake; it is the anti-pattern of treating a document definition as trusted code. A pdfmake document object can contain functions in places like table layout callbacks and page headers. If your server accepts a JSON body and passes it into pdfmake, and anywhere in your pipeline that JSON is deserialized in a way that can produce executable functions or you eval a template string to build it, you have handed the attacker a code path.
The fix is architectural. Never build a document definition by evaluating user-supplied strings. Accept structured data from the client (a list of line items, a customer name), then assemble the document definition on the server from your own trusted templates:
// Safe: user data fills a server-owned template
function buildInvoice(data) {
return {
content: [
{ text: 'Invoice', style: 'header' },
{ text: `Customer: ${sanitize(data.customerName)}` },
{ table: { body: data.lineItems.map(safeRow) } }
],
styles: { header: { fontSize: 18, bold: true } }
};
}
The user never controls the shape of the definition, only the values that land in known fields, and every value is sanitized before it goes in.
Additional Hardening
Cap document size and complexity. A request that asks for a hundred thousand table rows is a denial-of-service vector; enforce limits before rendering.
Run generation off the request thread. PDF rendering is CPU-heavy. Push it to a worker or a queue so a large or malicious job cannot stall your event loop.
Escape values that render as text. pdfmake handles text as data, which helps, but any value that comes from a user should still be validated for length and content, especially if it also flows into filenames or logs.
Pin and monitor. Lock pdfmake to a known version, and re-run your audit on a schedule so a newly disclosed advisory in that deep dependency chain does not sit unnoticed. Continuous scanning matters more than a one-time review, which is a theme we return to in our broader take on securing npm dependencies.
Should You Use pdfmake?
For most applications, yes. It is maintained, it has a clean declarative API, and its own code is not the problem. Use it confidently for generating documents from server-controlled data. Be deliberate about the two risk areas: audit the transitive chain so you know what you are shipping, and never let untrusted input define the document structure. Handle those and pdfmake npm is a dependable part of your stack.
FAQ
Is pdfmake npm safe for server-side PDF generation?
Yes, as long as you build the document definition from your own templates and never evaluate user-supplied strings into it. The reported code-execution issues stem from exposing a generic endpoint that treats client input as an executable document definition.
What is the static-eval concern in pdfmake?
pdfmake's dependency chain has historically included static-eval several levels deep via linebreak and brfs. It is largely a build-time concern rather than a runtime one, but it appears in audits, which is why full transitive dependency scanning is worth doing.
How do I generate PDFs from user input safely?
Accept structured data, not a document definition. Validate and sanitize each field, then insert those values into a server-owned template. This keeps the document's structure entirely under your control.
Is pdfmake actively maintained?
Yes. Package health signals rate its maintenance as healthy based on release cadence and repository activity, so it continues to receive updates.