Convert PDF to Word without uploading — a privacy-first workflow

Every day, millions of contracts, invoices, and case files pass through PDF-to-Word converters. The vast majority of those tools upload your document to a foreign server, run extraction there, and email or stream the result back. That model made sense in 2010 when browsers could barely parse images. In 2026 it is an unnecessary liability.

This is the story of how nctools performs the same conversion entirely inside your browser tab — no upload, no queue, no third-party processor — and why that architecture is now measurably faster than the server-based competition for anything under 100 pages.

The privacy math

When a legal team converts a signed NDA to Word to redline a clause, the document typically contains counter-party names, deal terms, and sometimes personal data of individuals covered by the agreement. Under GDPR Article 4, that document is personal data. Under the EU AI Act and most SOC 2 controls, it is confidential company information.

Uploading it to a third-party converter creates a processor relationship: you now need a Data Processing Agreement, sub-processor disclosure, and audit trail. Most free online converters offer none of the above. Some retain files for 30 days. A few train models on them.

How in-browser extraction works

A PDF is a tree of objects — pages, fonts, content streams, images — described in a subset of PostScript. Mozilla's pdfjs-dist ships a full parser and renderer that runs in JavaScript and WebAssembly. We use it to walk every page, extract each glyph with its font, position and style, and rebuild paragraphs from spatial clustering.

For the .docx output, we use the docx library, which generates Office Open XML in-browser. The output is a real Word file that Microsoft Word, LibreOffice, and Google Docs open natively — not a rasterised approximation.

import * as pdfjs from "pdfjs-dist";
import { Document, Packer, Paragraph, TextRun } from "docx";

async function convert(file: File): Promise<Blob> {
  const buf = await file.arrayBuffer();
  const pdf = await pdfjs.getDocument({ data: buf }).promise;
  const paragraphs: Paragraph[] = [];

  for (let n = 1; n <= pdf.numPages; n++) {
    const page = await pdf.getPage(n);
    const content = await page.getTextContent();
    for (const item of content.items) {
      paragraphs.push(new Paragraph({
        children: [new TextRun({ text: (item as any).str })],
      }));
    }
  }

  const doc = new Document({ sections: [{ children: paragraphs }] });
  return Packer.toBlob(doc);
}

Why heading detection matters

A naïve extractor produces a wall of paragraphs. A useful one preserves the document outline: headings, subheadings, lists, and tables. We cluster runs by font size, weight, and position, then map the top three size buckets to Heading 1, 2, and 3 respectively. Bulleted lists are detected by leading glyphs (•, ‣, –) and indentation.

The result is a Word document that opens with a real navigation pane on the left — the same experience as a human-authored file.

Performance in practice

On a 2023 MacBook Air, a 40-page contract converts in about 1.8 seconds. A 200-page policy handbook takes around 9 seconds. All of it is CPU-bound in your tab; nothing is uploaded, no server queue, no cold-start delay. Server-based converters routinely take longer because the file must travel twice over the network before you see the result.

What we cannot do (yet)

Some PDFs are photographs of paper — scanned documents with no text layer. For those, extraction falls back to OCR (see our companion article on Tesseract.js). OCR is slower and less accurate than native extraction, but still runs locally.

Complex multi-column layouts (academic papers, magazines) also require heuristics that occasionally mis-order columns. We ship weekly improvements to the ordering algorithm and would love your problem cases.

Try it now

Head to /tools/pdf-to-word, drop a file, and watch a Word document appear in your Downloads folder. Nothing leaves your machine.