DEV Community: Chloe

Why Excel Interop Is a Bad Idea for ASP.NET Applications

Chloe — Mon, 11 May 2026 07:38:53 +0000

What breaks in production — and what developers use instead

It usually starts with a simple requirement.

"Upload an Excel file, process it on the server, and export a report."

So you reach for Microsoft.Office.Interop.Excel. It's familiar. It's part of the Microsoft ecosystem. And it works — at least on your machine.

You open a workbook. You read a few cells. You write a test. Everything passes.

Then you deploy to production.

Within days, you start noticing things:

Excel processes quietly pile up in Task Manager, never exiting
Some requests hang indefinitely with no error, no timeout, no explanation
IIS recycles unexpectedly under moderate load
A background job that worked fine in staging fails intermittently
Deploying to a new server means installing Microsoft Office — and hoping the license key is somewhere

None of these failures are dramatic at first. They're subtle. They show up gradually. And by the time the pattern is obvious, they're already embedded in production infrastructure.

This is the Excel Interop trap. It looks like a solution. The API feels simple — until it becomes part of your production infrastructure.

1. What Is Excel Interop?
2. Why Excel Interop Fails on Servers
- 2.1 Microsoft Does Not Recommend It
- 2.2 Excel Requires a Desktop Environment
- 2.3 COM Objects Cause Memory Leaks
- 2.4 Not Thread-Safe
- 2.5 Incompatible with Modern Deployments
- 2.6 Security Concerns
3. What Developers Use Instead
4. Example: Reading Excel Files Without Interop
5. When Interop Still Makes Sense
6. How to Migrate Away from Interop
Conclusion

1. What Is Excel Interop?

Excel Interop is part of the Microsoft Office automation API, exposed through the Microsoft.Office.Interop.Excel namespace. It lets C# code control Excel the same way a human user would — opening workbooks, reading and writing cells, triggering formulas, running macros, and saving files.

Application excel = new Application();
Workbook workbook = excel.Workbooks.Open(@"C:\reports\data.xlsx");
Worksheet sheet = (Worksheet)workbook.Sheets[1];
string value = ((Range)sheet.Cells[1, 1]).Value?.ToString();

Under the hood, it works through COM Automation. Your .NET process doesn't parse the Excel file format directly — it launches a real Excel instance and sends instructions to it over the COM interface. Excel is running. It has a window (even if hidden). It manages its own memory, its own file handles, and its own process lifetime.

For desktop automation — a local tool that an individual runs interactively — this can work reasonably well.

For ASP.NET applications and server environments, it's a very different story.

2. Why Excel Interop Fails on Servers

The problems aren't edge cases. They're structural — and they compound each other in production.

2.1 Microsoft Does Not Recommend It

This isn't opinion. Microsoft has explicitly stated that Office Automation is unsupported in unattended server environments, including ASP.NET and Windows Services.

Office applications were built for interactive desktop use. When something breaks in production, you're not debugging a bug — you're operating outside the supported boundaries of the software itself.

2.2 Excel Requires a Desktop Environment

Calling new Application() doesn't open a file. It launches a full Excel process — with GUI infrastructure, user profile dependencies, and desktop session requirements that don't reliably exist on a server.

A Windows update, a Group Policy change, or a permission tweak can silently break everything overnight. The error messages are vague. The fix is never obvious.

2.3 COM Objects Cause Memory Leaks

Every Excel object you touch is a COM object that the .NET GC can't clean up on its own. Miss one Marshal.ReleaseComObject call — in an exception handler, inside a loop, in a helper method — and you get orphaned EXCEL.EXE processes that never exit.

// You have to do this manually. For every object. Every time.
Marshal.ReleaseComObject(range);
Marshal.ReleaseComObject(sheet);
Marshal.ReleaseComObject(workbook);
excel.Quit();
Marshal.ReleaseComObject(excel);

Over hours, these processes accumulate. Memory climbs. Files stay locked. Someone RDPs in and kills processes by hand.

If your production runbook includes "check for orphaned Excel processes," that's a sign something is fundamentally wrong.

2.4 Not Thread-Safe

ASP.NET processes requests concurrently. Excel Interop uses a Single-Threaded Apartment (STA) model and was never designed for concurrent access.

Under load, this means deadlocks, hanging requests, and IIS process recycling. You can add manual locking to serialize access — but then you've just built a bottleneck on top of a fragile foundation.

2.5 Incompatible with Modern Deployments

Excel Interop requires Windows, a full Office installation, and a valid license on every machine that runs your code — including CI/CD agents, staging servers, and auto-scaled instances.

There's no Docker image for this. A surprising number of modernization projects get blocked by a single Excel dependency.

2.6 Security Concerns

Three risks that are easy to overlook:

Macro and DDE execution — Excel may run embedded macros or DDE links in uploaded files, opening a code execution path on your server
Overprivileged process — the Excel process inherits your app pool identity, widening the blast radius of a malicious file
Temp file leakage — Excel writes AutoRecover and clipboard data to disk; in shared environments, this data can persist longer than expected

3. What Developers Use Instead

The important shift is this:

Modern libraries work with the Excel file format itself — not the Excel desktop application.

That means no COM automation, no hidden Excel processes, and no Office installation on the server.

The good news is that the .NET ecosystem already has several mature options for this.

Capability	Excel Interop	Modern Libraries
Requires Microsoft Office	Yes	No
Runs in Docker/Linux	No	Yes
COM Cleanup Needed	Yes	No
Designed for Server Use	Risky	Yes
Background Excel Processes	Yes	No

Here's a practical overview of the common ones.

Open XML SDK

Microsoft's official open-source library for reading and writing Office file formats. It gives you direct access to the underlying XML structure of .xlsx files.

Good for: developers who want full control over document structure and don't mind a lower-level API.

Worth knowing: the API is verbose. Simple operations — reading a cell value, writing a row — require significantly more code than you'd expect. For complex spreadsheets, it can become difficult to maintain.

EPPlus

One of the most widely used Excel libraries in the .NET ecosystem. The API is intuitive, the documentation is solid, and it handles most common spreadsheet operations cleanly.

Good for: teams that need a productive API and are comfortable with its licensing model.

Worth knowing: EPPlus moved to a commercial license for business use starting with version 5. It's still free for non-commercial projects, but production use in a commercial application requires a paid license.

NPOI

A .NET port of the Java Apache POI library. It's free, open-source, and supports both .xls and .xlsx formats.

Good for: teams migrating older codebases, or projects that need to support legacy .xls files alongside modern .xlsx.

Worth knowing: the API reflects its Java origins — it works, but it doesn't feel native to C#. Community activity has slowed in recent years.

Office-Independent Libraries

A category of libraries — including Spire.XLS and others — that implement Excel format support entirely in managed code, with no dependency on Office, COM, or Windows-specific APIs.

In practice, these libraries usually offer:

A higher-level API than Open XML SDK
Reliable behavior in server and containerized environments
Support for a wider range of Excel features out of the box

Good for: ASP.NET applications that generate reports, process uploaded files, or run scheduled export jobs in production — especially where deployment simplicity matters.

Worth knowing: some libraries in this category have per-developer or per-server licensing. Check the terms before committing to one for a commercial project.

Quick Comparison

Library	License	Office Required	.xls Support	API Level
Open XML SDK	MIT	No	No	Low
EPPlus	Commercial (v5+)	No	No	High
NPOI	Apache 2.0	No	Yes	Medium
Spire.XLS	Commercial	No	Yes	High

4. Example: Reading Excel Files Without Interop

Let's make this concrete. Here's the same task implemented two ways — first with Interop, then without it.

Scenario: an ASP.NET application receives an uploaded Excel file, reads the first sheet, and returns the value of cell A1.

The Interop Way

[HttpPost("upload")]
public IActionResult Upload(IFormFile file)
{
    var tempPath = Path.GetTempFileName() + ".xlsx";
    using (var stream = new FileStream(tempPath, FileMode.Create))
    {
        file.CopyTo(stream);
    }

    Application excel = null;
    Workbook workbook = null;
    Worksheet sheet = null;
    Range cell = null;

    try
    {
        excel = new Application();
        excel.Visible = false;
        workbook = excel.Workbooks.Open(tempPath);
        sheet = (Worksheet)workbook.Sheets[1];
        cell = (Range)sheet.Cells[1, 1];

        string value = cell.Value?.ToString();
        return Ok(value);
    }
    finally
    {
        if (cell != null) Marshal.ReleaseComObject(cell);
        if (sheet != null) Marshal.ReleaseComObject(sheet);
        if (workbook != null)
        {
            workbook.Close(false);
            Marshal.ReleaseComObject(workbook);
        }
        if (excel != null)
        {
            excel.Quit();
            Marshal.ReleaseComObject(excel);
        }
        System.IO.File.Delete(tempPath);
    }
}

