Convert DOCX to PDF in Node.js: JavaScript options compared

To convert DOCX to PDF in Node.js, first decide whether you are converting an existing Word file or generating a new document. Existing DOCX conversion usually needs LibreOffice, Gotenberg, a commercial SDK, or a hosted API because JavaScript does not include a Word-compatible layout engine. If your app owns the content, the cleaner path is to generate DOCX and PDF from the same JSON schema and skip conversion entirely.

There is no reliable free pure-JavaScript DOCX-to-PDF converter because DOCX is not just data. It is a Word layout format with section breaks, table sizing, header/footer rules, floating objects, fonts, and pagination. Rendering that accurately requires a document layout engine.

DOCX to PDF options in Node.js

Option 1: LibreOffice headless

LibreOffice is the common free answer because it contains a real Word-compatible layout engine. Node wrappers such as libreoffice-convert call the installed binary and return a PDF buffer.

import { convert } from "libreoffice-convert";
import { readFileSync, writeFileSync } from "node:fs";
import { promisify } from "node:util";

const convertAsync = promisify(convert);
const docx = readFileSync("invoice.docx");
const pdf = await convertAsync(docx, ".pdf", undefined);
writeFileSync("invoice.pdf", pdf);

This is the right starting point when you have user-uploaded Word files and need a free path. The cost is operational: you must install LibreOffice, ship a large container, manage process failures, pin versions, and test fidelity after upgrades.

Option 2: Gotenberg as a conversion service

Gotenberg packages LibreOffice and Chromium behind an HTTP API. Your Node.js app sends the DOCX to a sidecar or separate service and receives a PDF.

That separation is useful. Your application container stays smaller, the conversion runtime is isolated, and you can scale document conversion separately from web traffic.

Use Gotenberg when you want the LibreOffice fidelity path but do not want to invoke a local binary from every application process.

Option 3: Commercial DOCX-to-PDF SDKs

Commercial SDKs such as Nutrient, Apryse, and Aspose.Words maintain their own conversion engines or packaged runtimes. They are usually the strongest fit when document fidelity, support, PDF/A, compliance, or enterprise procurement matter more than library cost.

They also bring real constraints: licensing, native dependencies, deployment size, and vendor-specific APIs. For regulated or high-volume conversion, those tradeoffs can be worth it. For a small serverless feature, they may be too heavy.

Option 4: Hosted conversion APIs

Hosted APIs such as ConvertAPI, CloudConvert, Adobe PDF Services, or a hosted Gotenberg provider let your app convert DOCX to PDF without local binaries.

This is often the simplest serverless answer. It works from Vercel, Lambda, or a background job, and the provider owns the conversion runtime. The tradeoffs are privacy, latency, availability, and per-document cost. If the DOCX contains customer data, review data-processing terms before sending files out of your infrastructure.

Option 5: Skip conversion and generate DOCX plus PDF

If the document is generated by your app, conversion may be the wrong abstraction. Do not generate a DOCX and then ask another engine to reinterpret it as PDF. Generate both formats from the same source schema.

import { generate as toDocx } from "@runstamp/docx";
import { generate as toPdf } from "@runstamp/pdf";
import { writeFileSync } from "node:fs";

const report = {
  meta: { title: "Q3 Revenue Report" },
  pages: [{
    elements: [
      { type: "text", value: "Q3 Revenue Report", style: { fontSize: 24, bold: true } },
      {
        type: "table",
        headers: ["Region", "Revenue"],
        rows: [["North America", "$4.2M"], ["EMEA", "$3.1M"]]
      }
    ]
  }]
};

writeFileSync("report.docx", await toDocx(report));
writeFileSync("report.pdf", await toPdf(report));

This works for invoices, reports, statements, certificates, contracts, and internal documents where your database owns the content. It does not work for arbitrary uploaded Word files because there is no original DOCX layout to reproduce.

Decision framework

Why pure JavaScript conversion is different from PDF generation

A JavaScript PDF library can lay out a document because it owns the input model. A DOCX-to-PDF converter has a harder job: reproduce Word's layout decisions from an existing file.

That means a pure-JS converter would need to implement page layout, line breaking, table auto-fit, section settings, headers, footers, footnotes, floating images, font metrics, numbering, and compatibility behavior across Word versions. That is closer to building a word processor than building a PDF writer.

For structured app-generated documents, use JSON and generate both outputs. For uploaded Word files, choose a real conversion engine.