DEV Community: Jen

How to Export Excel to PDF in .NET (Fast & Accurate Method)

Jen — Mon, 30 Mar 2026 07:46:31 +0000

If you’ve ever tried exporting Excel to PDF in a backend service, you probably started with Microsoft.Office.Interop.Excel. And then it broke.

No Office is installed on the server. Random crashes under load. Processes that refuse to die. It might work on your machine — but not in production. What you really want is something predictable: no Office dependency, no layout surprises, and something that actually survives in a server or container environment.

So how do you do that cleanly in .NET?

Why Traditional Approaches Fall Short

The go-to options for Excel-to-PDF conversion in .NET each come with real trade-offs.

Microsoft.Office.Interop.Excel requires a full Office installation on the server — something Microsoft explicitly advises against for server-side use. Even when it works, it's single-threaded COM automation running in a multi-request environment: slow, fragile, and prone to leaving zombie processes when something goes wrong.
Manual rendering with libraries like iTextSharp flips the problem. No Office dependency, but now you're manually reading every cell, recreating styles, handling merged regions, and rebuilding layouts from scratch. The code is brittle, and even after all that work, the output rarely looks like the original.

These approaches either don't scale well or fail to preserve formatting — often both.

What We Actually Need

The real challenge isn't just converting Excel to PDF — it's doing it reliably in a backend environment where Office doesn't exist and formatting still has to look right.

A practical solution needs to check a few boxes:

No Microsoft Office dependency — must run on a clean server or Linux container.
Accurate output — merged cells, fonts, column widths, and print layout all preserved.
Handles complex files — charts, images, and multi-sheet workbooks shouldn't break it.
Simple API — integration shouldn't require rebuilding your document rendering logic from scratch.

With these requirements in mind, let's look at a practical approach.

Getting Started (Minimal Setup)

A practical way to achieve this is by using a dedicated .NET Excel processing library such as Spire.XLS for .NET — a standalone Excel processing library that handles conversion without any Office dependency.

Install it via NuGet:

dotnet add package Spire.XLS

Or through the Package Manager Console:

Install-Package Spire.XLS

A few things worth noting before we write any code:

Works with .NET 6, 7, 8 and .NET Framework.
Runs on Windows, Linux, and in Docker containers.
No Microsoft Office installation required.

That's all the setup needed. Let's convert something.

Basic Example: Export Entire Workbook to PDF

Here's the simplest form of the conversion — load a workbook, export to PDF:

using Spire.Xls;

class Program
{
    static void Main()
    {
        // Create a Workbook object
        Workbook workbook = new Workbook();

        // Load the Excel file
        workbook.LoadFromFile(@"C:\Users\Sample.xlsx");

        // Option: Fit each sheet to a page on export
        workbook.ConverterSetting.SheetFitToPage = true;

        // Save as PDF
        workbook.SaveToFile(@"C:\Users\Sample.pdf", FileFormat.PDF);

        // Release resources
        workbook.Dispose();
    }
}

That's the full conversion. No COM objects, no Office installation, no temp files to clean up. This approach works especially well in background jobs, scheduled tasks, or API-based report generation.

A few things the library handles automatically:

Merged cells — preserved as-is.
Fonts and cell styles — carried over to the output.
Column widths and row heights — no reflow or guesswork.

SheetFitToPage = true is worth setting by default. Without it, wide sheets may split across pages in ways that break the layout — we'll cover more layout controls in a later section.

At this point, you already have a reliable Excel-to-PDF pipeline that works without Office and preserves most formatting out of the box.

Advanced Excel to PDF Conversion Scenarios

The basic example works well — but real-world projects rarely stay that simple. Here are three variations you'll likely run into.

Export a Specific Worksheet

Useful when your workbook contains multiple sheets and you only need to export one — a department report, a specific template tab:

using Spire.Xls;

class Program
{
    static void Main()
    {
        // Create a Workbook object
        Workbook workbook = new Workbook();

        // Load the Excel file
        workbook.LoadFromFile(@"C:\Users\Multi-SheetChart.xlsx");

        // Get the second worksheet (index starts from 0)
        Worksheet sheet = workbook.Worksheets[1];

        // Option: Fit the worksheet to a single page (worksheet level)
        sheet.PageSetup.FitToPagesWide = 1;   // Fit width to 1 page
        sheet.PageSetup.FitToPagesTall = 0;   // Height adjusts automatically

        // Save the specific worksheet as PDF
        sheet.SaveToPdf(@"C:\Users\Multi-SheetChart_Sheet2.pdf");

        // Release resources
        workbook.Dispose();
    }
}

Batch Export Multiple Worksheets

When you need each sheet as a separate PDF file:

using Spire.Xls;
using System.IO;

class Program
{
    static void Main()
    {
        // Create a Workbook object and load the Excel file
        Workbook workbook = new Workbook();
        workbook.LoadFromFile(@"C:\Users\Multi-SheetChart.xlsx");

        // Get the output directory (same as input file location)
        string outputDir = Path.GetDirectoryName(@"C:\Users\Multi-SheetChart.xlsx");

        // Iterate through all worksheets
        for (int i = 0; i < workbook.Worksheets.Count; i++)
        {
            Worksheet sheet = workbook.Worksheets[i];

            // Use the worksheet name as the PDF filename
            string fileName = $"{sheet.Name}.pdf";
            string outputPath = Path.Combine(outputDir, fileName);

            // Save the worksheet as PDF
            sheet.SaveToPdf(outputPath);

            System.Console.WriteLine($"Exported: {sheet.Name} → {fileName}");
        }

        // Release resources
        workbook.Dispose();

        System.Console.WriteLine("\nAll worksheets exported successfully!");
    }
}

Each sheet is saved as an individual file named after the sheet tab. Pair this with Directory.CreateDirectory() to ensure the output folder exists before running.

Export a Defined Print Area

If your sheet has a defined print area — say, a template where only rows 10–34 contain actual data — you can export just that range:

using Spire.Xls;

