Excelize: pure Go OOXML, two install paths, and a source tree where every feature area is one flat file

The module path says xuri while the repository says qax-os

The repository is qax-os/excelize, but the Go module declared in go.mod is github.com/xuri/excelize/v2, and every code sample imports github.com/xuri/excelize/v2. The documentation links agree with the module rather than the repository: pkg.go.dev/github.com/xuri/excelize/v2 and the docs reference at xuri.me/excelize. The consequence for a reader is that the import line you write has nothing to do with the fork or organisation hosting the code, so searching by repository name will not find the import path and vice versa. The description in the package metadata is unchanged by any of this: a Go language library for reading and writing XLAM, XLSM, XLSX, XLTM and XLTX spreadsheets.

Two install commands, and the first one is not the module path

Installation is given twice and the two commands are not interchangeable. The first is:

go get github.com/xuri/excelize

The second is given as the option for packages managed with Go Modules:

go get github.com/xuri/excelize/v2

The difference is the major version suffix, and the wording makes the second one the conditional one, offered if your packages are managed using Go Modules. A project on modules needs the suffixed line; the unsuffixed one addresses the same package at v1. The consequence for a reader is that a copy-pasted first command in a module-aware project produces a dependency that is a major version behind the current one, and nothing in the error would tell you the suffix was the mistake. Documentation is available through Go's built-in documentation tool as well as the two hosted links.

Every feature area is one flat file with a test twin beside it

The root of the repository is the library. There is no internal package directory in the top-level listing; instead each concern is a single file with a matching test file: adjust.go, calc.go, calcchain.go, cell.go, chart.go, col.go, crypt.go, datavalidation.go, date.go, docProps.go, drawing.go, errors.go, excelize.go, file.go, hsl.go, lib.go, merge.go, numfmt.go, picture.go, rows.go, shape.go, sheet.go, sheetpr.go, sheetview.go, plus pivotTable.go and slicer.go. The file names map directly onto the API surface a caller touches, so chart work lands in chart.go and validation rules in datavalidation.go. The consequence for a reader is that the structure is easy to navigate but hard to extend, since adding a feature means adding a file at the top level rather than fitting into an existing package boundary.

Picture formats have to be registered by you through blank imports

The picture example imports three decoders as blank imports, and that detail is the whole contract:

    _ "image/gif"
    _ "image/jpeg"
    _ "image/png"

The insertion call itself is short, AddPicture with a sheet name, a cell reference and a file path, and a second call in the same example inserts a picture with scaling. The consequence for a reader is that the Go standard library ships these decoders but does not register them until something imports them, so a program that calls AddPicture without those blank imports still compiles and then fails when it reaches the image. The three formats are the ones the example registers; nothing in the README states that they are the complete set the library accepts, so a different format is a question the docs reference has to answer rather than the README.

Streaming is the answer to a worksheet with huge amounts of data

The stated reason for the library's existence beyond ordinary spreadsheet work is a streaming API for generating or reading data from a worksheet with huge amounts of data, and it is paired with a claim of high compatibility for complex components. Reading is deliberately bare: excelize.OpenFile with a path, a deferred Close, GetCellValue by sheet name and cell reference, and then a call that gets all the rows in a sheet. Writing starts from excelize.NewFile, adds sheets with NewSheet, writes cells with SetCellValue, marks the active sheet with SetActiveSheet, and saves by path. Both examples open the file and defer Close, and both print and return on error rather than ignoring it. The consequence for a reader is that the close call is part of the shape of the API rather than an afterthought, and the streaming path is a separate route from the cell-by-cell one shown in the samples.

Charts can be built from worksheet data or from nothing in the worksheet

Chart generation is described as a few lines of code, with one capability worth pulling out: you can build charts based on data in your worksheet, or generate charts without any data in your worksheet at all. That second case is what lets a caller emit a chart frame and populate it later, or emit one against a sheet that is still being assembled. The example fills a worksheet first, using CoordinatesToCellName to turn a column and row into a cell reference and SetSheetRow to write a whole row from a slice of values, then creates the chart. The consequence for a reader is that the chart API is not coupled to a populated sheet, which is the difference between a chart that describes data and a chart that is a placeholder. What the chart types are, and what each type requires, is not enumerated in the README.

Go 1.26 is the floor, and the releases land a few times a year

The minimum toolchain is stated plainly: Go version 1.26.0 or later, which is also the go directive in go.mod for the v2 module. The release rhythm is slow and regular. v2.10.1 was published on February 24, 2026, v2.11.0 on July 6, 2026, and v2.11.1 on November 2, 2026. The repository is not archived and its last push is dated November 2, 2026, so work is landing between those tags. The consequence for a reader is that a minor version bump is the event to schedule around, since the patch release between them carries fixes without the API movement, and a service pinned to a minor line should expect to sit on it for several months while waiting for the next one.

The compliance target is ECMA-376 part 1, fifth edition

The contributing section states that the XML is compliant with part 1 of the 5th edition of the ECMA-376 Standard for Office Open XML, which is the anchor for how much of the format the library attempts. The contribution path itself is ordinary: open a pull request to fix a bug, or open an issue to discuss a new feature or change. Licensing is the BSD 3-Clause License, and the artwork carries two separate notices, since the Excel logo is a trademark of Microsoft Corporation and the artwork is an adaptation, and the Go gopher was created by Renee French under a Creative Commons 4.0 Attribution license. A Chinese README, README_zh.md, ships next to the English one, and the project lists Gravity as a gold sponsor. The consequence for a reader is that using the library says nothing about the Excel trademark, which stays with its owner.

Editorial conclusion

Excelize fits a Go service that has to emit or ingest Office Open XML workbooks without a Microsoft dependency, especially when a worksheet will not fit comfortably in memory and the streaming API is the point. It does not fit a project still on the pre-modules import path, since that command resolves to v1, or one needing the older XLS binary format, which appears nowhere in the supported list. Before adopting it, decide which of the two go get lines you actually want, register the image decoders your pictures need, and read the docs on pkg.go.dev rather than assuming the README example is the whole API.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. qax-os/excelize on GitHub
4. README
5. Releases