This is the minimum viable version — and it's already fragile. Real production code usually ends up even more defensive than this. A single exception in the wrong place can prevent the cleanup code from running. The Excel process stays open. The temp file stays locked.

In production, under concurrent load, this gets worse fast.

Without Interop

Using Spire.XLS as an example — other libraries follow a similar pattern:

// Install-Package Spire.XLS
[HttpPost("upload")]
public IActionResult Upload(IFormFile file)
{
    if (file == null || file.Length == 0)
    {
        return BadRequest("No file uploaded.");
    }

    using var stream = file.OpenReadStream();

    var workbook = new Workbook();
    workbook.LoadFromStream(stream);

    var sheet = workbook.Worksheets[0];
    string value = sheet.Range["A1"].Text;

    return Ok(value);
}

No COM objects. No manual cleanup. No temp files. No Excel process running in the background.

The same result, in a fraction of the code — and it behaves predictably under concurrent load, inside a container, and on a Linux host.

The Pattern Holds for Writing Too

Reading is the simple case. Here's generating an Excel report and returning it as a download:

[HttpGet("report")]
public IActionResult DownloadReport()
{
    var workbook = new Workbook();
    var sheet = workbook.Worksheets[0];

    sheet.Range["A1"].Text = "Product";
    sheet.Range["B1"].Text = "Revenue";
    sheet.Range["A2"].Text = "Widget A";
    sheet.Range["B2"].NumberValue = 84500;

    using var stream = new MemoryStream();
    workbook.SaveToStream(stream, FileFormat.Version2016);

    return File(stream.ToArray(),
        "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
        "report.xlsx");
}

No installed Office. No cleanup ritual. Just code that does what it says.

Why This Matters Beyond the Code

The difference isn't just syntax. It's operational:

No Excel process means nothing to leak, nothing to orphan, nothing to kill
No Office dependency means the same code runs in dev, CI, staging, and production without special setup
Stream-based API means you can process uploaded files directly without writing to disk

Other libraries in the same category work on the same principles. The specific API differs, but the underlying advantage is the same: you're working with a file format, not remote-controlling a desktop application.

5. When Interop Still Makes Sense

It's worth being honest about this: Interop isn't always the wrong choice.

If you're building an internal desktop tool — one that runs on a machine where Office is already installed, used interactively by a single person, and never deployed to a server — Interop can be a reasonable option. You're using Excel as Excel was designed to be used.

Similarly, if your use case genuinely requires Excel-specific behavior that no file-format library supports — certain macro interactions, OLE embedding, or very specific rendering fidelity — Interop may be the only practical path.

The problem isn't the technology itself. It's the mismatch between what Interop was designed for and where it gets used.

For ASP.NET applications, background services, APIs, and anything that runs on a server or in a container, the mismatch is fundamental. The operational costs — fragile deployments, memory leaks, concurrency issues, licensing overhead — consistently outweigh the familiarity of the API.

6. How to Migrate Away from Interop

If Interop is already embedded in your codebase, a full rewrite isn't necessary. Most teams migrate incrementally — and that works well in practice.

A reasonable approach looks like this:

Identify Interop-heavy workflows — search for patterns like using Excel = Microsoft.Office.Interop.Excel or new Excel.Application(). These are reliable indicators of where Office automation is hiding in the codebase.
Wrap existing logic behind interfaces — don't rewrite Interop calls in place. Encapsulate them behind a service boundary first, so the replacement becomes a contained swap rather than a scattered refactor.
Replace operations incrementally — start with the highest-risk areas: anything in the ASP.NET request pipeline. Desktop utilities and internal tools can wait.
Validate file compatibility carefully — different libraries handle edge cases differently. Run your existing test files through the new implementation before switching over in production.
Load test under production-like conditions — concurrency issues that were masked by Interop's serialized behavior can surface during migration. Test early.

In practice, most Interop-heavy systems only use Excel for a handful of common tasks — reading uploads, generating reports, exporting spreadsheets — all of which modern libraries already handle well without launching Excel itself.

Conclusion

Excel Interop survives in production codebases for one reason: it works locally, and by the time the problems surface, it's already deeply embedded.

But the issues covered in this post aren't bad luck or misconfiguration. Orphaned processes, hanging requests, concurrency failures, deployment blockers — these are the predictable consequences of running a desktop application in a server environment. They don't go away with more careful coding. They go away when you stop using the wrong tool for the job.

The .NET ecosystem has mature, server-safe alternatives for working with Excel files. They're easier to deploy, easier to reason about, and they don't require a production runbook entry that says "kill orphaned Excel processes."

If you're starting fresh, the choice is straightforward. If you're maintaining existing code, the migration path is incremental — but the direction is worth committing to.

The spreadsheet may still be Excel. Your architecture doesn't have to be.

How to Merge PDFs in .NET Without Microsoft Office (Avoid Common Issues)

Chloe — Wed, 06 May 2026 09:57:18 +0000

Merging PDFs sounds simple — until you try to do it in a real-world .NET application running on a server.

Without a local desktop environment, approaches that rely on Microsoft Office quickly fall apart: licensing restrictions, deployment headaches, and poor performance under load make it a poor fit for server-side .NET applications.

That's usually the point where developers start looking for alternatives.

The good news is you don't need Office at all. Several dedicated .NET libraries handle PDF merging cleanly, without any Office dependency — and they give you far more control over the output.

In this guide, we'll walk through the practical side of merging PDFs in .NET: a working setup, the issues developers most commonly run into, and how to fix them.

A Clean Way to Merge PDFs in .NET

When merging PDFs in a .NET application—especially on the server—the biggest challenge isn't writing the code itself. It's making sure the solution is reliable, scalable, and doesn't depend on external software like Microsoft Office.

A more robust approach is to use a dedicated .NET PDF library that works independently of Office. This avoids common deployment issues and makes your solution suitable for environments like ASP.NET Core, Docker containers, or cloud services.

In this article, we'll use Spire.PDF for .NET as an example to demonstrate the process. The main reasons are:

It works completely without Microsoft Office
The API is straightforward and easy to integrate
It handles common PDF merging scenarios (including large files and complex documents)

That said, the approach shown here isn't limited to a single library. The same concepts apply to most modern .NET PDF libraries—you just need one that is stable, server-friendly, and doesn't introduce licensing or deployment complications.

In the next section, we'll walk through the simplest way to merge PDFs in C# with a minimal, working example.

Getting Started with Spire.PDF

Install the library

Install Spire.PDF via NuGet with a single command:

dotnet add package Spire.PDF

Or search for Spire.PDF in the Visual Studio NuGet Package Manager.

Basic PDF Merging - C# Sample

Here's the simplest way to merge PDFs in C#:

using Spire.Pdf;

namespace MergePDFs
{
    class Program
    {
        static void Main(string[] args)
        {
            // Specify the PDF files to be merged
            string[] files = new string[] {"sample0.pdf", "sample1.pdf", "sample2.pdf"};

            // Merge PDF files 
            PdfDocumentBase pdf = PdfDocument.MergeFiles(files);

            // Save the result file
            pdf.Save("MergePDF.pdf", FileFormat.PDF);
        }
    }
}

What's happening here:

PdfDocument.MergeFiles() method to merge multiple PDFs into a single file.
pdf.Save writes the merged document to disk in PDF format.

Common Issues & Solutions

Even with a straightforward API, PDF merging can go wrong in a few predictable ways. This section covers the most common ones — starting with the issues that tend to cause the most confusion.

Issue 1: Corrupted Output File

The merged file is generated, but when you try to open it, your PDF reader throws an error — or the file size looks suspiciously small.

Why does this happen

The most common cause is that SaveToFile() or Close() was never called — or was called in the wrong order. If the program exits or throws an exception before the file is properly finalized, the output will be incomplete.

How to fix it

Always release resources after use.

sourceDocument.Close();
mergedDocument.Close();

👉 Tip: Use using statements where possible to ensure proper disposal.

Issue 2: Missing Fonts or Layout Issues

Text in the merged PDF appears garbled, substituted with a fallback font, or missing entirely — even though the original files looked fine.

Why does this happen

PDFs may reference fonts without embedding them. When those fonts aren’t available in the runtime environment, the merged result can display incorrectly.

How to fix it

The most reliable solution is to ensure fonts are embedded in the source PDFs before merging. This guarantees consistent rendering across environments.

If you don’t control the source files, process and merge them using a consistent environment, and avoid relying on system-installed fonts.

PdfDocument mergedDocument = new PdfDocument();

foreach (string file in inputFiles)
{
    PdfDocument temp = new PdfDocument(file);
    mergedDocument.AppendPage(temp);
    temp.Close();
}

mergedDocument.SaveToFile(outputFile);
mergedDocument.Close();