class Program
{
    static void Main()
    {
        // Create a Workbook object
        Workbook workbook = new Workbook();

        // Load the Excel file
        workbook.LoadFromFile(@"C:\Users\StyleSheet.xlsx");

        // Get the first worksheet
        Worksheet sheet = workbook.Worksheets[0];

        // Define the range to export
        sheet.PageSetup.PrintArea = "A10:H34";

        // Optional: Fit the print area to a single page width
        sheet.PageSetup.FitToPagesWide = 1;    // Scale width to 1 page
        sheet.PageSetup.FitToPagesTall = 0;    // Height automatically adjusts

        // Save the print area as PDF
        sheet.SaveToPdf(@"C:\Users\StyleSheet_PrintArea.pdf");

        // Release resources
        workbook.Dispose();
    }
}

This is particularly useful for template-based reports where the sheet contains helper formulas or reference data outside the visible range that you don't want included in the output.

Returning PDF in ASP.NET Core

In a real backend service, you usually don't want to write files to disk — especially in containerized environments where the filesystem may be read-only or ephemeral. Here's how to convert and return the PDF entirely in memory:

using Microsoft.AspNetCore.Mvc;
using Spire.Xls;

[ApiController]
[Route("api/[controller]")]
public class ReportController: ControllerBase
{
    [HttpGet("export")]
    public IActionResult ExportToPdf()
    {
        // Load the Excel workbook
        Workbook workbook = new Workbook();
        workbook.LoadFromFile("report.xlsx");  // Ensure file exists in the correct location
        workbook.ConverterSetting.SheetFitToPage = true;

        // Convert directly to memory — no temp file needed
        using var stream = new MemoryStream();
        workbook.SaveToStream(stream, FileFormat.PDF);
        workbook.Dispose();

        // Rewind before reading
        stream.Position = 0;

        // Return as file download
        return File(
            stream.ToArray(),  // Can be optimized (For large files, consider returning the stream directly instead of ToArray())
            "application/pdf",
            "report.pdf"         // triggers download in the browser
        );
    }
}

A few things worth noting:

SaveToStream with FileFormat.PDF writes directly to the MemoryStream — no intermediate file on disk.
stream.Position = 0 rewinds the stream before reading; skipping this returns an empty response.
Content-Disposition is handled automatically by ASP.NET Core's File() result when you pass a filename as the third argument.

This pattern works cleanly in Docker containers, Azure App Service, AWS Lambda, or any environment where writing to the local filesystem isn't an option. It also avoids file I/O overhead, which can become a bottleneck under high concurrency.

Controlling Layout for Accurate Output

The conversion works — but on complex sheets, the default settings don't always produce clean output. Wide tables get sliced across pages, margins clip content, and landscape data ends up portrait. These three settings fix most of it.

Page Size & Orientation

using Spire.Xls;

Workbook workbook = new Workbook();
workbook.LoadFromFile("report.xlsx");

Worksheet sheet = workbook.Worksheets[0];

// Set paper size and orientation
sheet.PageSetup.PaperSize = PaperSizeType.PaperA4;
sheet.PageSetup.Orientation = PageOrientationType.Landscape;

sheet.SaveToPdf("report.pdf");
workbook.Dispose();

Margins

// Values are in inches
sheet.PageSetup.TopMargin    = 0.5;
sheet.PageSetup.BottomMargin = 0.5;
sheet.PageSetup.LeftMargin   = 0.5;
sheet.PageSetup.RightMargin  = 0.5;

Tightening the margins gives your content more room to breathe — particularly useful when you're fitting a wide table onto a single page.

Scaling (the important one)

// Force the sheet to fit within one page wide
sheet.PageSetup.FitToPagesWide = 1;
sheet.PageSetup.FitToPagesTall = 0; // 0 = no vertical limit

FitToPagesWide = 1 is the single most effective setting for preventing wide sheets from splitting mid-column across pages. Setting FitToPagesTall = 0 lets the content grow vertically as needed — you get a clean single-column layout without squashing everything onto one page.

These three settings mirror what you'd configure in Excel's Page Layout tab before printing — if the sheet looks right there, it'll look right in the exported PDF.

Common Issues & Fixes

Fonts render as squares or tofu characters

Scenario: PDF output looks fine on Windows but shows blank boxes where text should be on your CI server or container.

Cause: The Excel file uses fonts that aren't available in the server environment. The library falls back to a missing font and renders nothing.

Fix: Install the missing fonts in your environment, or point the library to a custom font directory:

// Tell Spire.XLS where to find fonts at runtime
workbook.CustomFontPath = "/usr/share/fonts/custom";

For Windows-style fonts on Linux, installing ttf-mscorefonts-installer via apt usually resolves the most common cases.

Charts or images missing from the PDF

Scenario: Your workbook contains charts or embedded images that simply don't appear in the exported PDF.

Cause: Chart rendering requires the sheet to be processed in a specific rendering mode. Default settings may skip embedded objects.

Fix: Make sure you're converting via the workbook-level method rather than the worksheet-level one — workbook-level conversion applies full rendering passes, including charts:

// Prefer this for sheets with charts or images
workbook.ConverterSetting.SheetFitToPage = true;
workbook.SaveToFile("report.pdf", FileFormat.PDF);

Layout errors or crashes on Linux / Docker

Scenario: Everything works locally on Windows, but after deploying to a Linux container you get a DllNotFoundException or the PDF layout is completely broken.

Cause: Spire.XLS depends on System.Drawing.Common, which in turn requires libgdiplus — a native library that isn't included in the default .NET Linux base image.

