Bento Slides: a PowerPoint alternative that ships as one HTML file

The problem Bento Slides solves, and who actually needs it

A .pptx file is a container that expects an application. Lose the application, or lose the licence, and the file becomes a research project. Bento Slides inverts that: the released artifact is Bento_Slides.bento.html, roughly 560 KB, and the README describes it as carrying its own viewer, presenter and editor. The recipient needs no account and no installer. They open the file in a modern browser and the file is the software.

The audience is narrower than the tagline suggests. This suits people who distribute decks to audiences they cannot control: consultants sending proposals to clients, trainers handing material to a partner organisation, anyone who has watched a deck arrive as a corrupted attachment. It also suits teams that want their presentation source under version control, because the README states the document sits in a plain, readable JSON block at the top of the file. That makes a diff meaningful in a way a binary deck never is.

It is not for people who want Office compatibility. There is no mention of importing or exporting .pptx anywhere in the README. The export path named there is PDF.

How a .bento.html file is put together

The architecture paragraph in the README is unusually specific, and it is worth reading literally. slides/src/model.ts defines the JSON document model. A single renderer, render.ts, draws that model for three surfaces: the editor canvas, thumbnails, and present mode. Reveal.js drives navigation, but morphs are computed from the model rather than read off the DOM. That distinction matters. DOM-driven animation tends to break when the DOM is rebuilt; model-driven animation survives a re-render because the source of truth is the JSON, not the element tree.

Animation, charts and collaboration are all in-house. anim.ts handles animation, charts.ts draws bar, line, pie and scatter charts without a charting dependency, and sync/crdt.ts holds the collaboration model as pure data. The README states the CRDT is fuzz-tested by scripts/test-sync.ts across hundreds of thousands of convergence checks. The shell compresses to about 560 KB, and the document block is deliberately left as plaintext so that older files and outside tools can splice it.

Collaboration is end-to-end encrypted with AES-GCM, and keys are minted client-side at document creation and live only in the file. The README is direct about the consequence: possession of the file equals membership, and rotating keys is how you revoke. The optional relay in server/sync-worker/ stores ciphertext. According to the README it sees ciphertext, connection timing and a hash of the room key, but not content, names or structure.

Building Bento Slides from source and making a first deck

The README states the build needs Node 20+ and npm, with no backend to stand up. The commands below are copied from the build section. The dev server runs on port 5173, and the single-file build is the product rather than a debug artifact.

cd slides
npm install
npm run dev            # dev server (http://localhost:5173)
npm run build:single   # → dist-single/Bento_Slides.bento.html (the product)

After npm run build:single, the output lands at dist-single/Bento_Slides.bento.html. That is the file you distribute. Open it in a browser and it behaves as the editor; saving rewrites the file with your deck inside, using the File System Access API with a download fallback.

The fastest way to see the format is to open the starter deck, which the README says doubles as the feature tour. If you would rather skip the build, the same file is downloadable from the GitHub Releases page or from bento.page.

For agent workflows, the README describes two routes. File harnesses edit the #bento-doc JSON block in place, and Claude Code users can install a packaged skill from the repository's plugin marketplace:

/plugin marketplace add nyblnet/bento

For any other chatbot, the round trip is manual: Save, then Copy document JSON, let the assistant rewrite it, then paste it back. The README also states the document JSON can be loaded through window.bento.loadDoc.

Where Bento Slides is the wrong tool

The README lists its own trade-offs, and two of them are significant enough to change a purchasing decision.

First, undo during live collaboration is snapshot-based. The README states it can revert a collaborator's concurrent edit to the same property. In practice that means two people adjusting the same element at the same moment can lose one of the changes, and the undo stack will not tell you whose. Character-level text merging exists, so typing is handled more carefully than property edits, but the general case is not solved.

Second, editing is desktop-first. The README says phones view and present well, which is a deliberate scoping decision rather than a bug. If your workflow involves fixing a slide on a train, this is the wrong project.

A third limitation is structural. Presence names are claims, not proofs. The README notes that enterprise identity would need signed frames, and that this is designed but not built. Any environment that requires verified attribution inside a shared room is out of scope today. A fourth: the release process is local. Releases are cut on the maintainer's machine so the signing key never leaves it, which is good for key hygiene and bad for bus factor. There is no stated path for a second person to cut a signed release.

Bento Slides versus a hosted deck platform

The obvious comparison is a browser-based presentation service, where the deck lives on someone's servers and you get a share link. The difference is not features, it is where the document lives and who can revoke access.

With Bento Slides the document is the distribution channel. The README puts it plainly: the file itself is the invitation, and anyone who opens a copy joins. There is no invite list to manage and no server-side permission model to audit. Revocation is key rotation, which the README names as the mechanism.

A hosted platform gives you centralised access control, server-side version history, and identity that is verified rather than claimed. Bento gives you a file that opens in 2036 without a vendor, a plaintext JSON block you can read in a text editor, and a relay that the README says cannot read content, names or structure. Those are opposite bets, and neither is strictly better. If your compliance process requires knowing who edited what with verified identity, the hosted model answers a question Bento explicitly leaves open. If your requirement is that the deck still opens when the vendor is gone, the hosted model cannot answer at all.

Maintenance, releases and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-10. The most recent release listed is bento/slides v1.0.19 on 2026-09-04, following v1.0.18 on 2026-08-15 and v1.0.17 on 2026-08-10. The cadence across those three tags is roughly one release every two to three weeks.

Upgrades are unusual by design. The README states releases are ECDSA-signed and offered in-app, and that updating writes a new file while the old one stays as your rollback. There is no in-place mutation of the running application, so an upgrade is a file swap you perform deliberately. The README also states update checks fetch a static manifest and send nothing about you or your document, and that signature, hash and version monotonicity are verified in-app.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a summary of the licence text, not legal advice, and the repository ships a THIRD_PARTY_NOTICES.md alongside it. If you fork and redistribute the single-file build, that notices file is the one to read before you ship.

Editorial conclusion

Adopt Bento Slides if you need decks that survive without a vendor: the file carries its own editor, the document is plain JSON, and the MIT licence lets you fork the renderer. Do not adopt it if your team edits presentations on phones, since the README states editing is desktop-first, or if you need signed identity in shared rooms rather than key possession. Before committing, open the starter deck at bento.page/slides, check the morph behaviour on elements that share an id in docs/format.md, and run node scripts/test-sync.ts after any change to sync/crdt.ts.

Frequently asked questions

Official sources

1. License: MIT
2. nyblnet/bento on GitHub
3. Project website
4. README
5. Releases