The developer’s complete guide to converting Word documents to PDF
Table of contents

Pick the Nutrient tool that fits your deployment model:
- Nutrient Web SDK — Interactive, browser‑only, offline‑capable workflows (eSignature portals)
- Nutrient Document Authoring SDK — In‑browser editing plus PDF export
- Nutrient Node.js SDK — High‑volume server or serverless pipelines (thousands of documents per hour)
- Nutrient .NET SDK — Windows desktop applications or .NET backends
- Nutrient Processor API — Polyglot microservices or FaaS(opens in a new tab) that can’t install native binaries
- Nutrient Document Engine — Headless server component for embedded or hybrid deployments
- Nutrient Document Automation Server — Low‑code, high‑volume conversion service for on‑premises or private cloud deployments
- Nutrient Document Converter — SharePoint, Power Automate, Nintex, and custom Java/PHP/.NET solutions
Converting Word to PDF powers workflows from eSignature portals to nightly invoice runs. Nutrient exposes its single conversion engine through a range of integration paths:
- Client‑side — Web SDK for view‑only conversion, Document Authoring SDK for in‑browser editing.
- Server‑side — Node.js SDK, .NET SDK, or the language‑agnostic Processor API.
- Low‑code and integration platforms — Document Automation Server for on‑premises batch jobs, and Document Converter for SharePoint, Power Automate, Nintex, and custom Java/PHP/.NET code.
- Headless and embedded— Document Engine when you need a stateless microservice you can host yourself.
The sections that follow provide code samples and configuration tips for each option, starting with the interactive Web SDK and moving through Document Authoring, .NET SDK, Processor API, automation server, and the integration‑friendly Document Converter.
1. Nutrient Web SDK — Browser-based conversion
Nutrient Web SDK performs Word‑to‑PDF conversion entirely in the browser, thanks to a WebAssembly core that embeds the same C++ engine used on Nutrient’s servers. Because the document never leaves the client, you get desktop‑level layout fidelity without any network transfer.
Situations where the Web SDK is appropriate
- Client‑side workflows — Ideal for eSignature portals or in‑browser editors where the document already resides on the user’s device.
- Strict data‑residency or privacy requirements — Because files never leave the browser, the solution meets zero‑trust and regional compliance policies.
- Browser‑level CPU utilization — Processing occurs on the client, which can reduce server load and associated operating costs.
Adding Nutrient to your project
Install the
@nutrient-sdk/viewer
package via npm:Terminal window npm i @nutrient-sdk/viewerTerminal window pnpm add @nutrient-sdk/viewerTerminal window yarn add @nutrient-sdk/viewerCopy the required viewer artifacts to your
assets
directory:Terminal window cp -R ./node_modules/@nutrient-sdk/viewer/dist/ ./assets/
Make sure the assets
directory contains:
nutrient-viewer.js
(or an equivalent main script)- A
nutrient-viewer-lib/
directory with supporting library files
Integrating into your project
Add the DOC or DOCX document you want to display to your project’s directory. You can use our demo document as an example.
Add a mounting
<div>
and a script reference to your HTML:<div id="nutrient" style="width: 100%; height: 100vh;"></div><script type="module" src="index.js"></script>Create an
index.js
file and import the viewer in your JavaScript entry file:import "./assets/nutrient-viewer.js";Initialize the viewer using
NutrientViewer.load()
:const baseUrl = `${window.location.protocol}//${window.location.host}/assets/`;NutrientViewer.load({baseUrl,container: "#nutrient",document: "document.docx",}).then((instance) => {console.log("Nutrient loaded", instance);}).catch((error) => {console.error(error.message);});This method takes a configuration object as its parameter. The configuration object specifies the location of the document on the page, the path to the source document, and the optional license key. The code will load
document.docx
into the element with thenutrient
ID.Convert the source document to a PDF with the
exportPDF
method:<script>NutrientViewer.load({baseUrl,container: "#nutrient",document: "document.docx", // Add the path to your document here.}).then(function (instance) {return instance.exportPDF();}).catch(function (error) {console.error(error.message);});</script>Optionally, you can use the
outputFormat
flag to generate a PDF/A document. For more details, refer to the guide on converting PDF to PDF/A:// The `NutrientViewer.load()` call is omitted for brevity..then(function(instance) {return instance.exportPDF({outputFormat: {conformance: PSPDFKit.Conformance.PDFA_4F}})})Next, save the resulting document. The
exportPDF
method returns aPromise
that resolves into anArrayBuffer
containing the output PDF document. You can use this array buffer to download the PDF or store it:.then(function (buffer) {const blob = new Blob([buffer], { type: "application/pdf" });const objectUrl = window.URL.createObjectURL(blob);downloadPdf(objectUrl);window.URL.revokeObjectURL(objectUrl);})function downloadPdf(blob) {const a = document.createElement("a");a.href = blob;a.style.display = "none";a.download = "output.pdf";a.setAttribute("download", "output.pdf");document.body.appendChild(a);a.click();document.body.removeChild(a);}
When you convert an Office document with custom fonts to a PDF, Nutrient Web SDK may not have access to these fonts due to licensing constraints. In this case, Nutrient typically replaces unavailable fonts with their equivalents — like Arial with Noto.
2. Nutrient Document Authoring SDK — In-browser editing and export
Nutrient’s Document Authoring SDK extends the Web SDK with a full WYSIWYG editor that runs entirely in the browser. It imports DOCX files, lets users make Word‑style edits, and exports the result as either DOCX or PDF — no server roundtrips, and no loss of layout fidelity.
When to consider Document Authoring
- Browser‑based editing workflows — Contract review, proposal drafting, or template‑fill scenarios where users must modify a document before downloading.
- Strict fidelity requirements — The exported PDF or DOCX mirrors the original Word file, including headers, tables, and pagination.
- Single‑step import → edit → export — Everything happens in the tab; no intermediate uploads or server processing.
Key capabilities
Feature | Notes |
---|---|
DOCX import / export | Roundtrip edits back to Word when needed. |
PDF export | Same exportPDF() method as other SDKs. |
Word-style editing | Paragraph, table, list, header/footer, section management. |
React-friendly API | Mounts on a DOM element via ref ; works with hooks or class comps. |
UI customization | Configure locale, measurement units, and ruler visibility via configuration. |
Check out the blog on how to integrate a DOCX editor in your React app using Nutrient for information on how to convert a DOCX to PDF in a React app using the Document Authoring SDK.
The SDK supports both DOCX import and dual-format export (DOCX and PDF), making it suitable for scenarios that start and end in Word but require a review step in the browser.
3. Nutrient Node.js SDK — Server-side conversion
Nutrient Node.js SDK embeds a self‑contained conversion engine right into your JavaScript runtime, so you can turn Office files or images into PDFs without installing LibreOffice, Ghostscript, or Microsoft Office. This SDK supports DOCX, XLSX, PPTX, and more, and is suitable for headless/serverless environments.
Nutrient relies on its own technology, built from the ground up. No external binaries, fewer deployment headaches.
Key features
- Versatile conversion — Seamlessly convert PDF, Word, Excel, PowerPoint, TIFF, JPG, and PNG files.
- Custom font support — Preserves document integrity by intelligently handling custom fonts.
- Diverse file handling — Works with DOCX, XLSX, PPTX, and popular image types such as PNG and JPEG.
- Advanced rendering — Render PDF pages into PNG or WebP for easy previews and thumbnails.
Quick start using the Node.js SDK
Initialize a project:
Terminal window npm init -yInstall the SDK:
Terminal window npm install @nutrient-sdk/nodePlace
sample.docx
in your project directory.Create
index.mjs
and add the following code to convert DOCX to PDF:import { load } from "@nutrient-sdk/node";import { readFileSync, writeFileSync } from "node:fs";async function convertToPDF() {const docx = readFileSync("document.docx");const instance = await load({document: docx,});const buffer = await instance.exportPDF();writeFileSync("converted.pdf", Buffer.from(buffer));await instance.close();}convertToPDF();Run the converter:
Terminal window node index.mjs
After execution, you’ll find converted.pdf
in your project folder. If you’d like to remove the trial watermark, pass a license key via the license
property
4. Nutrient .NET SDK — Desktop and Windows-based backends
Nutrient .NET SDK brings advanced Word-to-PDF conversion and document processing to any application built on the Microsoft stack. Delivered as a pure .NET library, it integrates seamlessly with WinForms and WPF desktop clients, as well as ASP.NET or Azure Functions running on Windows. There are no COM wrappers or Microsoft Office interop requirements — just copy the assemblies alongside your executable, and the converter is ready to run. This makes deployment straightforward and reliable.
When the .NET SDK is a good fit
- Microsoft stack integration — Ideal for applications built with .NET technologies, including desktop and server-side solutions.
- Desktop environments — Seamlessly integrates with Windows desktop applications, such as those built with WinForms or WPF.
- No external dependencies — Doesn’t require Microsoft Office, LibreOffice, or COM interop; just copy the assemblies alongside your executable for straightforward deployment.
- Reliable document processing — Enables high-fidelity Word-to-PDF conversion and robust document handling features.
- Flexible deployment — Suitable for both desktop clients and Windows-based backend services.
Quick start (C#)
using GdPictureDocumentConverter gdpictureDocumentConverter = new GdPictureDocumentConverter();// Load the source document.gdpictureDocumentConverter.LoadFromFile(@"C:\docs\report.docx", GdPicture14.DocumentFormat.DocumentFormatDOCX);// Save the output in a new PDF document.gdpictureDocumentConverter.SaveAsPDF(@"C:\docs\report.pdf");
Pro tips and best practices
Merge PDFs — After conversion, use the
GdPictureDocumentConverter
class to merge multiple PDFs or documents of different formats into a single PDF. For example:using GdPictureDocumentConverter gdpictureConverter = new GdPictureDocumentConverter();IEnumerable<string> source = new List<string>(new string[] { @"C:\temp\file1.pdf", @"C:\temp\file2.pdf" });gdpictureConverter.CombineToPDF(source, @"C:\temp\output.pdf", PdfConformance.PDF1_5);
5. Nutrient Converter API — Language-independent HTTP interface
Nutrient DWS Processor API exposes the Word-to-PDF engine behind a straightforward HTTP endpoint. Because conversion happens on Nutrient’s infrastructure, any language that can make a POST
request can produce a PDF, without any native libraries, package managers, or platform‑specific binaries required.
Nutrient offers a free plan(opens in a new tab) that includes 100 credits upon signup. Each API call consumes a certain number of credits depending on the operation. For example, converting a DOCX to PDF may cost fewer credits than OCR or PDF/A conversion. Once you use up your free credits, you can upgrade to a paid plan directly from your account dashboard. All you need to get started is a free account(opens in a new tab), which gives you immediate access to your API key.
When DWS Processor API is appropriate
- When you need a language-independent HTTP API for document conversion, allowing integration from any environment that can make HTTP requests.
- When you require a simple, scalable solution for generating PDFs or converting documents without managing your own infrastructure.
- When you want to quickly enable document conversion in your application with minimal setup, using a free plan to get started.
Quick start (Python)
import requestsimport json
response = requests.request( 'POST', 'https://api.nutrient.io/build', headers = { 'Authorization': 'Bearer your_api_key_here' # Replace with your API key }, files = { 'file': open('input.docx', 'rb') }, data = { 'instructions': json.dumps({ 'parts': [ { 'file': 'file' } ] }) }, stream = True)
if response.ok: with open('result.pdf', 'wb') as fd: for chunk in response.iter_content(chunk_size=8096): fd.write(chunk)else: print(response.text) exit()
6. Nutrient Document Engine — Server-side headless service
Nutrient Document Engine is a headless service that runs Nutrient’s high‑fidelity conversion core on your own infrastructure (Docker container or VM). It accepts Office files through a single REST endpoint — /api/build
— and returns a PDF by default, with options for other formats.
Why use Document Engine?
- Zero third‑party dependencies — No LibreOffice or Microsoft Office required.
- Highly scalable — Can be deployed in your own infrastructure, including Kubernetes and behind load balancers, and supports horizontal scaling by connecting multiple nodes to a shared database.
- Consistent output — The same rendering engine as Web, Node.js, .NET, and DWS Processor API.
Quick workflow
- Make sure your Document Engine container (or service) is running and you have an API token.
- Send a multipart
POST
request tohttp://<host>:5000/api/build
. - Include:
document
— The DOCX file (as@file
or via public URL).instructions
— JSON describing the parts to process (at minimum, reference the file).
The response body is the generated PDF; use -o
in cURL (or an equivalent in your language) to save it.
Example — Convert a local DOCX
curl -X POST http://localhost:5000/api/build \ -H "Authorization: Token token=<API_TOKEN>" \ -F document=@/path/to/example-document.docx \ -F instructions='{ "parts": [ { "file": "document" } ] }' \ -o result.pdf
The default output is PDF. Supply an
output
object ininstructions
if you need another format (see the API reference).
For full details — including additional actions (merge, OCR, PDF/A, encryption), multipart‑request structure, and output options — refer to the Document Engine API reference and the brief guide on composing multipart requests.
7. Document Automation Server — Low-code
Nutrient Document Automation Server is a robust backend solution designed for automating high-volume document conversion tasks — including, but not limited to, Word-to-PDF conversion — within enterprise-grade workflows. It can be integrated into your infrastructure and supports batch processing and automated workflows for large-scale operations.
For converting MS Office files to PDF, Document Automation Server provides four step options:
- Convert any file to PDF — For Word documents, this uses an instance of Microsoft Word installed on the host machine.
- Convert any file to PDF (GdPicture) — This step doesn’t require an instance of Microsoft Word.
- Any file to searchable PDF (standard) — For Word documents, this uses an instance of Microsoft Word installed on the host machine and OCRs any images using the standard OCR engine.
- Any file to searchable PDF (Canon/IRIS) — For Word documents, this uses an instance of Microsoft Word installed on the host machine and OCRs any images using the Canon/IRIS OCR engine.
These methods provide flexibility for different deployment scenarios and compliance requirements, making Nutrient Document Automation Server a comprehensive choice for enterprise document conversion automation.
8. Nutrient Document Converter — Multi-language SDK and low-code connectors
Nutrient Document Converter packages the same DOCX-to-PDF engine for Java, PHP, .NET, and other servers while also shipping no-code/low-code connectors for popular enterprise platforms.
Supported runtime/integration targets include:
- SharePoint (Online and on-premises)
- Power Automate flows
- Nintex workflows
- Windows Servers(opens in a new tab) (IIS, services, or scheduled tasks)
- REST API(opens in a new tab) (cloud-hosted endpoint)
- SOAP API (self-hosted service)
- Custom applications via the Java, PHP, or .NET SDKs
Whether you embed the SDK in code, drop the REST endpoint into a microservice, or add the low-code connector to a SharePoint or Power Automate flow, you get the same capabilities:
- Convert DOCX → PDF (and 100 + other formats) with a single call.
- Generate PDF/A, apply encryption, or merge multiple parts via the instructions JSON.
- Deploy on‑premises or in the cloud without Microsoft Office or LibreOffice.
Example: In a Power Automate flow you can add the “Convert Document with Nutrient” action and point it at an uploaded DOCX, and the flow returns a PDF you can store back to SharePoint or email to a recipient — all powered by the same engine used in the Node.js, .NET, and Web SDKs.
Check out the Nutrient Document Converter guide for more details on how to set up the low-code connectors or use the multi-language SDK.
Summary table
Product/method | Needs MS Office? | Extra runtime deps | Typical deployment | Key capabilities |
---|---|---|---|---|
Web SDK (interactive) | No | None | Browser (JavaScript) | Client‑side viewer + converter; offline |
Document Authoring SDK | No | None | Browser (JavaScript) | In‑browser WYSIWYG editing; DOCX import/export; PDF export |
Node.js SDK | No | None | Node.js servers | High‑volume batch streaming API, custom font handling |
.NET SDK | No | None | Win desktop, ASP.NET, Azure | Fully managed, COM‑free; parallel batch loops |
DWS Processor API | No | None | Any language/FaaS | HTTP POST; PDF/A, encryption, webhooks |
Document Automation Server | Yes (for Office formats) | BCL easyPDF service | On‑premises/private cloud | Low‑code, high‑volume batch processing |
Document Engine | No (optional) | None | Headless or embedded server | High‑fidelity engine, scale‑out microservice for hybrid deployments |
Document Converter | No | None | SharePoint/Power Automate/Nintex, Java/PHP/.NET apps | Low‑code connectors + multi‑language SDK; DOCX to PDF and 100 + formats; on‑premises or cloud |
One engine, many interfaces — Every option except Document Automation Server uses Nutrient’s proprietary C++ core compiled for its target runtime, so PDF output stays consistent across browser, server, desktop, and low‑code platforms.
Conclusion
Whether you need a one‑click Power Automate action, a headless microservice, or a drop‑in browser component, Nutrient offers the same high‑fidelity Word-to-PDF conversion engine everywhere you build.
- Frontend teams can stay fully client‑side with Web SDK or add rich editing through Document Authoring SDK.
- Backend teams can choose between the self‑contained Node.js/.NET libraries, the language‑agnostic DWS Processor API, or the scalable Document Engine they can host themselves.
- Low‑code architects get point‑and‑click conversion in SharePoint, Power Automate, and Nintex via Document Converter, while operations teams can automate huge batches with Document Automation Server.
Because every path shares the same core, you’re free to start wherever you have the least friction today and switch later without sacrificing output fidelity.
Have questions or planning a rollout? Contact our Sales team to get personalized guidance, pricing details, and deployment recommendations.
Or, spin up a free DWS Processor API trial(opens in a new tab) or pull the Docker image for Document Engine and see the results firsthand. We’re here to help you move fast without tradeoffs.
FAQ
Do I need Microsoft Office installed to use Nutrient SDKs?
No. Web SDK, Document Authoring SDK, Node.js SDK, .NET SDK, Processor API, and Document Engine are self‑contained. Only Document Automation Server relies on a local Office installation for its “MS Office Native,” “Direct Print,” and “Extended Print” modes.
How large can a Word document be in the Web SDK?
Browser memory limits apply. In practice, documents up to about 200 MB can convert in modern desktop browsers. Larger files should be handled with Node.js SDK, .NET SDK, Processor API, or Document Engine.
Can I embed or substitute custom fonts?
Server‑side tools automatically embed licensed fonts where possible. In the Web SDK, fonts unavailable in the browser are replaced with metrically compatible equivalents (for example, Arial to Noto Sans).
Is offline use allowed?
Yes. Web SDK and Document Authoring SDK work fully offline once assets are cached. Node.js SDK, .NET SDK, and Document Engine run entirely on your infrastructure with no outbound calls.
What’s the easiest way to trial the engine?
Create a free account and use the Processor API(opens in a new tab); you receive 100 credits instantly. POST a DOCX to /api/build
and the API returns a PDF in the response.
How do I add a license key to client‑side SDKs?
Pass the key in the configuration object (licenseKey
for Web SDK, license
for Node.js SDK, and so on). Keys are verified locally; no network request is made during validation.