Fix: Add the following to your Dockerfile:

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        libgdiplus \
        libc6-dev \
        libx11-dev \
    && rm -rf /var/lib/apt/lists/*

This is the officially recommended setup for running Spire.XLS in Linux containers.

Wrap-Up

At this point, you’ve got a solid Excel-to-PDF workflow in .NET — no Office dependencies, no fragile COM automation, and no need to rebuild layouts from scratch. It works just as well for background jobs, APIs, or containerized services, and scales from simple exports to more complex reporting scenarios.

If you're dealing with document generation in your own projects, I’m curious — how are you handling Excel-to-PDF today?

OpenXML SDK vs Spire.Doc: Which One Should You Use for Word Processing in C#?

Jen — Mon, 23 Mar 2026 09:32:00 +0000

Processing Word documents in C# is a common requirement in many backend systems, such as report generation, document automation, and data extraction. Developers typically choose between the Open XML SDK, which provides low-level access to the .docx structure, and third-party libraries like Spire.Doc that offer higher-level APIs.

Each approach comes with trade-offs in terms of development complexity, feature support, and flexibility. In this article, we’ll compare these two options through a practical scenario to help you choose the right solution for your project.

Understanding .docx and Server-Side Constraints
Option A: DocumentFormat.OpenXML SDK
- Example 1: Read All Paragraph Text
- Example 2: Replace Template Placeholders {{name}}
- Example 3: Insert a Formatted Table
- Limitations
- When OpenXML SDK Is the Right Choice
Option B: Using Third-Party Libraries (Spire.Doc)
- Example 1: Read All Paragraph Text
- Example 2: Replace Template Placeholders {{name}}
- Example 3: Insert a Formatted Table
- Example 4: Export to PDF
- Limitations
- When It Makes Sense to Use Third-Party Libraries
Side-by-Side Comparison
Performance & Scalability Considerations
Common Pitfalls and Hidden Traps
Decision Guide: Which One Should You Choose?

Understanding .docx and Server-Side Constraints

Before choosing a library, it helps to understand what you're actually dealing with.

A .docx file is not a binary format. It's a ZIP archive containing a collection of XML files, defined by the ECMA-376 standard — also known as Office Open XML (OOXML). Rename any .docx to .zip, extract it, and you'll find a structure like this:

mydocument.docx (extracted)
├── [Content_Types].xml
├── _rels/
│   └── .rels
└── word/
    ├── document.xml        ← your actual content lives here
    ├── styles.xml          ← paragraph and character styles
    ├── settings.xml
    ├── theme/
    │   └── theme1.xml
    └── _rels/
        └── document.xml.rels

The main content lives in word/document.xml. A single paragraph with bold text looks like this:

<w:p>
  <w:r>
    <w:rPr>
      <w:b/>
    </w:rPr>
    <w:t>Hello, World!</w:t>
  </w:r>
</w:p>

w:p is a paragraph. w:r is a run — a contiguous region of text sharing the same formatting. w:rPr holds the run's properties; w:b toggles bold. This is the atom of Word's content model, and every library you evaluate is ultimately reading and writing variations of this structure.

The ECMA-376 specification that defines all of this runs to over 6,000 pages. In practice, you don't need to read it — but you do need to understand that the abstraction level your library provides over this XML is the single most important factor in your day-to-day development experience.

Why Server-Side Processing Adds Complexity

Manipulating .docx files in a desktop context is relatively forgiving. On a server, four constraints change the equation:

No Office installation. Microsoft explicitly warns against using Word Automation (COM/Interop) in server environments. That rules out the most "complete" Word-compatible engine unless you license it separately.

Cross-platform deployment. If your service runs in a Linux container — and most do — any library with a Windows-only dependency is immediately disqualified.

Concurrency. A server handling concurrent document generation requests needs thread-safe library behavior. Not all libraries guarantee this, and the ones that don't require per-request instantiation at a minimum.

PDF export. "Generate a Word document" almost always means "generate a Word document and a PDF rendition." The OpenXML SDK has no rendering engine; PDF output requires a separate solution. Some third-party libraries include one.

These four constraints are what make the OpenXML SDK vs. third-party library decision non-trivial — and why the "just use the free one" instinct doesn't always hold up in production.

Option A: DocumentFormat.OpenXML SDK

The Open XML SDK is a Microsoft-provided library for working directly with Office Open XML documents such as .docx, .xlsx, and .pptx.

Instead of relying on Microsoft Word, it allows you to read and modify documents by interacting with their underlying XML structure. This makes it suitable for server-side environments where installing Office is not an option.

dotnet add package DocumentFormat.OpenXml

It maps directly to the XML structure described in the previous section — which means it's precise and complete, but also verbose. There is no abstraction between you and the OOXML spec.

Example 1: Read All Paragraph Text

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;

public static List<string> ReadParagraphs(string filePath)
{
    using var doc = WordprocessingDocument.Open(filePath, isEditable: false);

    var body = doc.MainDocumentPart!.Document.Body!;

    return body
        .Descendants<Paragraph>()
        .Select(p => string.Concat(p.Descendants<Text>().Select(t => t.Text)))
        .Where(text => !string.IsNullOrWhiteSpace(text))
        .ToList();
}

This is one of the cleaner operations in the SDK. Descendants<T>() traverses the XML tree generically, and the LINQ chain stays readable.

Example 2: Replace Template Placeholders `{{name}}`

A common server-side pattern: fill a pre-authored .docx template with runtime data.

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;

void MailMerge(string templatePath, string outputPath, string name)
{
    using (WordprocessingDocument doc = WordprocessingDocument.Open(templatePath, true))
    {
        var body = doc.MainDocumentPart.Document.Body;

        foreach (var text in body.Descendants<Text>())
        {
            if (text.Text.Contains("{{name}}"))
            {
                text.Text = text.Text.Replace("{{name}}", name);
            }
        }

        doc.SaveAs(outputPath);
    }
}

One important caveat: Word sometimes splits a placeholder like {{name}} across multiple <w:t> elements when the user types or edits it — for example, {{, name, }} may each land in a separate Run. A production-grade implementation needs to consolidate runs within each paragraph before scanning for placeholders. The code above works reliably only for placeholders that were pasted in as a single text node, which is the case for programmatically generated templates.

Example 3: Insert a Formatted Table

using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;
using System.Linq;

void InsertTable(string path)
{
    using var doc = WordprocessingDocument.Open(path, true);

    var p = doc.MainDocumentPart.Document.Body
        .Descendants<Paragraph>()
        .FirstOrDefault(p => p.InnerText.Contains("The table below presents the sales data for key items."));

    if (p != null)
    {
        p.InsertAfterSelf(CreateTable());
        p.InsertAfterSelf(new Paragraph());
        doc.Save();
    }
}

Table CreateTable()
{
    var t = new Table();

    t.AppendChild(new TableProperties(new TableBorders(
        new TopBorder { Val = BorderValues.Single, Size = 8 },
        new BottomBorder { Val = BorderValues.Single, Size = 8 },
        new LeftBorder { Val = BorderValues.Single, Size = 8 },
        new RightBorder { Val = BorderValues.Single, Size = 8 },
        new InsideHorizontalBorder { Val = BorderValues.Single, Size = 8 },
        new InsideVerticalBorder { Val = BorderValues.Single, Size = 8 }
    )));

    string[,] d = {
        { "Product", "Units Sold", "Revenue ($)" },
        { "Laptop", "1,250", "1,299,000" },
        { "Monitor", "850", "765,000" },
        { "Wireless Mouse", "3,200", "92,800" }
    };

    for (int i = 0; i < 4; i++)
    {
        var row = new TableRow();
        for (int j = 0; j < 3; j++)
        {
            var para = new Paragraph();
            var run = new Run(new Text(d[i, j]));

            if (i == 0)
            {
                run.RunProperties = new RunProperties(new Bold());
                row.AppendChild(new TableCell(
                    new TableCellProperties(new Shading { Val = ShadingPatternValues.Clear, Fill = "4472C4" }),
                    new Paragraph(new Run(run.RunProperties, new Text(d[i, j])))
                ));
            }
            else
            {
                para.AppendChild(run);
                if (j > 0) para.ParagraphProperties = new ParagraphProperties(new Justification { Val = JustificationValues.Right });
                row.AppendChild(new TableCell(para));
            }
        }
        t.AppendChild(row);
    }
    return t;
}

This is where the verbosity of the SDK becomes apparent. This is where many developers start to feel the friction. The object graph mirrors the XML tree exactly — every border, every shading value, every color is a separate object. This is accurate and fully controllable, but it requires familiarity with the underlying OOXML structure before you can write it confidently.

Limitations

At first glance, the SDK seems manageable. But as soon as you move beyond simple text operations, complexity increases quickly.

1. Verbose and Low-Level API

Even basic formatting requires navigating multiple layers:

Paragraph.
Run.
RunProperties.

A small visual change in Word often translates into a surprisingly large amount of code.

2. Understanding Document Structure Is Required

To do anything non-trivial, you need to understand how Word structures content internally:

How text is split across runs.
How styles are applied.
How relationships (rId) are managed.

Without this, it's easy to produce documents that look fine in code but break in Word.

3. No Built-in Rendering (e.g., PDF)

The SDK does not support converting Word documents to PDF.

To achieve this, you typically need to integrate external tools such as:

LibreOffice (via command line).
Other conversion services.

This adds operational complexity, especially in containerized environments.

When OpenXML SDK Is the Right Choice

Your service runs on Linux or in a container and you cannot take on a commercial dependency.
You need zero-cost licensing with no per-server or per-document fees.
You require precise, low-level control over document structure.
PDF export is not a requirement, or you are prepared to manage a separate rendering pipeline.

In short, OpenXML gives you maximum control — but that control comes with a significant development cost.

Option B: Using Third-Party Libraries (Spire.Doc)

Spire.Doc is a commercial .NET library developed by E-iceblue. Unlike the OpenXML SDK, it does not expose the OOXML object model directly — instead, it provides a document-oriented API that abstracts the XML layer entirely. It also ships with its own rendering engine, which means PDF export is a first-class feature rather than an afterthought.

dotnet add package Spire.Doc

The free tier (Spire.Doc for .NET Free) is available on NuGet without registration. It supports most core features but imposes two hard limits: documents are capped at 3 pages, and a watermark is appended beyond that threshold. Production use requires a commercial license.

Example 1: Read All Paragraph Text

using Spire.Doc;

string ReadAllParagraphs(string filePath)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(filePath);
        return doc.GetText();
    }
}

The Paragraph.Text property aggregates all runs automatically. No descending into child nodes required.

Example 2: Replace Template Placeholders `{{name}}`

using Spire.Doc;

void MailMerge(string templatePath, string outputPath, string name)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(templatePath);

        doc.Replace("{{name}}", name, false, true);

        doc.SaveToFile(outputPath, FileFormat.Docx);
    }
}

Document.Replace() handles run-splitting internally. The problem described in the OpenXML SDK section — where a placeholder like {{name}} is split across multiple <w:t> elements — does not surface here. The library normalizes the text representation before searching.

Example 3: Insert a Formatted Table

using Spire.Doc;
using Spire.Doc.Documents;

class Program
{
    static void Main()
    {
        Document doc = new Document();
        doc.LoadFromFile("input.docx");

        var sel = doc.FindString("The table below presents the sales data for key items.", false, true);
        if (sel != null)
        {
            var body = sel.GetAsOneRange().OwnerParagraph.Owner as Body;
            if (body != null)
            {
                int idx = body.ChildObjects.IndexOf(sel.GetAsOneRange().OwnerParagraph);
                body.ChildObjects.Insert(idx + 1, CreateTable(doc));
                doc.SaveToFile("output.docx", FileFormat.Docx);
            }
        }
        doc.Dispose();
    }

    static Table CreateTable(Document doc)
    {
        string[,] d = {
            { "Product", "Units Sold", "Revenue ($)" },
            { "Laptop", "1,250", "1,299,000" },
            { "Monitor", "850", "765,000" },
            { "Wireless Mouse", "3,200", "92,800" }
        };

        Table t = new Table(doc);
        t.ResetCells(4, 3);

        for (int i = 0; i < 4; i++)
            for (int j = 0; j < 3; j++)
                t.Rows[i].Cells[j].AddParagraph().AppendText(d[i, j]);

        return t;
    }
}

The structure is comparable in length to the OpenXML SDK version for this particular operation — table construction is inherently row-and-cell iteration regardless of the library. The difference is in the API surface: cell.CellFormat.BackColor versus constructing a Shading object with ShadingPatternValues.Clear and a hex string.

Example 4: Export to PDF

The OpenXML SDK does not provide a rendering engine, so PDF export requires integrating external tools (e.g., LibreOffice or commercial renderers).

using Spire.Doc;

public static void ExportToPdf(string docxPath, string pdfPath)
{
    var doc = new Document(docxPath);
    doc.SaveToFile(pdfPath, FileFormat.PDF);
}

Spire.Doc uses its own rendering engine to produce the PDF — no LibreOffice, no Word installation, no additional process to manage. Font fidelity and layout accuracy are generally reliable for standard documents; complex layouts with custom fonts may require additional configuration (covered in the pitfalls section).

Limitations

1. Higher-Level API

Most operations map directly to how developers think about documents:

Sections.
Paragraphs.
Tables.
Styles.

This reduces both development time and cognitive overhead.

2. Rich Feature Support

Common real-world requirements are handled natively:

Word → PDF / HTML / Image conversion.
Complex table layouts.
Headers, footers, styles.
Images and formatting.

3. Faster Development

Tasks that require dozens of lines in OpenXML can often be implemented in just a few lines here.

👉 This difference becomes more significant as document complexity increases.

Trade-offs to Consider

1. Licensing

Spire.Doc offers a free version with limitations:

Watermarks added to longer documents.
Some advanced features are restricted.

For production use, a commercial license is typically required.

2. Less Low-Level Control

Since the library abstracts away the XML layer, fine-grained control over document internals is more limited compared to OpenXML.

3. Dependency Size and Runtime Considerations

Larger package size than OpenXML.
Cold start impact in serverless or container environments.
Closed-source — debugging internal issues may be harder.

When It Makes Sense to Use Third-Party Libraries

This approach is often a better fit when:

You need document conversion (e.g., Word → PDF).
You are dealing with complex layouts or formatting.
You want to reduce development time.
Your project has a budget for commercial components.

In short, third-party libraries trade low-level control for productivity — and in many real-world applications, that trade-off is worth it.

Side-by-Side Comparison

The previous two sections walked through identical operations with both libraries. Here is a consolidated view across the dimensions that matter most for a production decision.

Feature Comparison

Feature	OpenXML SDK	Spire.Doc (Free)	Spire.Doc (Commercial)
Read / write `.docx`	✅	✅	✅
Template placeholder replace	✅ ⚠️	✅	✅
Table insertion	✅	✅	✅
Mail merge	❌	✅	✅
PDF export	❌	✅ ⚠️	✅
HTML export	❌	✅	✅
Image insertion	✅	✅	✅
Header / footer editing	✅	✅	✅
Document encryption	✅	✅	✅
Page limit	None	3 pages	None
Watermark on output	No	Yes (>3 pages)	No

⚠️ OpenXML SDK placeholder replacement requires manual run consolidation to handle split text nodes.

⚠️ Spire.Doc Free appends a watermark on documents exceeding 3 pages.

Technical Characteristics

Dimension	OpenXML SDK	Spire.Doc
License	MIT	Commercial (free tier available)
NuGet package size	~7 MB	~130 MB
.NET support	.NET 6 / 7 / 8 / Standard 2.0	.NET 6 / 7 / 8 / Standard 2.0
Linux / macOS support	✅	✅ ⚠️
Thread safety	✅ (per-instance)	❌ (per-request instantiation required)
PDF export	❌	✅
Source available	✅ (GitHub)	❌
Vendor support	Community / GitHub Issues	Commercial support included
Learning curve	High (OOXML knowledge required)	Low to medium

⚠️ Spire.Doc on Linux requires manual font installation for accurate rendering. Documents using fonts not present on the host system will fall back silently, which can affect PDF layout fidelity.

Operational Cost Comparison

This is the dimension developers most commonly overlook during library selection.

Cost factor	OpenXML SDK	Spire.Doc
Library license	Free	Free tier / paid commercial
PDF rendering	LibreOffice or equivalent required	Included
Infrastructure overhead	LibreOffice process management	None
Linux font setup	Not required	Required for non-Latin fonts
Debug ceiling	Full source	Public API only

The OpenXML SDK's zero license cost is real, but "free" does not account for the engineering time spent implementing PDF export, managing a LibreOffice process in containers, and handling edge cases in the OOXML object model. In a commercial project with a team of more than two developers, that time has a measurable cost.

Summary Recommendation

Neither library is categorically better.

If you are building a service where document processing is peripheral — one feature among many — Spire.Doc's higher-level API reduces the surface area of code you need to own and maintain. If document structure manipulation is central to your product and you need full visibility into the output, the OpenXML SDK gives you that control without any licensing constraints.

6. Performance & Scalability Considerations

When moving from prototypes to production systems, performance and scalability become critical factors — especially in high-load scenarios such as batch processing or document generation APIs.

Thread Safety

OpenXML SDK

The Open XML SDK is suitable for server-side use, but its document instances are not thread-safe and should not be shared across threads.

Each document must be handled within its own scope.
Avoid sharing document instances across threads.
Proper use of using blocks is essential to release resources.

👉 In practice, it works well in parallel processing as long as each task operates on its own file.

Spire.Doc

Spire.Doc is not thread-safe by design.

You should create a new Document instance per request.
Avoid reusing instances in multi-threaded environments.

👉 This is a common pattern for most document libraries, but it needs to be explicitly handled in high-concurrency systems.

Memory Usage

Memory consumption depends heavily on document size and complexity.

OpenXML SDK
- More lightweight in terms of dependencies.
- Gives you finer control over how data is processed.
- Can be optimized for streaming scenarios.
Spire.Doc
- Loads more structure into memory due to higher-level abstractions.
- Typically uses more memory for complex documents.

👉 For small to medium documents, the difference is usually negligible.
👉 For large files (e.g., 10MB+ with images and tables), memory usage becomes a factor worth testing.

Performance in Practice

In real-world scenarios:

OpenXML may perform better for simple, targeted operations (e.g., text replacement, metadata updates).
Spire.Doc often performs better for complex workflows, since it avoids manual XML manipulation.

👉 A key insight:

In most real-world systems, development time and maintainability matter more than raw execution speed.

Cold Start & Deployment Considerations

For modern deployments (e.g., Docker, serverless):

OpenXML SDK
- Smaller package size.
- Faster cold start.
- Minimal external dependencies.
Spire.Doc
- Larger DLL size.
- Slightly slower cold start in environments like AWS Lambda or Azure Functions.
- May require additional setup (e.g., fonts in Linux containers).

Summary

Use OpenXML when you need lightweight, controlled processing at scale.
Use Spire.Doc when you need feature-rich processing with less development overhead.

7. Common Pitfalls and Hidden Traps

No matter which approach you choose, there are a few non-obvious issues that can cause serious problems in production.

Here are some of the most common ones.

OpenXML SDK Pitfalls

1. Broken Documents Due to Relationship ID Conflicts

When adding images, styles, or other parts, each element is linked using a relationship ID (rId).

Hardcoding or reusing IDs can lead to corrupted files:

“Word found unreadable content…”

👉 Best practice:
Always use built-in methods to generate IDs instead of manually assigning them.

2. Text Replacement Isn’t as Simple as It Looks

In Word, text is often split across multiple Run elements.

So a placeholder like:

{{name}}

may actually be stored as:

{{na
me}}

👉 This breaks naive string replacement logic.

Solution:

Normalize runs before replacement.
Or use more robust search strategies.

3. Strict vs Transitional OOXML Compatibility

Not all .docx files follow the same OOXML standard.

Some use Strict.
Others use Transitional.

👉 This can lead to unexpected parsing or formatting issues.

Spire.Doc Pitfalls

1. Watermarks in Production

The free version of Spire.Doc adds watermarks to documents beyond certain limits.

This can easily slip into production if licensing is not configured properly.

👉 Best practice:
Load the license at application startup (e.g., via environment variables).

2. Font Issues in Linux Environments

When running in Docker or Linux containers, missing fonts can cause:

Garbled text.
Missing characters.
Layout inconsistencies.

👉 Solution:
Install necessary fonts in your container, for example:

apt-get install -y fonts-wqy-zenhei

3. Limited Debugging Visibility

Since the library is closed-source:

Internal processing is not visible
Debugging rendering or layout issues can be harder

👉 You may need to rely on documentation or vendor support.

Shared Pitfall: Security Risks (XXE)

Both approaches can be vulnerable when handling user-uploaded documents.

A common risk is XML External Entity (XXE) injection, which can lead to:

Data leakage
Remote file access

👉 Mitigation strategies:

Use secure XML parsing settings (e.g., prohibit DTD processing).
Validate and sanitize uploaded files.
Avoid processing untrusted documents directly.

Takeaway

Most issues don’t come from “wrong APIs” — they come from assumptions about how Word documents behave internally.

Understanding these pitfalls early can save hours of debugging and prevent production incidents.

8. Decision Guide: Which One Should You Choose?

At this point, the choice between the Open XML SDK and a third-party library like Spire.Doc should be clearer — but let’s make it more practical.

Instead of abstract comparison, here’s a simple decision flow based on real-world needs:

Quick Decision Flow

Do you need PDF or other format conversion?
→ Yes → Use a third-party library.
Do you have a budget for commercial components?
→ No → Use OpenXML (optionally combined with external tools like LibreOffice).
Is your document logic simple (e.g., text replacement, basic structure)?
→ Yes → OpenXML is sufficient.
Do you need to handle complex layouts, tables, or styling?
→ Yes → Third-party libraries will save significant time.
Are you targeting Linux containers or fully open-source stacks?
→ Yes → OpenXML is the safest choice.

Scenario-Based Recommendations

Scenario	Recommended Approach
Internal tools / scripts	OpenXML SDK
Open-source projects	OpenXML SDK
Commercial SaaS platforms	Third-party libraries
Document-heavy workflows	Third-party libraries
MVP with tight deadlines	Third-party libraries

A Flexible Approach (Best of Both Worlds)

In some projects, you don’t have to commit to a single solution.

A common strategy is to define an abstraction layer, for example:

public interface IWordProcessor
{
    void ReplaceText(string filePath, string key, string value);
    void InsertTable(string filePath, object data);
    void ExportToPdf(string inputPath, string outputPath);
}

👉 Then provide different implementations:

OpenXmlWordProcessor
SpireWordProcessor

This allows you to:

Start with one approach
Switch later if requirements change
Test performance or cost trade-offs

Final Thoughts on Choosing

There is no universally “better” solution.

OpenXML SDK is ideal when you need control, flexibility, and a free solution.
Third-party libraries are better when you need speed, features, and simpler development.

👉 The real decision comes down to this:

Are you optimizing for control, or for productivity?

9. Conclusion

Processing Word documents in C# can range from simple text manipulation to complex document generation pipelines.

The Open XML SDK gives you full control over the document structure, but requires a deeper understanding of OOXML and more development effort. Third-party libraries like Spire.Doc simplify most tasks and accelerate delivery, especially for feature-rich scenarios.

The difference isn’t just about APIs — it’s about how much complexity you’re willing to manage yourself.

If you're building production systems, choosing the right approach early can save significant time and effort down the line.

How to Convert Word to PDF in C# Without Microsoft Office (Fast & Server-Safe)

Jen — Mon, 16 Mar 2026 09:40:48 +0000

If you've ever tried to convert Word to PDF in C# using Microsoft Office Interop, you probably know the pain.

COM dependency issues, unstable server-side automation, and the requirement to install the full Microsoft Office suite just to perform document conversion.

This approach might work on a local machine, but it quickly becomes problematic in production environments:

Office automation is not recommended for server-side applications.
It introduces heavy dependencies.
It often causes performance and stability issues.

So what's the better way?

In this guide, we'll show how to convert Word documents to PDF in C# without installing Microsoft Office, using Spire.Doc for .NET - a lightweight .NET library designed for programmatic Word processing.

Why Spire.Doc for .NET for Word to PDF Conversion?

Before we write any code, let's address the obvious question: why Spire.Doc specifically?

Unlike Office automation, it allows developers to work with Word documents directly through a managed .NET API.

Here is a quick comparison of common approaches:

Feature	Spire.Doc	Word Interop	LibreOffice Headless
Office required	✅ None	❌ Full install	✅ None
Linux / Docker	✅ Yes	❌ No	✅ Yes (via CLI)
Conversion fidelity	✅ High	✅ High	⚠️ Variable
Server-side safe	✅ Yes	❌ Not recommended	⚠️ Via subprocess
Offline / air-gapped	✅ Yes	✅ Yes	✅ Yes
Latency	✅ In-process	🐢 Slow (COM)	🐢 Process spin-up
Cost model	One-time license	Office license	Free

The pattern is pretty clear. Word Interop is the go-to for desktop apps where Office is already present - but it's explicitly not recommended by Microsoft for server-side use. LibreOffice headless is a solid free option, but spawning a new process per conversion under load creates its own reliability headaches.

Spire.Doc hits the sweet spot for server-side automation: it's a single NuGet package, fully managed .NET, no external processes, no Office, no network calls.

This makes it a reliable solution for modern .NET applications.

💡Tip: Spire.Doc for .NET offers a free version for evaluation and small projects. A commercial license is required for full features and production use.

🚀 If your .NET application runs in Linux containers, make sure the libgdiplus package is installed. It provides the GDI+ compatibility layer required for document rendering.

Setup: Install Spire.Doc

Installation only takes a few seconds using NuGet.

PM> Install-Package Spire.Doc

Once installed, you're ready to start converting Word documents programmatically.

Basic Conversion - Word to PDF in C

Let's start with the simplest scenario: converting a .docx file to PDF.

using Spire.Doc;

namespace ConvertWordToPdf
{
    class Program
    {
        static void Main(string[] args)
        {
            Document doc = new Document();

            // Load a Word document
            doc.LoadFromFile("C:\\Users\\Tommy\\Desktop\\Sample.docx");

            // Save the document to PDF
            doc.SaveToFile("C:\\Users\\Tommy\\Desktop\\Sample.pdf", FileFormat.PDF);

            // Dispose resources
            doc.Dispose();
        }
    }
}

That's it.

Example output:

The code performs three steps:

Load the Word document into memory.
Render the document layout.
Export the rendered content as a PDF file.

Advanced Word to PDF Conversion Settings

The default conversion works well, but production systems often need more control over the output. Spire.Doc provides several options that allow developers to tune PDF generation for different scenarios.

Stream-based Conversion - for Web API responses

If you're building an API endpoint that returns a PDF download, writing to disk first is wasteful. Spire.Doc can write directly to any Stream, which means you can pipe the output straight to the HTTP response:

using Spire.Doc;

[HttpPost("convert")]
public IActionResult ConvertToPdf(IFormFile wordFile)
{
    if (wordFile == null || wordFile.Length == 0)
        return BadRequest("No file uploaded.");

    using var inputStream = wordFile.OpenReadStream();
    using var outputStream = new MemoryStream();
    using var doc = new Document();

    // Load from upload stream directly — no temp file needed
    doc.LoadFromStream(inputStream, FileFormat.Docx);
    doc.SaveToStream(outputStream, FileFormat.PDF);

    // Rewind before returning
    outputStream.Position = 0;

    return File(
        outputStream,  //
        "application/pdf",
        Path.GetFileNameWithoutExtension(wordFile.FileName) + ".pdf"
    );
}

Key Points Explanation:

doc.LoadFromStream(inputStream, FileFormat.Docx); - Loads Word document directly from upload stream, no temp file needed
doc.SaveToStream(outputStream, FileFormat.PDF); - Writes converted PDF directly to memory stream
outputStream.Position = 0; - Resets stream position before returning
return File(outputStream, "application/pdf", fileName); - Streams PDF directly to HTTP response

⚠️ Note on MemoryStream and large files: For documents under ~50 MB this pattern works fine. For larger files in high-throughput scenarios, consider writing to a FileStream on a temp path and streaming that back - holding very large documents in MemoryStream will put pressure on the LOH (Large Object Heap).

PDF output options - page size, image quality, font embedding

The default output is good, but Spire.Doc exposes a ToPdfParameterList object that gives you control over the most commonly tuned settings:

using Spire.Doc;
using Spire.Pdf;

namespace ConvertWordToPdf
{
    class Program
    {
        static void Main(string[] args)
        {
            Document doc = new Document();

            try
            {
                // Load a Word document
                doc.LoadFromFile(@"C:\Users\Tommy\Desktop\Sample.docx");

                // Create PDF parameter list for output options
                ToPdfParameterList pdfParams = new ToPdfParameterList();

                // 1. Set page size
                // Options: A1, A2, A3, A4, A5, Letter, Legal, etc.
                pdfParams.PdfPageSize = PdfPageSize.A4;

                // 2. Set image quality (0-100, higher = better quality, larger file size)
                pdfParams.ImageQuality = 80; // 80% quality, good balance

                // 3. Set font embedding
                pdfParams.IsEmbeddedAllFonts = true; // Embed all fonts for consistent display
                // Alternative: pdfParams.IsEmbeddedFonts = true; // Some versions use this

                // Optional: Set PDF conformance level (for long-term archiving)
                // pdfParams.PdfConformanceLevel = PdfConformanceLevel.Pdf_A1B;

                // Optional: Set compression level
                // pdfParams.CompressionLevel = PdfCompressionLevel.Best;

                // Save the document to PDF with custom parameters
                doc.SaveToFile(@"C:\Users\Tommy\Desktop\Sample.pdf", pdfParams);

                System.Console.WriteLine("PDF created successfully with custom options!");
            }
        }
    }
}

Code Explanation:

ToPdfParameterList - Object that configures PDF output settings like page size, image quality, and font embedding.
PdfPageSize.A4 - Sets the output page dimensions (A4, Letter, Legal, etc.).
ImageQuality = 80 - Controls image compression (0-100); 80 balances quality and file size.
IsEmbeddedAllFonts = true - Embeds all fonts to ensure cross-platform display consistency.

Batch conversion - process an entire folder

For report generation pipelines, scheduled exports, or migration jobs, you'll typically need to process multiple files. Here's a production-ready pattern with basic error isolation so one bad file doesn't abort the whole batch:

using Spire.Doc;
using System.IO;

class Program
{
    static void Main()
    {
        string sourceDir = @"C:\Users\Tommy\Desktop\WordFiles";
        string targetDir = @"C:\Users\Tommy\Desktop\PDFFiles";

        Directory.CreateDirectory(targetDir);

        foreach (string file in Directory.GetFiles(sourceDir, "*.docx"))
        {
            Document doc = new Document();
            doc.LoadFromFile(file);

            string pdfFile = Path.Combine(targetDir, 
                Path.GetFileNameWithoutExtension(file) + ".pdf");

            doc.SaveToFile(pdfFile, FileFormat.PDF);
            doc.Dispose();

            Console.WriteLine($"Convert: {Path.GetFileName(file)}");
          }
    }
}

Typical use cases include:

document archiving systems.
automated report generation.
contract processing pipelines.

Key Points Explanation:

Directory.CreateDirectory(targetDir); - Ensures output folder exists before saving files.
Directory.GetFiles(sourceDir, "*.docx") - Retrieves all Word documents from the source folder for batch processing.
Path.Combine(targetDir, ...) - Constructs output file path while preserving filename.
Path.GetFileNameWithoutExtension(file) + ".pdf" - Generates PDF filename by replacing the original extension.
Creating a new Document instance per file ensures resources are released and prevents memory buildup during large batch jobs

Real-World Scenarios: ASP.NET Core Web API

The most common server-side pattern: a client POSTs a .docx, gets a .pdf back in the same response. Here's a complete, production-ready controller:

using Microsoft.AspNetCore.Mvc;
using Spire.Doc;

[Route("api/[controller]")]
[ApiController]
public class WordToPdfController : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> Post(IFormFile file)
    {
        using var ms = new MemoryStream();
        await file.CopyToAsync(ms);
        ms.Position = 0;

        using var doc = new Document();
        doc.LoadFromStream(ms, FileFormat.Docx);

        using var pdf = new MemoryStream();
        doc.SaveToStream(pdf, FileFormat.PDF);
        pdf.Position = 0;

        return File(pdf, "application/pdf", "output.pdf");
    }
}

This approach is commonly used in:

document generation platforms.
SaaS reporting systems.
automated invoice processing.

Code Explanation:

[Route("api/[controller]")] and [ApiController] - Standard ASP.NET Core attributes that define the API endpoint and enable automatic model validation.
await file.CopyToAsync(ms); - Asynchronously copies uploaded file to memory stream for processing.
ms.Position = 0; and pdf.Position = 0; - Resets stream positions to beginning before reading or returning.
doc.LoadFromStream(ms, FileFormat.Docx); - Loads Word document directly from memory stream without saving to disk.
doc.SaveToStream(pdf, FileFormat.PDF); - Converts and writes PDF to memory stream.
return File(pdf, "application/pdf", "output.pdf"); - Streams PDF directly back to client as downloadable file.

Common Pitfalls Developers Hit When Converting Word to PDF

When implementing Word-to-PDF conversion in C# in production, there are a few common issues developers run into.

Missing Fonts on Linux ServersLinux

If your application runs on Linux, missing fonts can cause layout problems.

Install common fonts using:

sudo apt install fontconfig

You may also need to install additional font packages depending on your document templates.

Large Document Memory Usage

Large documents with high-resolution images can consume significant memory.

Possible solutions include:

reducing image resolution.
streaming processing pipelines.
batch processing instead of single large jobs.

Layout Differences

Some complex Word features (especially embedded objects) may render slightly differently in PDF.

Testing with real-world documents is always recommended.

Wrap-up

If you're building a C# application that needs Word-to-PDF conversion:

Avoid Microsoft Office Interop for server environments.
Use a dedicated document library like Spire.Doc for .NET.
Implement stream-based or batch processing for scalable systems.

With just a few lines of code, you can integrate reliable Word-to-PDF conversion into your .NET applications - without installing Microsoft Office.

DEV Community: Jen

How to Export Excel to PDF in .NET (Fast & Accurate Method)

Why Traditional Approaches Fall Short

What We Actually Need

Getting Started (Minimal Setup)

Basic Example: Export Entire Workbook to PDF

Advanced Excel to PDF Conversion Scenarios

Export a Specific Worksheet

Batch Export Multiple Worksheets

Export a Defined Print Area

Returning PDF in ASP.NET Core

Controlling Layout for Accurate Output

Page Size & Orientation

Margins

Scaling (the important one)

Common Issues & Fixes

Fonts render as squares or tofu characters

Charts or images missing from the PDF

Layout errors or crashes on Linux / Docker

Wrap-Up

OpenXML SDK vs Spire.Doc: Which One Should You Use for Word Processing in C#?

Understanding .docx and Server-Side Constraints

Why Server-Side Processing Adds Complexity

Option A: DocumentFormat.OpenXML SDK

Example 1: Read All Paragraph Text

Example 2: Replace Template Placeholders {{name}}

Example 3: Insert a Formatted Table

Limitations

1. Verbose and Low-Level API

2. Understanding Document Structure Is Required

3. No Built-in Rendering (e.g., PDF)

When OpenXML SDK Is the Right Choice

Option B: Using Third-Party Libraries (Spire.Doc)

Example 1: Read All Paragraph Text

Example 2: Replace Template Placeholders {{name}}

Example 3: Insert a Formatted Table

Example 4: Export to PDF

Limitations

1. Higher-Level API

2. Rich Feature Support

3. Faster Development

Trade-offs to Consider

1. Licensing

2. Less Low-Level Control

3. Dependency Size and Runtime Considerations

When It Makes Sense to Use Third-Party Libraries

Side-by-Side Comparison

Feature Comparison

Technical Characteristics

Operational Cost Comparison

Summary Recommendation

6. Performance & Scalability Considerations

Thread Safety

Memory Usage

Performance in Practice

Cold Start & Deployment Considerations

Summary

7. Common Pitfalls and Hidden Traps

OpenXML SDK Pitfalls

1. Broken Documents Due to Relationship ID Conflicts

2. Text Replacement Isn’t as Simple as It Looks

3. Strict vs Transitional OOXML Compatibility

Spire.Doc Pitfalls

1. Watermarks in Production

2. Font Issues in Linux Environments

3. Limited Debugging Visibility

Shared Pitfall: Security Risks (XXE)

Takeaway

8. Decision Guide: Which One Should You Choose?

Quick Decision Flow

Scenario-Based Recommendations

A Flexible Approach (Best of Both Worlds)

Final Thoughts on Choosing

9. Conclusion

How to Convert Word to PDF in C# Without Microsoft Office (Fast & Server-Safe)

Why Spire.Doc for .NET for Word to PDF Conversion?

Setup: Install Spire.Doc

Basic Conversion - Word to PDF in C

Advanced Word to PDF Conversion Settings

Stream-based Conversion - for Web API responses

Example 2: Replace Template Placeholders `{{name}}`

Example 2: Replace Template Placeholders `{{name}}`