DEV Community: Jakub Melka

C++ has no Apache POI. So I wrote one.

Jakub Melka — Mon, 07 Sep 2026 13:12:00 +0000

If you need to read or write DOCX, XLSX and PPTX files from native C++, there is no good answer. .NET has Open-XML-SDK. Java has Apache POI. C++ has a few XLSX-only libraries - OpenXLSX, QXlsx, libxlsxwriter among them - and nothing feature-rich that covers all three formats.

I hit that wall last year on my own project. After searching long enough to be confident I was not simply missing something, I decided to write the library myself. It is called ExyokiOffice, it is MIT licensed, and it now covers Word, Excel and PowerPoint behind one API.

The part I care about most: nothing gets silently dropped

Open a document containing charts, SmartArt or a vendor extension with most open-source Office libraries, save it, and the honest question is: what did I just lose? Usually nothing tells you. The elements the library does not understand are simply gone, and you find out when someone opens the file.

I designed ExyokiOffice so that content preservation is a contract. Elements and attributes the library does not recognize are retained in the internal XML DOM and written back when the document is saved. Round-trip preservation is checked against a corpus of real documents, not only synthetic ones.

That is the difference between a library you can put in a production pipeline and one you can only safely use on documents you created yourself.

No managed runtime, no external dependencies

No .NET Framework. No Java Virtual Machine. The only dependency is the standard C++ library.

Given the scope I expected the result to be big, and I was surprised that it is not. The compressed packages, including a Docker image containing the CLI tool and the MCP servers, come in under 30 MB.

Two APIs, because you will need both

The high-level API is built for the common case and does not ask you to know the underlying specifications.

#include "ExyokiOffice/Word/WordDocument.hpp"

int main()
{
    using namespace ExyokiOffice::Word;

    auto editor = WordDocumentEditor::CreateNew();
    editor->AddHeading("Hello world");
    editor->AddParagraph("This document was created by ExyokiOffice.");
    editor->SaveToFile("Hello.docx");
}

And here is a small Excel example:

#include "ExyokiOffice/Excel/ExcelDocument.hpp"

int main()
{
    using namespace ExyokiOffice::Excel;

    auto editor = ExcelDocumentEditor::CreateNew();
    auto sheet = editor->FirstWorksheet();
    sheet->SetCellText(1, 1, "Hello world");
    sheet->SetCellText(2, 1, "This workbook was created by ExyokiOffice.");
    editor->SaveToFile("Hello.xlsx");
}

When the high-level API is not enough, you drop into a DOM-like low-level API similar to Open-XML-SDK and modify the tree directly. You do not have to choose between them up front.

What else is in it

exyoki, a CLI tool: validation, conversion, full-text search, redaction and statistics, without writing a line of code
Schema and semantic validation against a specific Office version
Format conversion, including DOCX to Markdown and back
A security model where access to external resources is denied by default
Machine-readable CLI output in JSON or XML, for scripts, automation and AI agents
MCP servers for each document type, one per format - experimental, and I would rather say so than imply otherwise

exyoki info corpus/word/The_United_States_of_America.docx
exyoki search corpus/word/Open_Source_Software.docx "license" --ignore-case
exyoki validate corpus/excel/Formulas.xlsx
exyoki stat corpus/powerpoint/Yellowstone.pptx
exyoki convert corpus/word/The_United_States_of_America.docx usa.md

What it cannot do

No rendering, and no conversion to raster or SVG images. No legacy binary formats - DOC, XLS, PPT. The MCP servers are experimental and need real-world testing.

All the major parts of the library are finished and covered by unit tests. I am currently running coverage tooling to find the gaps and fix what it turns up.

If you work with Office documents in C++

This is a one-person project and I am at the start of a long road. If there is a feature you need and it is not there, open an issue. For a library like this, that is genuinely the most useful thing you can do.

JakubMelka / ExyokiOffice

A modern, MIT-licensed native C++ library for creation and modification of Open XML documents (DOCX, XLSX, PPTX), designed for cross-platform and dependency-free use.

ExyokiOffice

A native C++20 toolkit for creating and editing Word, Excel, and PowerPoint documents. Work with .docx, .xlsx, and .pptx through high-level editors or a typed OpenXML DOM, without Microsoft Office, .NET, Java, or Python at build time or runtime.

ExyokiOffice is designed for applications that need to generate or modify Office documents while retaining access to the underlying package. Content outside the high-level editing model is preserved instead of being silently dropped.

Quick start · Choose an API · Compatibility · Documentation · Comparison

Why ExyokiOffice

One native library for all three Office formats. Create and edit Word documents, Excel workbooks, and PowerPoint presentations from C++20.
Start high-level, go low-level when needed. Friendly editors cover common authoring tasks; the generated typed DOM and OPC packaging layer remain available for precise OpenXML work.
Preserve what you do not edit. The compatibility matrix distinguishes features the library can create…

View on GitHub

Introducing ExyokiOffice: An Open-Source C++ Library for Word, Excel and PowerPoint

Jakub Melka — Thu, 20 Aug 2026 13:00:00 +0000

What is ExyokiOffice?