👉 In production, always test with real-world documents—not just simple PDFs.

Issue 3: Out of Memory When Merging Large Files

The merge works fine for small files, but throws a System.OutOfMemoryException — or causes noticeable memory pressure — when the input files are large or numerous.

Why does this happen

By default, loading a PdfDocument reads the entire file into memory. If you're merging ten 50MB PDFs, you're potentially holding 500MB in memory at once — before the output document is even written.

How to fix it

Process files one at a time and release each one before loading the next. Avoid holding all source documents open simultaneously:

PdfDocument merged = new PdfDocument();

foreach (string file in inputFiles)
{
    using (FileStream fs = new FileStream(file, FileMode.Open, FileAccess.Read))
    {
        PdfDocument temp = new PdfDocument(fs);
        merged.AppendPage(temp);
        temp.Close();
    }
}

merged.SaveToFile(outputFile);
merged.Close();

Going further

For very large batches, consider merging in chunks — combine files in groups of 5–10, write each chunk to a temp file, then do a final merge of the temp files. This keeps peak memory usage bounded regardless of input size.

Other Common Issues

Form fields and annotations disappear after merging
By default, merging flattens interactive elements. If you need to preserve form fields, set merged.FileInfo.IncrementalUpdate = true before appending pages, or explicitly copy the AcroForm structure from each source document.

Password-protected PDFs fail to merge
Spire.PDF will throw an exception if it encounters an encrypted file without credentials. Load protected files with the password explicitly: new PdfDocument(file, "yourpassword") — then append as normal.

Pages come out in the wrong order
This is almost always a file list ordering issue, not a library bug. Sort your input array explicitly before merging rather than relying on filesystem or directory enumeration order, which varies by OS and environment.

Advanced Scenarios

Once basic merging is working reliably, there are a few common extensions worth knowing about. You don’t need all of these for basic use—pick what fits your scenario.

Here's a minimal example you can copy and run:

Merging Specific Pages Only

Sometimes you don't need the entire document — just merge a range of pages from each source file.

using Spire.Pdf;

// Load source PDFs
PdfDocument[] pdfs = new PdfDocument[]
{
    new PdfDocument("sample0.pdf"),
    new PdfDocument("sample1.pdf"),
    new PdfDocument("sample2.pdf")
};

// Create merged document
PdfDocument newPDF = new PdfDocument();

// Insert selected pages
newPDF.InsertPageRange(pdfs[0], 1, 2);  // Pages 1-2 from first PDF
newPDF.InsertPage(pdfs[1], 0);          // First page from second PDF
newPDF.InsertPage(pdfs[2], 1);          // Second page from third PDF

// Save result
newPDF.SaveToFile("SelectivePageMerging.pdf");

This is useful when you're pulling specific sections from multiple reports into a single summary document.

Adding a Watermark During Merge

If you need to stamp each page with a watermark — a company name, "CONFIDENTIAL", a draft label — the merge step is a natural place to do it.

using Spire.Pdf;
using Spire.Pdf.Graphics;
using System.Drawing;

// Merge
var merged = PdfDocument.MergeFiles(new[] { "doc1.pdf", "doc2.pdf", "doc3.pdf" });
string tempPath = Path.GetTempFileName();
merged.Save(tempPath);
merged.Close();

// Add watermark
using (var pdf = new PdfDocument())
{
    pdf.LoadFromFile(tempPath);
    var font = new PdfTrueTypeFont(new Font("Arial", 50f, FontStyle.Bold), true);

    foreach (var page in pdf.Pages)
    {
        page.Canvas.SetTransparency(0.5f);
        page.Canvas.TranslateTransform(page.Canvas.Size.Width / 2, page.Canvas.Size.Height / 2);
        page.Canvas.RotateTransform(-45);
        page.Canvas.DrawString("CONFIDENTIAL", font, PdfBrushes.DarkGray, -150, -25);
        page.Canvas.SetTransparency(1f);
    }

    pdf.SaveToFile("merged_with_watermark.pdf");
}

File.Delete(tempPath);

Adjust the transparency, font size, and position to suit your layout.

Adding Page Numbers After Merging

Page numbers should reflect the final document, not the originals — so add page numbers after the merge is complete.

using Spire.Pdf;
using Spire.Pdf.Graphics;

// Merge
var merged = PdfDocument.MergeFiles(new[] { @"D:\doc1.pdf", @"D:\doc2.pdf", @"D:\doc3.pdf" });
string temp = Path.GetTempFileName();
merged.Save(temp, FileFormat.PDF);
merged.Close();

// Add numbers
using (var pdf = new PdfDocument())
{
    pdf.LoadFromFile(temp);
    var font = new PdfTrueTypeFont(new Font("Arial", 9f), true);
    int total = pdf.Pages.Count;

    for (int i = 0; i < total; i++)
    {
        var page = pdf.Pages[i];
        string text = $"Page {i + 1} of {total}";
        float x = page.Canvas.ClientSize.Width - font.MeasureString(text).Width - 50f;
        page.Canvas.DrawString(text, font, PdfBrushes.Black, x, page.Canvas.ClientSize.Height - 50f);
    }

    pdf.SaveToFile(@"D:\numbered_merged.pdf");
}

File.Delete(temp);

Exposing Merge as an ASP.NET Core API Endpoint

If you're building a service that accepts PDF uploads and returns a merged file, here's a minimal endpoint structure:

app.MapPost("/merge-stream", async (HttpRequest request) =>
{
    var files = request.Form.Files;
    if (files.Count < 2)
        return Results.BadRequest("At least two files are required.");

    PdfDocument merged = new PdfDocument();

    try
    {
        foreach (var file in files)
        {
            using var stream = file.OpenReadStream();
            // Load PDF from stream
            using var tempDoc = new PdfDocument(stream);

            // Insert all pages
            for (int i = 0; i < tempDoc.Pages.Count; i++)
            {
                merged.InsertPage(tempDoc, i, i);
            }
        }

        using var output = new MemoryStream();
        merged.SaveToStream(output);
        merged.Close();

        output.Position = 0;
        return Results.File(output.ToArray(), "application/pdf", "merged.pdf");
    }
    catch (Exception ex)
    {
        merged.Close();
        return Results.Problem($"Error merging PDFs: {ex.Message}");
    }
});

A few things to keep in mind for production use:

Validate file types before processing
Set a reasonable size limit per upload
Consider running the merge in a background job for large files rather than blocking the request thread

Async Batch Processing for Large Volumes

For pipelines that process many files at once, avoid blocking threads on I/O. Here's a simple async wrapper:

public async Task<byte[]> MergePdfsAsync(IEnumerable<string> filePaths)
{
    // Since Spire.PDF's MergeFiles doesn't support async I/O,
    // you can omit the async wrapper in practice, or just add a caching layer
    return await Task.Run(() =>
    {
        var filesArray = filePaths.ToArray();

        // Use the officially recommended MergeFiles method
        using var mergedDocument = PdfDocument.MergeFiles(filesArray);

        using var output = new MemoryStream();
        mergedDocument.SaveToStream(output);
        mergedDocument.Close();

        return output.ToArray();
    });
}

