OfficeToPDF: server-side Office conversion through Office's own export

A converter that drives Office instead of reimplementing it

OfficeToPDF is a command line utility that converts Microsoft Office 2003, 2007, 2010, 2013 and 2016 documents from their native format into PDF using Office's in-built PDF export features. That last clause is the whole design decision, and everything else follows from it.

Most Office to PDF tools are single-user desktop applications, and the README says most of them are intended that way. OfficeToPDF is useful, in its words unique, if you want to automatically create PDF files on a server-wide basis and free individual users from an extra step of using the Save as command on their Office files. The PDF files can then be stored and managed on a separate server.

The scenario the README gives is a policy one: a department that only distributes PDF versions of documents to people outside the department. That is a real workflow in large organisations, and it is exactly the case where a desktop Save as button does not scale and where reimplementing Word's layout engine would be a mistake.

So the mechanism is: run the conversion on a machine where Office is installed, using Office's own exporter, and collect the results as files. The output is not a re-rendered approximation of the document. It is what Office itself would have produced.

The audience is a Windows administrator or a document-processing team who already has Office licences, not a developer looking for a cross-platform library. The tool is written in C#, it is distributed as a Visual Studio solution with a nuget directory and an azure-pipelines configuration, and the deliverables are a Windows executable.

The hard requirements are Office itself and the .NET Framework 4

The README lists the technical requirements before anything else, and they are not light. You need the .NET Framework 4, and you need Office 2016, 2013, 2010 or Office 2007 installed.

Office 2007 is the awkward case. If that is your version, you additionally need Visual Studio 2010 Tools for Office Runtime and the 2007 Microsoft Office Add-in for Save as PDF or XPS, because the export path Office 2007 uses for PDF is delivered as an add-in rather than built in. Office 2010 and later have the export built in.

This is the constraint that decides whether the tool fits your environment. The converter is not self-contained: it is a driver for Office installed on the machine, so the machine needs an Office licence, the Office installation needs to be present, and the conversion inherits Office's behaviour including its first-run dialogs, its activation state and its tendency to leave a process running.

There is a related operational consequence that shows up in the switches. The /noquit switch exists to avoid exiting running Office applications, and /hidden attempts to minimise the Office application while converting. Both exist because the tool drives a real Office installation, which is a real process with a real window. On a server, the conversion happens in a session that may not have an interactive desktop, and getting that right is part of the operational work rather than something the tool abstracts away.

The fallback printer switches make the dependency explicit. The /printer and /fallback_printer options print the document to a PostScript printer of the given name for conversion, and both require Ghostscript to be installed. That is the escape hatch when the main conversion routine fails, and it needs a second piece of software on the machine.

The command is one executable, two files, and about forty switches

Using it is deliberately simple. The README says to download the officetopdf.exe file and run it with two arguments, the source Office document and the destination PDF document. The example given shows a Windows command prompt session:

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:\Users\test> officetopdf.exe somefile.docx somefile.pdf

The switches are where the real configuration lives, and the list is long because each one maps to a specific Office behaviour you might want to change. The output-affecting ones include /bookmarks to create bookmarks when the Office application supports them, /print for high-quality PDFs optimised for print, /pdfa to produce ISO 19005-1 compliant PDF/A output, and /template to use a .dot, .dotx or .dotm template when converting with Word.

There is also /merge, which with a template creates a new file from the template and merges the text from the document being converted into it, which is how you get a letterhead or a compliance cover page applied automatically to every converted file.

Metadata and markup are handled separately. /excludeprops and /excludetags strip document properties and tags from the generated PDF, and /pdf_clean_meta removes more, with a basic type that removes author, keywords, creator and subject, and a full type that also removes the title. On the markup side, /markup shows document markup when creating PDFs with Word, and a family of /word_show_* switches controls exactly which markup appears, including revisions, comments, ink annotations, insertions and deletions, with /word_show_all_markup to turn it all on and /word_markup_balloon to switch between balloon style and inline messages.

The Excel switches are the same kind of thing. /excel_show_formulas, /excel_show_headings, /excel_max_rows to limit the number of rows converted, /excel_active_sheet and /excel_worksheet to convert one specific sheet, /excel_auto_macros to run Auto_Open macros in the file before conversion, and /excel_no_link_update and /excel_no_recalculate to suppress link updates and formula recalculation.

Two switches deserve a warning label. /excel_auto_macros runs macros from the document being converted, on a server, unattended. That is a decision with security consequences that the switch list itself does not spell out.

File type coverage depends on which Office applications you actually own

The supported file types list is long, and it is worth reading as two lists rather than one. Word, Excel, Powerpoint, Outlook, Publisher, Visio, Project and OpenOffice formats are all listed, with specific extensions for each.

But the README states that conversion of Visio, Publisher and Project files requires that those applications are installed, and that they are not included in the Office standard package. So the coverage you actually get depends on your licence. There are version floors too: Visio 2013 or newer is needed for .svg, .vsdx and .vsdm support, and Project 2010 or newer for .mpp.

That is the difference between a tool that supports a format and a tool that can convert it, and it is the sort of thing that only shows up when a job fails in production. A pipeline that handles .docx perfectly and quietly drops .mpp because Project was not installed is a bad afternoon.