When I needed to create and edit DOCX / XLSX / PPTX documents from native C++, I ran into a surprisingly difficult problem: which open-source library should I use? There are libraries for .NET (Open-XML-SDK) and Java (Apache POI) but there aren't any feature-rich C++ libraries that cover all three document formats. There are some libraries for XLSX (OpenXLSX, QXlsx and libxlsxwriter among others),
but they have their limits. So, last year, I decided to write the library myself.

What I wanted from an Office library

It was an ambitious goal for a one-person project. I wanted to create a feature-rich open source library under the MIT license that
would offer:

a small native C++ library without external dependencies (standard C++ library is an exception)
DOM-like low-level API similar to Open-XML-SDK (.NET), which will allow advanced users to modify the DOM tree directly
high-level API to comfortably process DOCX /XLSX / PPTX documents even for people not aware of the underlying specifications
robust representation preserving data not recognized by the library (preservation is important, so no data are accidentally deleted)
useful CLI tool for command-line automation (document validation, conversion to other formats, searching text in documents and much more)
MCP servers (actually, they are in an experimental mode) for each document type
a Docker image, which is easy to install and use (only about 30 MB of compressed size) containing the CLI tool and MCP servers
conversion between formats (for example, DOCX to Markdown document and vice versa)

It is very important to me to develop a powerful library that will address some of the limitations I have encountered in existing projects. I designed it so
that all unrecognized data are preserved - elements and attributes the library does not understand are retained in the internal XML DOM
and written back when the document is saved. Another very important issue is to avoid using managed runtimes (such as .NET Framework and Java), which will make my library small and fast. No .NET, no Java Virtual Machine, just pure C++.

I was actually surprised by how small the resulting library was, despite its scope, thanks to its self-containment and pure C++ implementation.
The compressed packages, including the Docker image, have size under 30 MB.

Because I wanted to keep up with modern technologies, I have created MCP servers and a Docker image containing the CLI tool and these MCP servers.
This is my first attempt to create MCP servers, so they are now in experimental mode. The CLI tool was tested and it works.

A quick example

I designed the high-level API as easy to use as possible. Here is a small Word example:

#include "ExyokiOffice/Word/WordDocument.hpp"

int main()
{
    using namespace ExyokiOffice::Word;

    auto editor = WordDocumentEditor::CreateNew();
    editor->AddHeading("Hello world");
    editor->AddParagraph("This document was created by ExyokiOffice.");
    editor->SaveToFile("Hello.docx");
}

And here is a small Excel example:

#include "ExyokiOffice/Excel/ExcelDocument.hpp"

int main()
{
    using namespace ExyokiOffice::Excel;

    auto editor = ExcelDocumentEditor::CreateNew();
    auto sheet = editor->FirstWorksheet();
    sheet->SetCellText(1, 1, "Hello world");
    sheet->SetCellText(2, 1, "This workbook was created by ExyokiOffice.");
    editor->SaveToFile("Hello.xlsx");
}

Why another Office library?

You may ask: why do we need another office library? Well, there are several important differences:

Content preservation as a contract: When you open a document with charts, SmartArt or custom extensions, the usual question using open source libraries is, what will I lose? In ExyokiOffice, unknown content is preserved in the internal XML DOM tree during the modification and then saved back.
Deployment without dependencies: Permissive MIT license and dependency only on the standard C++ library.
All-in-one library: All three document formats are covered by a single library. One API for all three types!
High-level API and low-level DOM united: You can easily use the high-level API editors for common operations and when they aren't sufficient, you just simply switch to the low-level API to gain more control
Schema and semantic validation: ExyokiOffice is capable of validation of documents against a specific Office version
CLI tool exyoki: Usable for shell and scripts. Validation, conversion into other formats, fulltext search, redaction without the need to write a single line of code.
MCP servers: Although experimental, they are there to be used with AI agents.
Security model: External resources are curated by a security policy - by default, access to external resources is prohibited.
Verifiability: Code is covered by unit tests, corpus of real documents as a proof of round-trip preservation, fuzzing, code review and manual testing.
AI-friendly: The CLI tool can produce machine-readable output (JSON, XML), which is easier to process using scripts, automation tools and AI agents

CLI tool example

The command-line tool is designed to be simple and easy to use:

exyoki info corpus/word/The_United_States_of_America.docx
exyoki search corpus/word/Open_Source_Software.docx "license" --ignore-case
exyoki validate corpus/excel/Formulas.xlsx
exyoki stat corpus/powerpoint/Yellowstone.pptx
exyoki convert corpus/word/The_United_States_of_America.docx usa.md

Current state and limitations

All major parts of the library are finished and covered by unit tests. Now, I am using a code coverage tool to catch gaps and fix some bugs.
Of course, I feel I am only at the start of a long journey. The library has some important limitations: it cannot do rendering or conversion to raster or SVG images.
No legacy binary formats such as DOC, PPT, XLS. The MCP servers are still experimental and need more real-world testing.

GitHub

ExyokiOffice is available on GitHub under the MIT license.
For all who are working with Office documents using C++, I'd love to get your feedback.
Are you missing a feature that is important to you? Just write an issue!