For high-throughput scenarios, pair this with a queue (e.g., Azure Service Bus or a simple [Channel<T>](https://learn.microsoft.com/en-us/dotnet/core/extensions/channels)) to process merge jobs one at a time rather than in parallel — PDF merging is memory-intensive enough that concurrency can backfire.

Alternative Libraries

Spire.PDF works well for the scenarios covered in this guide, but it's not the only option. Depending on your project's requirements — licensing, budget, or specific feature needs — one of these alternatives may be a better fit.

Library	License	Highlights	Best For
Spire.PDF	Commercial (free tier available)	Clean API, good documentation, server-friendly	General-purpose merging, teams that want a supported library
iText 7	AGPL / Commercial	Industry standard, highly capable, large community	Complex PDF manipulation, enterprise projects with commercial license
PDFsharp	MIT	Lightweight, no cost, simple API	Open-source projects, basic merging without advanced requirements
PdfPig	Apache 2.0	Fully open-source, actively maintained	Reading and extracting PDF content, lightweight merging
Aspose.PDF	Commercial	Feature-rich, excellent format support	Teams that need broad format coverage and vendor support

👉 Quick recommendation:

Use Spire.PDF for ease of use and quick integration.
Use iText 7 if licensing is not an issue.
Use PDFsharp for simple open-source scenarios.

Each of these libraries can handle PDF merging—the right choice depends on your licensing constraints and how complex your use case is.

Conclusion

Merging PDFs in .NET is straightforward—until real-world constraints come into play.

By using a library that doesn't depend on Microsoft Office and understanding the common pitfalls, you can build a solution that's both reliable and production-ready.

Once you have the basics in place, you can extend the same approach to more advanced scenarios like batching, APIs, or document workflows.

Start with a simple merge, validate it with real-world files, and build from there.

Best .NET PDF Libraries in 2026: Free vs Paid (What Actually Works)

Chloe — Mon, 27 Apr 2026 03:38:54 +0000

It usually starts with something simple:

"We just need to export a PDF."

Sounds straightforward. Until it isn't.

At first, everything seems fine. You pick a library, write a few lines of code, and get a PDF output. Done.

Then the real problems begin.

Not in development — but the moment you deploy.

The layout looks completely different from your HTML.
Fonts are missing or rendering incorrectly.
It works on your machine… but fails in Docker or Linux.
Performance drops when processing larger files.
And suddenly, licensing becomes a concern you didn't plan for.

What felt like a quick task turns into a series of unexpected trade-offs.

The truth is, choosing a PDF library in .NET isn't about features — it's about what actually works in production.

In this article, we'll take a practical look at some of the most popular .NET PDF libraries in 2026, compare free and paid options, and — more importantly — help you figure out which one actually fits your use case.

The Real Problem — Why Choosing a PDF Library Is Harder Than It Looks

On the surface, most PDF libraries look similar: create documents, add text, insert images, maybe even support HTML rendering.

But in practice, the differences start to matter very quickly.

The challenge isn't generating a PDF — it's generating the right PDF, under real-world conditions.

Here are a few trade-offs developers often run into:

Feature Complexity vs. Simplicity

Some libraries give you full control over every element — layout, positioning, rendering.
That's powerful, but it also means more code, more setup, and a steeper learning curve.

Others are much easier to use, but become limiting once your requirements grow beyond simple documents.

HTML Rendering vs. Manual Layout

If your PDFs are based on existing HTML (invoices, reports, web pages), HTML-to-PDF support becomes critical.

But not all libraries handle this well.

Some don't support HTML at all.
Some only support partial or inconsistent rendering.
Others rely on embedded browsers, which introduces performance and deployment considerations.

Local Development vs. Production Environments

This is where a lot of library choices fall apart in practice.

Common issues include:

Missing system dependencies in Linux or Docker.
Font rendering differences.
Headless environment limitations.
Unexpected crashes under load.

Free vs. Paid — More Than Just Cost

At first glance, the decision seems simple: use a free library if possible.

But "free" often comes with trade-offs:

Limited features.
More time spent on implementation.
Licensing restrictions (especially for commercial use).

On the other hand, paid libraries usually offer more complete solutions — but introduce cost and vendor dependency.

All of this leads to one important conclusion:

There is no universally "best" PDF library in .NET — only the one that best fits your specific use case.

Free vs Paid — What's the Actual Difference?

At some point, almost every developer asks the same question:

"Can I just use a free library?"

The answer is: yes — but it depends on what you need.

The difference between free and paid PDF libraries isn't just about cost. It's about where you spend your effort.

🟢 Free / Open-Source Libraries

Free libraries are often the first choice — and for good reason.

They're accessible, flexible, and backed by active communities.

What they do well:

No upfront cost.
Full control over implementation.
Suitable for simple or well-defined use cases.

Where they get challenging:

Limited or no HTML-to-PDF support.
More manual work (layout, pagination, styling).
Inconsistent behavior across environments.
Licensing constraints (e.g., AGPL in some cases).

In practice, they work best when:

You're generating structured documents (reports, invoices).
You don't rely heavily on HTML rendering.
You're okay investing more development time.

🔵 Paid / Commercial Libraries

Commercial libraries take a different approach: they aim to solve the entire problem out of the box.

Instead of building everything yourself, you get a more complete toolkit.

What they do well:

Reliable HTML-to-PDF rendering.
Better handling of fonts, layouts, and pagination.
Consistent behavior across environments (Windows, Linux, Docker).
Dedicated support and documentation.

Trade-offs to consider:

Licensing cost.
Vendor lock-in.
Sometimes heavier dependencies.

They're typically a better fit when:

You need production-ready stability.
You're building backend services or automation pipelines.
Time-to-market matters more than implementation flexibility.

The Real Trade-Off

This is where most comparisons miss the point.

It's not:

Free vs Paid

It's actually:

Time vs Money

In most real-world projects, you don't really choose a library — you choose your trade-offs.

Free libraries often save money upfront, but require more engineering effort.

Paid libraries cost more initially, but can significantly reduce development time and risk.

If you're building something quick or highly customized, a free library might be enough.

But if you're building something that needs to run reliably in production, the decision becomes less about cost — and more about stability.

Library Breakdown — What Actually Works

Enough context. Let's get into the libraries themselves.

Before we dive into specific libraries, one important note: what follows isn't a rehash of each library's feature page. It's an honest assessment of where each one shines, where it struggles, and what kind of project it's actually suited for.

🟢 Open-Source Options

QuestPDF

QuestPDF is probably the most exciting thing to happen to .NET PDF generation in recent years. It takes a code-first, Fluent API approach — you describe your document structure in C#, and it renders it precisely and consistently.

The results are clean, the API is genuinely pleasant to work with, and it handles things like pagination and repeating headers without the usual pain. For structured documents — invoices, financial reports, delivery notes — it's hard to beat at any price.

The limitation is equally clear: QuestPDF doesn't do HTML rendering. If your documents are driven by Razor templates or existing HTML/CSS, this isn't your tool. You'll be rebuilding your layout in C# from scratch, which is a significant investment depending on complexity.

👍 Beautiful Fluent API, precise layout control, great for structured docs.
👎 No HTML support, requires code-based layout for everything.
✅ Best for: Invoices, reports, any document with a predictable structure.

PDFsharp

PDFsharp is the "old reliable" of the .NET open-source PDF world. It's been around for years, it's lightweight, and it does what it says.

That said, it's showing its age. The API is lower-level than modern alternatives, documentation is sparse, and complex layout work requires a lot of manual effort. It's not a library you'd choose for a serious production system in 2026 — but for simple one-off PDFs or quick prototypes, it gets the job done without ceremony.

👍 Lightweight, no frills, easy to get started.
👎 Low-level API, limited features, not actively developed.
✅ Best for: Simple PDF generation, quick prototypes, low-complexity needs.

iText 7 (AGPL)

iText is the most powerful open-source PDF library in the .NET ecosystem — and also the most misunderstood.

The functionality is exceptional. Fine-grained control over PDF structure, solid form handling, digital signatures, PDF/A compliance — if you need to do something with a PDF, iText can probably do it. The API has a learning curve, but it rewards the investment.

The real issue is the license. iText 7 is released under AGPL, which requires any software using it to also be open-sourced under AGPL. For commercial applications, that's almost certainly not acceptable — which means you'd need their commercial license, at which point it's no longer a "free" option.

Use it for open-source projects freely. For everything else, price out the commercial license before you build anything on top of it.

👍 Extremely powerful, precise PDF control, handles complex requirements.
👎 AGPL license is a serious constraint for commercial projects.
✅ Best for: Open-source projects, or commercial projects with budget for the paid license.

🔵 Commercial Options

IronPDF

If your primary use case is converting HTML to PDF, IronPDF is hard to ignore. It's built on Chromium, which means what you get out is very close to what a real browser would render — CSS, web fonts, JavaScript-rendered content, all of it.

For teams that maintain their document templates as HTML and want pixel-accurate output, that's a genuinely compelling proposition.

The tradeoff is resource usage. Chromium is not a lightweight dependency. Cold start times are noticeable, memory footprint is higher than other options, and in high-throughput scenarios you'll need to think carefully about how you manage instances. It's not a dealbreaker, but it's something to test against your actual load before committing.

👍 Best-in-class HTML rendering, near-perfect browser fidelity.
👎 High resource usage, slower cold starts, heavier infrastructure footprint.
✅ Best for: HTML-heavy documents, web page to PDF conversion, template-driven output.

Aspose.PDF

Aspose is the enterprise choice — and it earns that label in both directions.

The feature set is genuinely comprehensive: PDF generation, editing, conversion to and from dozens of formats, OCR, digital signatures, PDF/A and PDF/UA compliance, redaction. If you have a complex document processing requirement, Aspose almost certainly supports it. The library is mature, well-maintained, and the documentation is thorough.

The cost reflects that. Aspose is among the most expensive options in this space, and the API can feel heavy for simpler use cases. If you're building a straightforward report generator, it's more library than you need.

But for large-scale systems where document processing is a core part of the product — legal platforms, financial systems, document management pipelines — the investment tends to pay off. You're not going to hit a wall with Aspose.

👍 Most complete feature set, enterprise-grade reliability, extensive format support.
👎 Highest price point, API complexity, more than most projects need.
✅ Best for: Enterprise systems, complex document workflows, organizations with serious compliance requirements.

Spire.PDF

Spire.PDF sits in an interesting position: it's not the flashiest option, and it doesn't get talked about as much as IronPDF or Aspose — but in practice, it quietly handles a lot of real-world scenarios well.

HTML to PDF conversion is stable and doesn't require a full browser engine. The API is straightforward without being simplistic. It runs cleanly on Linux and inside Docker containers without needing special configuration — which is exactly where some browser-based solutions start to show friction, usually at the worst possible time: during deployment.

It won't win any design awards for its API, but for backend automation — generating documents server-side, processing PDFs in bulk, integrating into pipelines — it's a practical, reliable choice that won't surprise you in production.

👍 Stable HTML to PDF, clean Linux/Docker support, straightforward API.
👎 Less community presence, not as well known as larger alternatives.
✅ Best for: Server-side automation, backend document generation, Docker-based deployments.

Comparison Table

If you just want the quick answer, here's how they compare:

Library	HTML to PDF	License	Ease	Performance	Deployment	Best For
QuestPDF	❌	MIT	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Structured reports, invoices
PDFsharp	❌	MIT	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	Simple PDF generation
iText	⚠️ Partial	AGPL / Paid	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	Advanced PDF control
IronPDF	✅	Commercial	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	HTML to PDF (web content)
Aspose	✅	Commercial	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Enterprise-level solutions
Spire.PDF	✅	Commercial	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Automation, backend services

A few notes on the table:

HTML to PDF — ⚠️ on iText means partial support exists but isn't a core strength. Don't build an HTML-driven workflow around it without testing first. ⚠️ on IronPDF for Linux/Docker means it works, but requires more setup than other options — Chromium dependencies need to be explicitly handled in your container.

So… Which One Should You Choose?

If you don’t want to overthink it, here's the short version:

👉 You need to generate structured documents — invoices, reports, statements

Go with QuestPDF

Clean API
Great layout control
No need for HTML

👉 Your documents are HTML-based and you need accurate rendering

Go with IronPDF if output fidelity is the priority and you can absorb the resource overhead.
If you're running in a lightweight backend environment and need something more predictable, Spire.PDF is worth evaluating — the rendering isn't browser-identical, but it's consistent and far less demanding on infrastructure.

👉 You need complete control over PDF internals — signatures, compliance, low-level manipulation

Go with iText

Powerful but complex
Best for advanced scenarios

👉 You're building backend automation — bulk generation, scheduled jobs, document pipelines

Go with a commercial library (Spire, IronPDF, Aspose)

More stable across environments
Less time spent debugging edge cases

👉 You just need something simple and fast

Go with PDFsharp

Lightweight
Easy to set up
Good enough for basic tasks

Real-World Advice — What the Docs Won't Tell You

By this point, the differences between libraries should be clearer. But in practice, a few factors matter more than anything listed in a feature comparison.

1. Don't choose based on features alone

Most libraries claim to support similar things.
The real difference shows up when you run them in production.

2. Test in your actual environment early

Especially if you're deploying to:

Linux
Docker
Cloud environments

What works locally may not work there.

3. Pay attention to licensing

This is often overlooked - until it becomes a problem.

Some "free" libraries have strict licenses (like AGPL)
Commercial use may require purchasing a license

4. Start with a small proof of concept (POC)

Before committing to a library, try:

Rendering a real document
Testing performance
Checking output consistency

A few hours of testing can save days of refactoring later.

5. Think long-term, not just quick wins

The wrong library usually doesn't fail immediately — it fails when you scale.

Closing Thoughts

There's no perfect PDF library for .NET. There's only the right one for what you're actually building.

If this article has a single takeaway, it's this: start with your constraints, not the feature list. Your deployment environment, your license requirements, your document structure, your team's capacity — those filters will do most of the work for you. By the time you've answered those questions honestly, the shortlist usually writes itself.

If you're working on document generation or automation in .NET, taking the time to choose the right library early can save you a lot of trouble later.

And in the end, the best PDF library isn't the most powerful one — it's the one that keeps working when everything else starts to break.

Why Microsoft Office Interop Fails for PDF Generation in .NET (And What to Use Instead)

Chloe — Tue, 21 Apr 2026 01:59:09 +0000

Microsoft Office Interop is still widely used for PDF generation in .NET because it feels like a quick win. It works on a local machine, requires minimal code, and produces accurate results by leveraging Microsoft Office itself.

The problems start in production. Applications begin to hang, background processes like WINWORD.EXE accumulate, and stability degrades under load—not because of application logic, but because Interop was built for desktop automation rather than server-side workloads.

Built for desktop automation, Interop depends on a GUI environment and system states that don’t exist in modern backend architectures. This article explains why it fails—and what to use instead.

What Is Microsoft Office Interop (And Why It's So Common)

Microsoft Office Interop is a set of .NET assemblies that allow applications to automate Microsoft Office programs such as Word and Excel. In the context of PDF generation, it is often used to open a document and export it directly to PDF using the built-in capabilities of Office.

Its popularity comes from a few practical advantages. First, it feels familiar—developers are effectively controlling tools they already know. Second, the API surface is relatively straightforward, making it easy to get a working solution with minimal code. And because the output is generated by Microsoft Office itself, the formatting accuracy is typically high.

This combination makes Interop especially appealing for quick implementations or internal tools. However, the same characteristics that make it convenient during development can become limitations once the application is deployed to a production environment.

Why Interop Fails in Production

The issues with Microsoft Office Interop are not incidental—they are a direct result of its design.

The core problems fall into a few categories:

Fundamentally Not Designed for Server Environments

Interop doesn't just use Office — it is Office. Every API call drives a full desktop application running in the background. Microsoft's own documentation explicitly states that Office is not designed for unattended server-side execution and is unsupported in that context.

Server environments don't have desktop sessions, logged-in users, or displays. Interop assumes all three. When those assumptions break, dialog boxes appear with no one to dismiss them, file pickers block indefinitely, and processes stall waiting for input that never comes.

Requires Microsoft Office Installation (Hard Dependency)

Every machine that runs your code needs a licensed Office installation — your web server, your build agent, your Docker container. In practice this means two problems: you can't containerize cleanly, and version inconsistencies between Office 2019 and Microsoft 365 mean the same document can render differently across environments.

Stability Issues (COM Lifecycle Complexity)

COM objects don't clean themselves up. Every Document and Application object needs explicit Marshal.ReleaseComObject() calls. Miss one, and the Office process keeps running after your code exits.

finally
{
    if (doc != null) Marshal.ReleaseComObject(doc);
    if (app != null) { app.Quit(); Marshal.ReleaseComObject(app); }
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

Even this pattern isn't bulletproof. Under certain error conditions the process still doesn't exit, and orphaned WINWORD.EXE instances accumulate quietly until the server runs out of memory. Interop is also not thread-safe — in a multi-threaded web server, race conditions are a matter of when, not if.

Poor Scalability (Process-Per-Request Model)

Each conversion request starts a new Office instance. Under any real load, this means multiple full Office processes running simultaneously, each consuming hundreds of megabytes. Batch processing is no better — failures become silent and unpredictable once you're iterating over large file sets.

Interop works fine for demos — but breaks under real production workloads.

What a Modern PDF Solution Should Provide

A production-ready PDF solution should meet the expectations of modern backend applications:

No Office dependency — a NuGet package, nothing more
Server environment support — ASP.NET Core, Docker, Linux, no display required
Stability under load — bounded memory, no process leaks, thread-safe
Clean .NET API — idiomatic C#, no COM artifacts
Streaming and batch support — MemoryStream for web APIs, stable iteration for batch jobs

These requirements reflect how applications are built and deployed today—and highlight why Interop struggles in these scenarios.

The Landscape: Standalone .NET PDF Libraries

Library	Strengths	Limitations
iText 7	Feature-complete, large community	AGPL — commercial use requires paid license
PdfSharp + MigraDoc	Fully open source	Weak Word conversion support
QuestPDF	Elegant fluent API for building documents	Weak support for converting existing Word/Excel files
Spire.Doc / Spire.PDF for .NET	No Office dependency, reliable conversion, cross-platform	Free tier has page limit
Puppeteer	Flexible HTML→PDF	Heavy runtime (browser dependency)

Different tools fit different scenarios. For generating PDFs from scratch, libraries like QuestPDF offer a clean developer experience. For HTML-based workflows, headless browsers provide flexibility.

However, when the requirement is reliable server-side conversion of existing Word or Excel documents, the priorities change: no Office dependency, consistent behavior across environments, and stable performance under load. This is where standalone libraries designed specifically for backend processing, like Spire.Doc and Spire.PDF for .NET, become the most practical choice. In practice, different libraries handle different parts of the workflow—for example, Spire.Doc for Word-to-PDF conversion and Spire.PDF for creating or manipulating PDF documents directly.

Practical Examples: Interop vs a Modern Approach

These limitations become obvious when you compare Interop with modern libraries in real-world scenarios.

Scenario A: Creating a PDF Report from Scratch

While Interop isn't typically used for creating PDFs from scratch, this comparison highlights how different the programming models are.

❌ Using Interop

var app = new Microsoft.Office.Interop.Word.Application();
var doc = app.Documents.Add();
var para = doc.Paragraphs.Add();
para.Range.Text = "Quarterly Report";
doc.SaveAs2(outputPath, WdSaveFormat.wdFormatPDF);
doc.Close();
app.Quit();
Marshal.ReleaseComObject(doc);
Marshal.ReleaseComObject(app);

Even for a simple document, you're launching a full Office instance, managing COM object lifecycles manually, and hoping nothing throws before the cleanup code runs.

This approach is error-prone and difficult to maintain in backend code.

✅ Using Spire.PDF

PdfDocument pdf = new PdfDocument();
PdfPageBase page = pdf.Pages.Add();
PdfTrueTypeFont font = new PdfTrueTypeFont(new Font("Arial", 14f));
PdfBrush brush = PdfBrushes.Black;
page.Canvas.DrawString("Quarterly Report", font, brush, 10, 10);
pdf.SaveToFile("report.pdf");

Creating PDFs becomes a straightforward, in-process operation.

Scenario B: Converting Existing Documents to PDF

This is where Interop causes the most production pain. The typical implementation looks like this:

❌ Using Interop

var word = new Application { Visible = false };
var doc = word.Documents.Open(inputPath);
doc.SaveAs2(outputPath, WdSaveFormat.wdFormatPDF);
doc.Close();
word.Quit();
Marshal.ReleaseComObject(doc);
Marshal.ReleaseComObject(word);

Locally, this works. In production, it requires Office installed, runs single-threaded, leaks processes under error conditions, and can lock files in ways that require manual cleanup on the server.

✅ Using Spire.Doc

var doc = new Document();
doc.LoadFromFile("report.docx");
doc.SaveToFile("report.pdf", FileFormat.PDF);

No Office. No COM cleanup. No process management. The same three lines work identically on Windows, Linux, and inside a Docker container.

This is where most Interop-based solutions start to break.

Scenario C: Returning a PDF from an ASP.NET Core Endpoint

❌ Using Interop

Each request spins up a new Office process. Concurrent requests interfere with each other. There's no clean way to write to a response stream — you're saving to disk and reading it back. Process cleanup in an async context is unreliable.

✅ Using Spire.Doc with MemoryStream

[HttpGet("report")]
public IActionResult GetReport()
{
    var doc = new Document();
    doc.LoadFromFile("template.docx");

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

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

The conversion (handled by Spire.Doc) happens entirely in memory. No temp files, no disk I/O, no process lifecycle to manage. This pattern scales horizontally without any changes.

This is where standalone libraries truly outperform Interop.

Interop vs Modern Libraries: A Quick Comparison

Feature	Interop	Modern Library
Requires Office	✅ Yes	❌ No
Server / Docker Support	❌ No	✅ Yes
Thread Safety	❌ No	✅ Yes
Stability Under Load	🔴 Low	🟢 High
Deployment Complexity	🔴 High	🟢 Low

When You Might Still Use Interop

Interop isn't universally wrong. It's a reasonable choice for local desktop automation tools, single-user scripts, and scenarios where Office is already present and concurrency isn't a concern. If you need to manipulate macros or preserve highly complex Office-specific formatting, it may still be the only option.

Interop isn't wrong — it's just used in the wrong context.

Conclusion: Move Beyond Interop

Microsoft Office Interop remains convenient for quick solutions, but its reliance on desktop components, lack of scalability, and instability under load make it unsuitable for modern backend systems.

Today's .NET systems are built to run in cloud environments, containers, and stateless services—where dependencies on GUI-based software simply don't fit. Instead of working around these constraints, it's more effective to adopt tools designed for server-side document processing from the ground up. Standalone libraries—such as Spire.Doc and Spire.PDF for .NET—exist precisely to address these challenges.

How to Highlight Duplicates in Excel: A Developer-Friendly Guide

Chloe — Mon, 13 Apr 2026 09:42:53 +0000

If you've ever received a spreadsheet from a product manager and been asked to "just check for duplicates," you know the feeling — it sounds trivial, but the moment you open the file, you realize what you're dealing with: 10,000 rows, multiple columns, no clear definition of what “duplicate” actually means in this context.

Duplicate detection is one of those tasks that sits at the intersection of Excel power users and backend developers. It's too manual to ignore, yet too tightly coupled to a .xlsx file to fit cleanly into your usual data tooling.

In this guide, we'll walk through a set of approaches that scale with your needs—from quick UI tricks to automation and developer-friendly solutions.

What Counts as "Duplicates" in Excel?
Method 1: Conditional Formatting (Built-in UI)
Method 2: COUNTIF Formula-Driven Conditional Formatting
Method 3: VBA Macro — Client-Side Automation
Method 4: Power Query & Dynamic Arrays
Method 5: Highlight Duplicates in Excel Using C# (Server-Side Automation)
Method Comparison at a Glance
Conclusion

What Counts as "Duplicates" in Excel?

Before jumping into solutions, it's worth clarifying what we actually mean by "duplicates," because the definition can vary depending on the scenario.

Different Types of Duplicates

In most real-world cases, duplicates fall into one of three categories:

Single-column duplicates: the same value appears more than once in a column, such as repeated email addresses
Full-row duplicates: every cell in two or more rows is identical.
Composite duplicates: a combination of columns forms a duplicate key, even if no individual column is duplicated on its own. For example, the same '(user_id, date)' pair appearing twice in a transaction log.

The distinction matters, because Excel’s built-in tools don’t always handle these cases the same way.

Common Gotchas

Even when the logic seems straightforward, a few subtle issues can lead to misleading results.

For example, Excel is not case-sensitive by default, which means Apple and apple are treated as the same value. That's convenient in many cases, but it can also hide inconsistencies.

Hidden characters are another common culprit. A value like "123" is not the same as "123 " if there's a trailing space—something that's easy to miss visually.

You'll also run into type mismatches, where "123" (text) and 123 (number) are treated differently. And yes, even Excel isn’t immune to floating-point quirks—calculations like 0.1 + 0.2 may not always behave exactly as expected.

Taken together, these edge cases are why “finding duplicates” is often more nuanced than it appears.

Method 1: Conditional Formatting (Built-in UI)

The fastest way to highlight duplicates — no formulas, no code. Best for one-off checks where you just need to see the problem quickly.

How to do it:

Select the column or range you want to check, then follow this path:

Home → Conditional Formatting → Highlight Cell Rules → Duplicate Values

A dialog appears letting you choose a highlight color. Click OK and Excel immediately colors every cell whose value appears more than once in your selection.

One behavior to know:

If you select multiple columns at once, Excel checks each cell individually — not each row. So if column A has alice twice and column B has bob twice, both get highlighted, but a row where (alice, bob) appears twice would only be caught if both cells independently repeat. If you need row-level or composite duplicate detection, skip ahead to Method 2.

Customizing the format:

The default is a light red fill, but you can set any fill color, font color, or border style. In the same dialog, open the format dropdown and select "Custom Format" to access the full cell formatting options.

Limitations:

No case sensitivity control — Alice and alice are treated as the same
Dynamic ranges aren't tracked automatically — if you add rows later, you'll need to reapply or extend the rule manually
Rules stack: if you have multiple conditional formatting rules on the same range, order matters. Manage them under Home → Conditional Formatting → Manage Rules

Still, for quick, one-off checks, it's often the most efficient option.

Method 2: COUNTIF Formula-Driven Conditional Formatting

When the built-in UI isn't flexible enough — you need case sensitivity, composite keys, or more precise control over which occurrences get flagged — COUNTIF gives you that control without leaving Excel.

The idea is simple: instead of letting Excel decide what counts as a duplicate, you write a formula that returns TRUE or FALSE for each cell, and conditional formatting applies the highlight based on your logic.

Basic setup:

Select your data range, for example B2:B16, then create a new conditional formatting rule:

Home → Conditional Formatting → New Rule → "Use a formula to determine which cells to format."

Enter this formula:

=COUNTIF($B$2:$B$16, B2) > 1

This counts how many times the value in B2 appears across the entire range. If it appears more than once, the cell gets highlighted. The $ signs lock the range while letting the row reference shift as the rule applies to each cell.

If you're familiar with SQL, this is the spreadsheet equivalent of:

SELECT value
FROM table
GROUP BY value
HAVING COUNT(*) > 1

Highlight only the second occurrence onwards:

The basic formula flags every occurrence, including the first. If you want to mark only the duplicates — leaving the original untouched — use this instead:

=COUNTIF($B$2:B2, B2) > 1

The key difference is $B$2:B2 — the start of the range is anchored but the end expands as the rule moves down each row. By the time Excel evaluates row 5, the range is $B$2:B5, so it only counts occurrences up to the current row. The first appearance is never flagged; only repeats are.

Composite duplicate detection:

To check whether a combination of columns forms a duplicate — say (email, signup_date) — concatenate the values into a single key using &:

=COUNTIFS($A$2:$A$100, A2, $B$2:$B$100, B2) > 1

Or with string concatenation across more columns:

=COUNTIF($A$2:$A$100 & $B$2:$B$100, A2 & B2) > 1

This is the closest you'll get to a composite primary key check inside native Excel.

Case-sensitive duplicate detection:

COUNTIF is case-insensitive by default. For case-sensitive matching, use EXACT wrapped in SUMPRODUCT:

=SUMPRODUCT((EXACT($A$2:$A$100, A2)) * 1) > 1

This iterates over every value in the range and checks for an exact match, including case, returning a count. More expensive on large datasets, but it works.

Method 3: VBA Macro — Client-Side Automation

The three methods above all live inside Excel's UI. They work well for interactive use, but they're hard to trigger programmatically, difficult to version control, and impossible to run without opening Excel manually. If you need duplicate highlighting to happen automatically — on file open, on a button click, or as part of a repeatable workflow — VBA is the natural next step.

Basic implementation:

The core logic is straightforward: iterate over a column, track how many times each value has appeared using a Dictionary, then go back and color any cell whose value appeared more than once.

Sub HighlightDuplicates()

    Dim ws As Worksheet
    Dim rng As Range
    Dim cell As Range
    Dim dict As Object
    Dim highlightColor As Long

    Set ws = ThisWorkbook.Sheets("Sheet1")
    Set rng = ws.Range("A2:A1000")
    highlightColor = RGB(255, 199, 206)

    Set dict = CreateObject("Scripting.Dictionary")

    For Each cell In rng
        If cell.Value <> "" Then
            Dim key As String
            key = Trim(CStr(cell.Value))
            If dict.exists(key) Then
                dict(key) = dict(key) + 1
            Else
                dict.Add key, 1
            End If
        End If
    Next cell

    For Each cell In rng
        If cell.Value <> "" Then
            If dict(CStr(cell.Value)) > 1 Then
                cell.Interior.Color = highlightColor
            Else
                cell.Interior.ColorIndex = xlNone
            End If
        End If
    Next cell

End Sub

The first loop builds the frequency map. The second loop applies or removes the highlight based on the count. Splitting into two passes keeps the logic clean and makes it easy to add a "clear all highlights first" step before reapplying.

Making it reusable:

Hard-coding the sheet name and range is fine for a one-off script, but if you plan to reuse this across files, parameterize the key variables:

Sub HighlightDuplicates(sheetName As String, columnRange As String, highlightColor As Long)
    Dim ws As Worksheet
    Dim rng As Range
    Set ws = ThisWorkbook.Sheets(sheetName)
    Set rng = ws.Range(columnRange)
    ' ... same logic as above
End Sub

Call it from elsewhere in your project:

Call HighlightDuplicates("Sheet1", "A2:A1000", RGB(255, 199, 206))

Triggering automatically on file open:

To run the macro every time the workbook opens, add it to the Workbook_Open event in ThisWorkbook:

Private Sub Workbook_Open()
    Call HighlightDuplicates("Sheet1", "A2:A1000", RGB(255, 199, 206))
End Sub

Now every time someone opens the file, duplicates are flagged automatically — no manual steps required.

Performance on large datasets:

VBA loops are slow by default because Excel recalculates and redraws after every change. For datasets over a few thousand rows, disable these before running and re-enable them after:

Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual

' ... your loop here ...

Application.ScreenUpdating = True
Application.Calculation = xlCalculationAutomatic

On a 50,000-row dataset, this alone can reduce runtime from 30+ seconds to 2–3 seconds.

Where VBA falls short:

VBA runs inside Excel, which means it requires Excel to be installed and open. It can't be triggered from a CI pipeline, a backend service, or a scheduled task on a server. If your use case involves processing Excel files without a desktop environment, the next method is what you need.

Method 4: Power Query & Dynamic Arrays

While the previous methods work well within Excel itself, they are harder to integrate into data pipelines or produce clean, structured outputs. If your goal is to output a deduplicated table, feed results into another process, or refresh the analysis automatically when data updates, Power Query and dynamic arrays are better tools.

Dynamic arrays (Excel 365 only):

If you're on Microsoft 365, the [UNIQUE()](https://support.microsoft.com/en-us/office/unique-function-c5ab87fd-30a3-4ce9-9d1a-40204fb85e1e) and [FILTER()](https://support.microsoft.com/en-us/office/filter-function-f4f7cb66-82eb-4767-8f7c-4877ad80c759) functions let you extract duplicate values directly into a new range — no conditional formatting involved.

To get a list of values that appear more than once:

=FILTER(A2:A100, COUNTIF(A2:A100, A2:A100) > 1)

COUNTIF(A2:A100, A2:A100) returns an array of counts — one per row. FILTER() then keeps only the rows where that count exceeds 1. The result spills automatically into adjacent cells.

Note: On very large datasets, this approach may become slow because COUNTIF is evaluated across the entire range for each element.

To get just the unique values among those duplicates — without repetition:

=UNIQUE(FILTER(A2:A100, COUNTIF(A2:A100, A2:A100) > 1))

This is clean, readable, and updates live as your source data changes. The main constraint is that it requires Excel 365 — it won't work on Excel 2016 or 2019.

Power Query:

Power Query works on Excel 2016 and later, and is better suited for larger datasets or more complex transformations. The approach is to group rows by the columns you care about, count occurrences, then filter for groups with more than one row.

To open Power Query:

Data → Get Data → From Table/Range

Select your data range and click OK. In the Power Query editor:

Select the column you want to check for duplicates
Go to Home → Group By
Group by your target column, add a count column using Count Rows
Click OK — you now have a summary table with each value and its occurrence count
Filter the count column to show only rows where count > 1

Click Close & Load to output the results to a new sheet. Every time you refresh the query (Data → Refresh All), it re-runs against the latest data.

For composite duplicate detection, select multiple columns before grouping — Power Query will treat the combination as a single key.

👉 If you're familiar with SQL, you can think of this as a GROUP BY + HAVING COUNT > 1 workflow, but expressed through a visual interface.

When to use which:

Dynamic arrays are ideal when you want a live formula that updates automatically and the data fits within a single worksheet. Power Query is the better choice when the dataset is large, the transformation logic is complex, or you need a repeatable process that non-technical users can trigger with a single Refresh click.

Neither method requires code, but both offer a significant step up in capability — and both output clean data rather than just painting cells.

Method 5: Highlight Duplicates in Excel Using C# (Server-Side Automation)

Up to this point, all approaches still depend on Excel as the execution environment. That works for manual workflows, but starts to break down when you need to process files in a backend service, a CI/CD pipeline, or any environment where Microsoft Office isn't available.

In these scenarios, using a standalone .NET library becomes the most practical approach. Instead of relying on Excel itself, you work directly with the file format in code — making the solution easier to automate, deploy, and scale.

One option here is Spire.XLS, a .NET library that reads and writes Excel files independently of Office. No COM interop, no Excel process in the background, and no dependency on a desktop environment. You install it via NuGet, point it at a file, and manipulate it like any other object in your codebase.

Setup:

Install the package via NuGet:

dotnet add package Spire.XLS

Or via the NuGet Package Manager in Visual Studio:

Install-Package Spire.XLS

No further configuration needed. The library handles .xlsx and .xls formats out of the box.

Core object model:

Before writing the implementation, it helps to understand three objects you'll use throughout:

Workbook — represents the entire Excel file
Worksheet — a single sheet within the workbook
CellRange — a cell or range of cells, with properties for value, style, and formatting

Basic implementation:

The logic mirrors the VBA approach: build a frequency map, then iterate again to highlight duplicates. The difference is that this runs as a standalone C# program — no Excel required.

using Spire.Xls;
using System.Collections.Generic;
using System.Drawing;

class Program
{
    static void Main(string[] args)
    {
        Workbook workbook = new Workbook();
        workbook.LoadFromFile("data.xlsx");

        Worksheet sheet = workbook.Worksheets[0];
        int startRow = 2;
        int endRow = sheet.LastRow;
        int targetColumn = 2;

        // Build frequency map
        Dictionary<string, List<int>> valueMap = new Dictionary<string, List<int>>();

        for (int row = startRow; row <= endRow; row++)
        {
            CellRange cell = sheet.Range[row, targetColumn];
            string value = cell.Value?.Trim();

            if (string.IsNullOrEmpty(value)) continue;

            if (!valueMap.ContainsKey(value))
                valueMap[value] = new List<int>();

            valueMap[value].Add(row);
        }

        // Apply highlighting to duplicate rows
        Color highlightColor = Color.FromArgb(255, 199, 206);

        foreach (var entry in valueMap)
        {
            if (entry.Value.Count > 1)
            {
                foreach (int row in entry.Value)
                {
                    CellRange cell = sheet.Range[row, targetColumn];
                    cell.Style.Color = highlightColor;
                }
            }
        }

        workbook.SaveToFile("data_highlighted.xlsx", ExcelVersion.Version2013);
        System.Console.WriteLine("Done. Duplicates highlighted.");
    }
}

The Dictionary<string, List<int>> stores each unique value alongside the row numbers where it appears. After the first pass, any key with more than one row number in its list is a duplicate. The second pass iterates over those row numbers and applies the fill color.

Composite duplicate detection:

To check for duplicates across multiple columns — say columns 1 and 2 together — concatenate the cell values into a composite key:

string value = $"{sheet.Range[row, 1].Value?.Trim()}|{sheet.Range[row, 2].Value?.Trim()}";

The | separator prevents false matches where concatenating two different pairs could produce the same string. For example, ("ab", "c") and ("a", "bc") would both produce "abc" without a separator, but "ab|c" and "a|bc" are distinct.

Make sure the separator character does not appear in your actual data, or choose a more robust delimiter.

Skipping the header row:

The startRow = 2 in the implementation above already handles this — adjust the value to match however many header rows your file has.

Custom highlight colors:

Color.FromArgb(r, g, b) accepts any RGB value. To match the default Excel duplicate highlight:

Color highlightColor = Color.FromArgb(255, 199, 206); // light red fill
Color fontColor = Color.FromArgb(156, 0, 6);          // dark red text

cell.Style.Color = highlightColor;
cell.Style.Font.Color = fontColor;

Integrating into a .NET service:

Because this is plain C#, it slots naturally into any .NET application — an ASP.NET endpoint that processes uploaded files, a background worker that validates reports on a schedule, or a console tool invoked from a CI pipeline:

# Example GitHub Actions step
- name: Validate Excel report
  run: dotnet run --project ./ExcelValidator -- --file reports/output.xlsx

The process exits with a non-zero code if duplicates are found, which causes the pipeline step to fail — giving you automatic duplicate detection as a CI gate.

Spire.XLS vs. VBA — when to use which:

VBA is the right tool when the work stays on a desktop, the file is opened interactively, and the person running it has Excel. Spire.XLS is the right tool when the file is processed on a server, the environment has no Office installation, or you need the logic to be testable, version-controlled, and integrated into a larger codebase.

Method Comparison at a Glance

Five methods is a lot to hold in your head. Here's a summary to help you pick the right one for your situation:

Method	Requires coding	Needs Office	Automation	Best for
Conditional Formatting	No	Yes	Manual	Quick one-off visual check
COUNTIF formula	No (formula)	Yes	Semi-auto	Flexible logic, stays in Excel
Power Query / Dynamic arrays	No	Yes (365)	Auto-refresh	Periodic reports, clean output
VBA macro	Yes	Yes	Full auto	Desktop automation, event-driven
C# Spire.XLS	Yes	No	Full auto	Server-side, CI/CD, batch processing

For quick decision-making, here's a simple rule of thumb:

Spot-checking a file someone sent you → Conditional Formatting.
Logic is complex but you're staying in Excel → COUNTIF formula.
You need a refreshable, clean output table → Power Query.
Desktop automation, triggered on open or button click → VBA.
Server-side, no Office, CI/CD pipeline → C# Spire.XLS.

Conclusion

Highlighting duplicates in Excel may seem like a small task, but it often reveals deeper issues in how data is structured and validated. What starts as a quick visual check can quickly turn into questions about consistency, edge cases, and reliability. Depending on your workflow, the right approach can range from simple conditional formatting to more controlled, repeatable solutions using formulas, Power Query, or code. As your data grows and processes become more automated, duplicate detection stops being just an Excel trick and becomes part of a broader data quality strategy. Choosing the right method is less about the tools themselves, and more about where your data logic naturally belongs as your workflow evolves.

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

Chloe — 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#?

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

Processing Word documents in C# is a common requirement in backend systems such as report generation, document automation, and data extraction.

For most developers, the choice eventually comes down to two approaches:

Open XML SDK — Microsoft's low-level library for working directly with .docx files
Third-party libraries like Spire.Doc — higher-level APIs focused on productivity and document rendering

Both approaches are widely used in production systems, but they optimize for very different things.

This article compares them from a practical, server-side perspective — including development complexity, PDF export, deployment concerns, and long-term maintainability.

Why Word Processing Becomes Complicated on Servers
Option A: DocumentFormat.OpenXML SDK
Option B: Using Third-Party Libraries (Spire.Doc)
Side-by-Side Comparison
Common Pitfalls and Hidden Traps
Decision Guide: Which One Should You Choose?

Why Word Processing Becomes Complicated on Servers

At first glance, generating a .docx file sounds straightforward.

In practice, server-side document processing introduces several constraints that significantly affect library selection.

No Office installation. Microsoft explicitly warns against using Word Automation (COM/Interop) in server environments. That rules out the most feature-complete Word automation approach in server environments.

Cross-platform deployment. If your service runs in a Linux container — which is increasingly common in modern deployments — any library with a Windows-only dependency is immediately disqualified.

Concurrency. A server handling concurrent document generation requests needs libraries that behave reliably under concurrent workloads. Some libraries require creating a separate document instance per request to avoid concurrency issues.

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 automating Microsoft Word, it manipulates the underlying XML structure directly.

dotnet add package DocumentFormat.OpenXml

This gives developers precise control over document internals — but also exposes the complexity of Word’s document model.

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 often splits text across multiple Run elements internally.

So a placeholder like:

{{name}}

may actually be stored as:

{{na
me}}

This breaks naive string replacement logic.

Production-grade implementations usually need additional logic to normalize runs before replacement.

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 example illustrates the SDK’s core trade-off: precise control at the cost of verbosity. Most formatting operations map directly to the underlying OOXML structure, which provides flexibility at the cost of additional implementation complexity.

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 itself does not include a rendering engine for PDF conversion.

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

LibreOffice (via command line)
Commercial rendering libraries
External conversion services

This adds extra infrastructure and deployment 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 additional implementation complexity.

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 built into the library rather than relying on external rendering tools.

dotnet add package Spire.Doc

A free edition (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 library aggregates paragraph and run content internally, so developers typically do not need to traverse the underlying node structure manually.

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 library abstracts this issue internally, so placeholder replacement typically works even when text is split across multiple runs.

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);
}

This is one of the biggest differences between the two approaches.

Spire.Doc includes its own rendering engine, which removes the need to integrate external tools such as LibreOffice or Microsoft Word for basic PDF conversion workflows.

Like most third-party rendering engines, PDF output may not always be pixel-identical to Microsoft Word for highly complex layouts or documents using uncommon fonts.

For large-scale batch conversion scenarios, memory usage and throughput testing are still recommended, especially in containerized deployments.

Advantages of Spire.Doc

1. Higher-Level API

Most operations map directly to how developers think about documents:

Sections.
Paragraphs.
Tables.
Styles.

This avoids exposing most OOXML-specific implementation details in application code.

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. Reduced Implementation Overhead

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

The free version includes limitations.

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 rendering or layout issues may be harder.

In addition, migrating away later may require refactoring document-generation logic tied to the library API.

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 often acceptable.

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)
DOCX read/write	✅	✅	✅
Placeholder replacement	✅ ⚠️	✅	✅
Table insertion	✅	✅	✅
Mail merge	Manual implementation	✅	✅
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.

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
Internal visibility	Full source access	Limited to exposed APIs

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.

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.

This breaks naive string replacement logic.

Solution:

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

Spire.Doc Pitfalls

1. 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

2. 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)

Like many document-processing workflows, handling untrusted user-uploaded files can introduce security risks if parsing and validation are not handled carefully.

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.

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 → A third-party library is often the simpler option.
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 often reduce implementation time for complex document workflows.
Are you targeting Linux containers or fully open-source stacks?
→ Yes → OpenXML is often the simplest fully open-source option.

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

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 many common tasks and reduce implementation overhead, especially for feature-rich scenarios.

The decision is less about which API is “better” and more about which operational complexity your team wants to own.

OpenXML gives you maximum control and zero licensing cost, but shifts more implementation responsibility onto your application. Higher-level libraries reduce that complexity, but introduce dependency and licensing considerations in return.

For production systems, making the right architectural decision early can significantly reduce maintenance overhead, deployment complexity, and long-term implementation cost.

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

Chloe — 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.