If you’re working with Excel files in Go, you’ve probably come across Excelize. It’s the most popular .xlsx library in the Go ecosystem, and for good reason. We built Werkbook because we had a different set of priorities, not because Excelize is bad. It’s excellent at what it does.
Here’s an honest look at where each library shines.
Where Excelize shines
Feature coverage. Excelize supports a huge surface area of the OOXML spec. Charts, pivot tables, images, comments, sparklines, conditional formatting, data validation, form controls. If Excel has it, Excelize probably supports it. For projects that need to generate richly formatted reports with charts and visual elements, Excelize is hard to beat.
Streaming for large files. Excelize includes a streaming writer that can handle very large workbooks without loading everything into memory. If you’re generating hundreds of thousands of rows, this is a big deal.
Battle-tested maturity. Excelize has been around since 2016 and is used in production by a lot of teams. The community is large, the documentation is thorough, and most edge cases you’ll hit have already been filed and fixed.
Broad OOXML fidelity. If you need to open a complex workbook, modify a few cells, and write it back with everything else intact (styles, charts, macros, print settings), Excelize preserves a lot of that structure.
Where Werkbook shines
Formula evaluation. This is the big one. Werkbook includes a full formula engine: lexer, parser, compiler, dependency sorter, and evaluator, all in Go. You can set formulas on cells and actually compute results without Excel or LibreOffice. Werkbook currently supports 437 formula functions. If your use case involves recalculating workbooks server-side, this is what Werkbook was built for.
Zero dependencies. Werkbook uses only the Go standard library. No CGo, no system libraries, no transitive dependency tree to audit. This matters if you care about supply chain simplicity, reproducible builds, or deploying to minimal containers.
Typed value model. Cell values in Werkbook carry their type: Number, String, Bool, Error, or Empty. The formula engine and public API both preserve these types rather than flattening everything to strings. This makes it easier to work with cell data programmatically without guessing whether "42" is a number or text.
Sparse storage. Werkbook stores rows and cells in maps, not dense slices. A workbook with data in A1 and Z10000 only allocates storage for those two cells. This keeps memory usage proportional to actual data, not to the bounding rectangle.
API design. Werkbook’s API is modeled around spreadsheet concepts (workbooks, sheets, rows, cells) rather than around XML structure. Operations like SetValue, SetFormula, and GetValue read the way you’d describe them to a colleague.
How to choose
Pick Excelize if you need charts, images, pivot tables, or other rich formatting features. It covers more of the OOXML spec and has a mature ecosystem around those capabilities.
Pick Werkbook if you need to evaluate formulas, want zero external dependencies, or are building server-side automation where computation matters more than visual formatting.
There’s no wrong answer, just different trade-offs for different problems.