IronCalc: a Rust spreadsheet engine you embed rather than open
Main engine of the IronCalc ecosystem
At a glance
- What is it?
- IronCalc is a work-in-progress spreadsheet engine written in Rust, with an xlsx reader and writer and a wasm build aimed at browsers. It is a library for people who need formula evaluation inside their own product, not a finished Excel replacement.
- Who is it for?
- Adopt IronCalc if you need a spreadsheet model you can drive from Rust code and export to xlsx, and you are willing to track a project that describes itself as work in progress. Do not adopt it as a drop-in replacement for Excel or LibreOffice in front of end users who expect the full function set and a mature UI; the README is explicit that the engine and the skins are early.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem IronCalc solves is embedding, not editing
Most spreadsheet software assumes a human in front of a grid. IronCalc assumes a program. The README describes it as a spreadsheet engine and set of tools to work with spreadsheets in diverse settings, and the repository contains the engine plus the xlsx reader and writer. That split matters. If you are building a SaaS product where users upload a workbook, you recalculate it after a data change, and you hand back a file, you need a library that exposes cells and formulas as data structures. You do not need a window. IronCalc is aimed at that case, and at people who want to write their own front end on top of it, whether in a terminal, as a desktop application, or inside a web app. The audience is developers integrating spreadsheet behaviour into something else. It is not aimed at someone looking for a free Excel to install on a laptop, and the README does not pretend otherwise.
The Model is the unit of work, and xlsx is the boundary
The example in the README shows the shape of the API. You construct a model with Model::new_empty, passing a filename, a locale, a timezone and a language tag. You write into it with set_user_input, which takes a sheet index, a row, a column and a string. That string can be a plain number or a formula, and the engine decides which it is. Reading is positional: sheet 0 is the first sheet. Adding a sheet is a separate call, add_sheet, and it returns a Result. Evaluation is not automatic on every write in the example; the code fills a hundred by hundred block of cells, adds a sheet, sets one SUM formula, and then calls model.evaluate() once. Export goes through save_to_xlsx, which writes the model to disk. That is the whole data flow visible in the README: build a model in memory, evaluate, serialise to xlsx. The xlsx reader sits on the other side of the boundary, so the same model type is what you get whether the sheet came from a file or from your own code. The README also notes that more examples live in the examples folder of the xlsx crate, which is where you would look for import behaviour, since the top-level README does not show a load call.
Getting it running: cargo, make, and a Docker demo on port 2080
Three entry points are documented. For the full application, the README gives docker compose up --build and then points a browser at http://localhost:2080. That is the fastest way to see what the project currently does, and it avoids building anything locally. For the library, you add it to Cargo.toml. The README shows a git dependency with a version constraint rather than a crates.io path: ironcalc = { git = "https://github.com/ironcalc/IronCalc", version = "0.8" }. That is worth noticing, because it means your build resolves against the repository rather than the registry, and you should confirm on your own whether a published crate exists for the version you want. Building from source is cargo build --release. Testing is make tests, which the README says runs unit tests, integration tests, linter tests and formatting tests together. Coverage is make coverage, followed by serving target/coverage/html with python -m http.server. API docs are generated with make docs into target/doc, again served with python -m http.server, and the published version lives on docs.rs under the ironcalc crate name. The README also links a browser preview at app.ironcalc.com, which the project labels early testing.
Where the project is thin, and where it will bite you
The README opens by calling IronCalc new and work in progress. That is not modesty boilerplate; it is the most useful sentence in the document. It means formula coverage is not something you should assume. The example uses SUM, and the README does not enumerate which functions are implemented, so the only honest way to check is to try your own workbooks. The call for collaborators says the project does not have a large community yet and is at very early stages, which has a practical consequence: when a formula evaluates differently from Excel, there may be no existing issue describing it and no answer waiting. The API surface shown is also low level. Cell access is by numeric row and column, sheet access is by index, and there is no mention of a range object, a named-range API, or a calculation dependency graph you can inspect. If your application needs to know which cells a formula depends on so you can invalidate a cache selectively, the README gives you nothing to work with, and you would be re-evaluating the model. The skins are described as something the project will build, in the future tense, so the terminal and desktop front ends are plans rather than shipped components.
The real alternative is a formula library, not another grid
If you only need to evaluate formulas and you are already in Python, the comparison that matters is not Excel. It is a formula evaluation library such as formulas or pycel, which parse a workbook and compute values without offering a document model you can edit and write back. IronCalc is the other trade. It gives you a mutable Model with set_user_input and add_sheet, and it writes xlsx through save_to_xlsx, so the round trip is part of the design rather than an add-on. The cost of that design is that you take on a Rust dependency and, if you are not writing Rust, a language binding layer. The README lists Python, JavaScript via wasm, and nodejs as intended targets, and mentions R, Julia and Go as possibilities. Intended is the operative word. If your team is Python-first and needs a spreadsheet engine this quarter, a pure-Python evaluator that reads xlsx and returns values will get you further, as long as you accept that you cannot hand an edited workbook back. Choose IronCalc when the edit and the export are the point. Choose a read-only evaluator when they are not.
Maintenance cost, licensing, and what to pin
The repository is dual licensed under MIT and Apache-2.0, at your option, and both licence files are named in the README. That is the same permissive pairing Rust projects commonly use, and it is friendlier to commercial embedding than a copyleft licence would be. This is not legal advice; if you are shipping it inside a product, have your own counsel read LICENSE-MIT and LICENSE-Apache-2.0 rather than taking a summary. On maintenance, the release cadence visible in the material is tight: v0.8.0 and v0.8.2 landed on the same day in late July, with v0.8.3 following a few days later. Frequent point releases at an 0.x version mean the public API can still move under you. The README pins the dependency at version 0.8 in its own example, and that is the pattern to copy: pin the git revision or the exact version in Cargo.toml, and read the release notes before bumping, rather than tracking a branch. Because the README points at a git dependency rather than a registry version, your lockfile is doing more work than usual, and a rebuild on a machine without that lockfile may resolve to something newer than you tested.
Who should pick this up now
The honest summary is that IronCalc is a bet on a small, actively developed engine rather than a finished product. The people who should look at it now are the ones the README addresses directly: a team that wants a permissively licensed spreadsheet core inside its own application and is prepared to read Rust source when a formula misbehaves. The Docker command gives you a same-day way to test that premise against a real workbook. The people who should wait are anyone who needs a stable API contract, a documented function list, or a user-facing editor today; the README's own language about early stages and missing community is the clearest signal on that point. The one thing to verify before you write production code is the xlsx round trip on your own files, because import and export are the parts of the design that distinguish it from a formula evaluator, and they are the parts the top-level README demonstrates least.
Editorial conclusion
Adopt IronCalc if you need a spreadsheet model you can drive from Rust code and export to xlsx, and you are willing to track a project that describes itself as work in progress. Do not adopt it as a drop-in replacement for Excel or LibreOffice in front of end users who expect the full function set and a mature UI; the README is explicit that the engine and the skins are early. Before committing, run the Docker demo at port 2080 with your own xlsx file, call save_to_xlsx on the result, and reopen it in Excel to see which formulas survive the round trip. That single test tells you more about fit than any feature list.
Community notes