OpenOffice formats are listed as convertible, but the technical requirements above name only the .NET Framework and Office, and the export mechanism is described as Office's own PDF export features. The README does not explain how OpenOffice files are handled given that mechanism, so if that row matters to you it is a question for the project rather than an assumption to make.

The Outlook formats, .msg, .vcf and .ics, are covered by the same export path. That is worth noting because converting a .msg is often the hardest case in a mail archive migration, since the result is a static document rather than a mail client view, and any expectation of preserving the message structure has to be checked against the actual output.

Licensing is the awkward part of this project

The README states that the tool is distributed under the Apache 2.0 license, with a LICENSE.md file at the repository root and a link to it. GitHub's own classification of the repository licence is not one it recognises as a standard identifier, which is a discrepancy worth resolving by reading the LICENSE.md file directly rather than trusting a badge or a metadata field.

The Apache 2.0 grant itself is not the problem. The problem is the surrounding stack. Running the conversion requires Microsoft Office installed and licensed on the machine, which means the deployment inherits Office's licensing terms, its automation restrictions and its version support lifecycle. Apache 2.0 on the converter does not grant anything about Office.

Office automation on a server is also a category of use that Microsoft has historically restricted in its licensing, and the README does not address the licensing question at all. It focuses on what the tool does. If you are deploying this inside an organisation, the question of whether your Office licence permits unattended server-side conversion is a question for your legal team and your Microsoft agreement, not something this repository can answer.

The framing in the README is worth noting for what it is. The project appears under a heading about giving back to the community, saying Cognidox would not exist without help from open source projects such as Perl, Apache and Solr, and that it has released open source projects such as OfficeToPDF to help others. That is a sponsor's stated motivation, and it explains why the tool is free without telling you anything about the obligations it creates downstream.

Where OfficeToPDF is the wrong tool

The first wrong-tool case is any environment without Office, which in practice means Linux. The conversion mechanism is Office's own export, the requirements list names Office and the .NET Framework 4, and the deliverable is a Windows executable. There is no Linux build and no cross-platform path described in the README.

The second is a headless requirement with no Office at all. There are tools that read and render Office file formats directly, without an Office installation, and they exist precisely because the Office dependency is heavy. The difference in approach is fundamental. OfficeToPDF gets fidelity for free because the same engine that renders the document on a desktop produces the PDF, which also means it gets Office's font substitution behaviour, its printer driver dependencies and its macro handling. A renderer without Office is independent of Office but has to reimplement layout, and will differ on complex documents.

The third is a document volume problem. The tool drives a real Office application, one process per conversion, on a Windows machine. A batch of ten thousand documents is a scheduling and licensing question, and the switches like /hidden, /noquit and /excel_auto_macros show that process management is part of the operational picture rather than something the tool handles.

The fourth is compliance requirements that PDF/A alone does not meet. The /pdfa switch gives you ISO 19005-1 output, and /pdf_clean_meta strips metadata, which is a good start, but the README documents no signing, no certification and no validation step. A regulatory pipeline needs more than the converter produces.

The fifth is a licensing refusal. If you cannot run Office for unattended conversion, no amount of this tool's capability helps, and the decision has to be made before the engineering starts.

Release history suggests a stable tool rather than a growing one

The release tags tell a story of a project that reached a plateau. OfficeToPDF 1.9 was published on 2020-02-26, 1.8.22.0 on 2018-10-09, and 1.8.21.0 on 2018-07-27.

A few months between 1.8.21 and 1.8.22, then a longer gap to 1.9, and then nothing published since February 2020. The last push to the repository was on 2026-09-01, and the repository is not archived, so work continues in the tree even though no new version has been cut in more than six years.

That is unusual but not alarming for this kind of tool. A converter that drives a fixed API of Office 2016 and earlier has little to add over time, and the newest Office versions it supports are themselves old. The risk is different from a typical stale dependency. It is not that the code rots, it is that the Office versions it targets fall further behind, and that a future Office install on your server may behave in ways this code has never seen.

The repository also shows a working project rather than an abandoned one. There is an azure-pipelines.yml, so there is continuous integration, a.nuget directory suggesting package output, a docs directory, and a Visual Studio solution at the root. The OfficeToPDF directory holds the code itself.

For an adopter, the practical consequence is that you should not expect new Office version support to arrive from this project. If your organisation standardises on a current Office release, the compatibility question is yours to answer, and the answer is likely to be that this tool does not target it.

Editorial conclusion

OfficeToPDF fits a Windows organisation with an Office install that needs PDF copies produced automatically for distribution, where fidelity to Word's own layout matters more than headless independence. It is the wrong tool for a Linux deployment, for an organisation that cannot or will not run Office, and for anything that must avoid the Office licence and its automation constraints. Before adopting it, confirm the target Office version is one of the supported ones, check that Visio, Publisher and Project licences exist for those file types, and verify that the PDF/A and metadata options meet your distribution policy before wiring it into a pipeline.

Frequently asked questions

Official sources

1. cognidox/OfficeToPDF on GitHub
2. Issues
3. Project website
4. README
5. Releases