unidoc/unioffice: a commercial Go library for building and editing DOCX, XLSX and PPTX files

What unioffice solves, and who it is aimed at

Generating an Office file from a Go service usually means either shelling out to LibreOffice, hand-writing OOXML XML, or binding to a non-Go runtime. unioffice takes the third path out of the picture: it is a pure Go library for creating and processing .docx, .xlsx and .pptx documents. The README states the goal plainly, to be the most compatible and highest performance Go library for creation and editing of docx/xlsx/pptx files.

The audience is narrower than a general-purpose file library. unioffice is a commercial product, and the README says it requires a license code to operate. A metered license API key in the free tier comes from signing up at cloud.unidoc.io. So the typical user is a backend team that already ships Go, needs to emit Word reports, Excel workbooks or slide decks as part of a product, and is willing to take on a vendor dependency in exchange for not maintaining OOXML serialization itself.

The feature list is split by format. DOCX covers read, write and edit, formatting, images, tables, and Word to PDF conversion. XLSX covers read, write and edit, cell formatting including conditional formatting, cell validation with dropdown comboboxes, retrieval of cell values as formatted by Excel, formula evaluation with more than 100 functions supported, embedded images, and all chart types. PPTX is the thinnest of the three: creation from templates, plus textboxes and shapes. If your workload is presentation generation, that scope is worth reading twice before you commit.

How the wrapper API and the schema/ package fit together

The OOXML specification is enormous, and the README is candid that a friendly API covering all of it would take a very long time to build. The design answer is two layers. A wrapper API handles common use cases, and raw XML types live in the schema/ directory for everything else. Wrapper types expose their raw counterpart through an X() method.

The README gives a concrete example of when you need that escape hatch: the library has no API for setting a document background color, but it can be done manually by editing the raw type. That pattern matters for adoption planning. Before choosing unioffice, check whether the specific OOXML feature you need is wrapped. If it is not, you are not blocked, but you are writing schema-level code, and the ergonomics of the wrapper no longer apply.

Under the hood, the module depends on several sibling UniDoc packages listed in go.mod: github.com/unidoc/unipdf/v5 for PDF work, github.com/unidoc/unichart for charts, github.com/unidoc/emf, github.com/unidoc/unitype, plus golang.org/x/image and github.com/richardlehane/msoleps. Chart support in XLSX is therefore not homegrown; it routes through unichart. The go.mod also sets go 1.25.0, so the toolchain floor is recent.

Installing unioffice and writing a first document

Installation is a single go get against the v2 module path. The README gives this command:

go get github.com/unidoc/unioffice/v2

That pulls the library and its transitive dependencies into your module. It does not give you a working license. The README states that the package is a commercial product and requires a license code to operate, and that a metered license API key in the free tier is obtained by signing up at cloud.unidoc.io. Expect to wire that key into your program before any document call succeeds.

For a first real use, the repository's document examples are the place to start. The README links a Simple Text Formatting example covering font colors, sizes and highlighting, and an Editing an existing document example that opens a document and replaces or removes text without modifying formatting. Those two cover the two shapes most teams need: build from scratch, and patch an existing file.

If your workload is spreadsheets, the spreadsheet examples are more relevant than the document ones. The README links Simple, Named Cells, Cell Number/Date/Time Formats, Merged Cells, Conditional Formatting, Validation, Frozen Rows/Cols, and several chart examples including Line Chart, Bar Chart and Multiple Charts. The Validation example covers data validation including combo box dropdowns, which pairs with the cell validation feature listed in the status section.

For presentations, the README lists three examples only: Simple Text Boxes, Images, and Template. That list is short, and it matches the limited PPTX feature set described above.

The binary size and read performance trade-off

The README publishes its own benchmark numbers, and they are worth reading as a design statement rather than as marketing. Against a benchmark that creates a sheet with 30k rows and 100 columns, the reported figures are:

creating 30000 rows * 100 cells took 3.92506863s
saving took 89ns
reading took 9.522383048s

Two things stand out. Saving is effectively free, which the README attributes to no reflection usage. Reading is more than twice as slow as creating the same data. The README acknowledges this directly, calling reading a bit slower.

The cost shows up elsewhere too. The README states the binary is large, 33MB, because it contains generated structs plus serialization and deserialization code for all of DOCX, XLSX and PPTX. If you are building a small CLI or a Lambda-style function and only need to write one XLSX, that 33MB is the price of the three-format coverage whether you use it or not. This is a real constraint, not a footnote: it affects cold starts and container image sizes.

