x-spreadsheet

Last reviewed Aug 26, 2026 · 691 words

I would not start a new project on x-spreadsheet in 2026. It is a genuinely nice piece of engineering, a canvas-rendered, Excel-feeling grid in a single JavaScript dependency with no framework requirement and a footprint measured in kilobytes, and its 14,585 stars are earned. But the repository has gone quiet, the formula engine stops well short of what a spreadsheet user expects, and the same author's line of work has moved on. If you already ship it, keep shipping it; it is MIT-licensed and it does not rot. If you are choosing today, read the last two sections first.

What you actually get in the box

Install with npm install x-data-spreadsheet (the package name differs from the repo name, which catches people) and mount it on an element:

import Spreadsheet from "x-data-spreadsheet";

const sheet = new Spreadsheet("#grid", { showToolbar: true, showGrid: true })
  .loadData({ name: "Sheet1", rows: { 0: { cells: { 0: { text: "Qty" } } } } })
  .change(data => fetch("/api/sheet", { method: "PUT", body: JSON.stringify(data) }));

That gives you cell editing, multi-sheet tabs, copy and paste, freeze panes, merged cells, borders, fonts, number formats, undo, and a toolbar that looks close enough to Excel that nobody needs training. Rendering is a canvas, not thousands of DOM nodes, so a 10,000-row sheet scrolls smoothly on a Raspberry Pi's browser. The whole library is a few hundred kilobytes and it has no runtime dependencies, which for a self-hoster means one static file served by whatever already serves your app.

The formula ceiling is the real limit

Formulas exist, and SUM, AVERAGE, MAX, MIN, IF, AND, OR, and a handful of others work across ranges. Beyond that you are writing your own. There is no VLOOKUP, no date arithmetic worth the name, no array formulas, and no way for a user to paste a moderately clever Excel formula and have it evaluate. The data model is also its own JSON shape, not XLSX; importing a real workbook means running it through a converter like SheetJS first and accepting that styles and most formulas will be lost on the way in. For a data-entry grid that a backend then computes over, none of this matters. For anything a user would call "a spreadsheet", it matters a great deal.

Where it still fits in a self-hosted stack

The honest use case is a bounded grid inside a larger app: an order form with 30 line items, a batch-edit screen for inventory, a config matrix for a home automation dashboard. In those places x-spreadsheet is still lighter and simpler to embed than any competitor, and its change callback makes wiring it to a REST endpoint a five-minute job. It does not need a server, a database, or a build step. Pairing it with a tiny Go or Python backend that validates and stores the JSON is the whole architecture.

What to pick instead for new work

If you need a spreadsheet component with a real formula engine and active maintenance, Univer is the modern answer from the team that built Luckysheet, with a far larger function library and collaborative editing. If what you actually want is a spreadsheet-shaped database with permissions, forms, and an API, Grist or NocoDB are standalone servers that already do all of that. And if the requirement is "open our existing XLSX files in a browser", stop looking at components entirely and run ONLYOFFICE Docs, which renders the real format with the real formulas; the office category lays out that whole field.

What I'd do

Existing app already using x-spreadsheet: pin the version, keep it, and spend zero time worrying. New internal tool that needs a grid with basic sums: still a defensible choice for its size, provided you write down the formula limit where the next developer will see it. New anything that users will call a spreadsheet: Univer for the component, Grist for the app. The MIT license means x-spreadsheet will keep working forever; it just will not keep improving.