There is no published number for how the library behaves on files far larger than 30k rows by 100 columns, and the README does not discuss streaming or partial reads. If your input is a multi-hundred-megabyte workbook, treat that as unverified and test it against your own data before designing around it.

Licensing, the license key, and what it means for your build

The repository's license is reported as NOASSERTION, and the README badge points to the UniDoc EULA at unidoc.io/eula/. The repository also carries LICENSE.md, CLA.md and ACKNOWLEDGEMENTS.md at the top level. The practical reading is that this is not an OSI-approved permissive license, and the README says so in plain terms: unioffice is a commercial product and requires a license code to operate.

For engineering decisions, that produces three concrete consequences. First, the license key is a runtime input, which means your deployment pipeline needs a way to supply it, and your local test setup needs one too. Second, the free tier exists but is metered, so usage volume is a design variable rather than an afterthought. Third, because the module is versioned under /v2, upgrades move through Go module semantics rather than a vendor download.

This article cannot give legal advice, and the EULA text is not reproduced here. Read unidoc.io/eula/ and the LICENSE.md in the repository before you build a product on top of it. The repository's own README is the authoritative source for install and key acquisition, and it does not document rollback behavior or what happens when a key expires mid-process.

When unioffice is the wrong choice

The clearest mismatch is licensing. If your project requires an OSI-approved permissive license, unioffice fails that test before any technical question is asked, because the README states it is a commercial product requiring a license code. No amount of API quality changes that.

The second mismatch is format scope. If you only need XLSX and nothing else, you are paying the 33MB binary cost for generated code covering DOCX and PPTX that you never call. The README attributes the binary size precisely to that three-format coverage.

The third is read-heavy spreadsheet work. The published benchmark shows reading at 9.5s against creating at 3.9s for the same 30k by 100 shape. If your service is mostly ingesting large workbooks rather than producing them, the balance of the library's strengths is against you.

The fourth is PPTX. The status section lists only creation from templates plus textboxes and shapes. If you need to edit existing decks, populate charts in slides, or manipulate slide masters, the README does not claim that support, and the three presentation examples do not demonstrate it. Treat PPTX as a template-filling feature, not a full presentation toolkit.

Finally, if you cannot supply a license key at runtime (for example, an environment where you cannot inject secrets), the library will not operate at all, per the README.

Alternatives and how their approach differs

The related searches around this project point at a cluster of Go office libraries, and the differences are mostly about which formats are covered and under what license.

Excelize is the common Go choice for spreadsheet-only work. The approach differs in scope: Excelize targets XLSX, while unioffice covers DOCX, XLSX and PPTX in one module. If your requirement is only spreadsheets, a single-format library avoids the generated code for the other two formats that the unioffice README blames for the 33MB binary.

Gooxml is the historical predecessor name in this space, and baliance com gooxml document appears in the related searches. The relationship matters because unioffice is the successor line, and the module path is now github.com/unidoc/unioffice/v2. If you find old Gooxml code in a codebase, that is a migration question, not an alternative-evaluation question.

Godocx and Docxgo appear in the searches as DOCX-focused Go options. Their approach is narrower by design: one format, no spreadsheet or presentation engine. That is the opposite trade from unioffice, which bundles all three formats and their serialization code together.

UniPDF, from the same vendor, is the PDF counterpart and is listed as a direct dependency in go.mod (github.com/unidoc/unipdf/v5). If your pipeline is DOCX to PDF, the README lists Word to PDF as a supported DOCX operation, and that path runs through the UniPDF dependency rather than an external converter.

Docconv sits in a different category: it is a text-extraction tool rather than a document-generation library. If your goal is to pull text out of a file, unioffice's write-oriented API and license key are both unnecessary weight.

Editorial conclusion

Adopt unioffice if your team writes Go, needs DOCX, XLSX and PPTX handling in one dependency, and can accept a metered commercial license with a free tier. Do not adopt it if you need an OSI-approved permissive license, a small binary, or fast reads of large spreadsheets, since the README reports a 33MB binary and slower read times. Before committing, verify the current license terms at unidoc.io/eula/, confirm the free-tier key limits on cloud.unidoc.io, and check whether your target OOXML features are covered by the wrapper API or require falling back to schema/ raw types.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. unidoc/unioffice on GitHub