Bento: a PowerPoint alternative that ships as one HTML file
Bento, the office suite that fits in a file
At a glance
- What is it?
- Bento packs an editor, presenter and viewer into a single .bento.html document that rewrites itself on save. It is a strong fit for people who want decks they own outright, and a poor fit for anyone who needs phone editing or verified identity in collaboration.
- Who is it for?
- Adopt Bento if you want decks that survive without a vendor: the file carries its own editor, the document is plain JSON at the top of the file, and the MIT licence lets you fork or vendor it. Do not adopt it if you need to edit on a phone, or if collaboration between people who do not already trust each other is a requirement, since presence names are described as claims rather than proofs and signed frames are designed but not built.
- Can I use it commercially?
- Yes. MIT 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 1 day ago.
- What is it written in?
- Mainly TypeScript, 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 Bento picks: documents you hold rather than documents you rent
The README frames the project against cloud office suites: office documents, it argues, used to be things you had and are now things you rent, readable only while a company keeps its servers running. Bento's answer is a single HTML file that carries the deck, the fonts, the images, the charts, the animations and the editor itself. The person you send it to needs no account and no installer. The README states the shell is roughly 560 KB. The intended audience is anyone who has to hand a presentation to someone outside their organisation and cannot assume that person has the right software, the right login, or a working network. It is also aimed at people who want to read their own files in ten years: the README claims a copy from 2026 will open in 2036, which rests on the format being plain HTML plus a JSON block rather than a binary container. That claim is a design intention, not something this review can verify.
One renderer, three surfaces, and a document block left in plaintext
The architecture paragraph in the README is unusually specific. slides/src/model.ts defines the JSON document model. A single renderer, render.ts, draws that model for the editor canvas, for thumbnails, and for present mode, with Reveal.js handling navigation. Morph transitions are computed from the model rather than read off the DOM, which is why duplicating a slide and rearranging elements produces motion without hand-authored keyframes: elements that share an id are interpolated across position, size, colour and gradients. Animation lives in anim.ts and charts in charts.ts, both written in-house, so a bar chart that becomes a pie chart morphs through the same model-driven path. Collaboration is an in-house CRDT in sync/crdt.ts, described as pure data and fuzz-tested by scripts/test-sync.ts. The build compresses the shell but deliberately leaves the document block as plaintext JSON so that older files and outside tools can splice it. That last decision is the one that makes the rest of the product possible: an AI agent with filesystem access edits the #bento-doc JSON in place, and the README names Claude Code, Cursor and Aider as examples, with a packaged bento-slides skill installable via /plugin marketplace add nyblnet/bento.
Building the single file, and what the release artefacts actually are
The README gives the build path plainly. You need Node 20 or newer and npm. From the repository root you run cd slides, then npm install, then npm run dev for a dev server on http://localhost:5173, or npm run build:single to produce dist-single/Bento_Slides.bento.html, which the README calls the product. There is no backend to stand up. The CRDT convergence rig runs with node scripts/test-sync.ts from the repository root. If you would rather not build, the Releases page carries the built file, and the README also points at a direct download path on bento.page, describing it as about 560 KB with no account and no installer. The release history shows the cadence: v1.0.19, v1.0.18 and v1.0.17 landed within roughly a month, tagged under bento/slides. Updates are ECDSA-signed and offered inside the app, and the README states that updating writes a new file while the old one remains as your rollback. Releases are cut locally so the signing key stays on the maintainer's machine, per docs/RELEASING.md, which is a deliberate trade: no CI can cut a release for you, and the trust anchor is one person's laptop.
The collaboration model: the file is the invitation
Collaboration here is not a hosted service. Keys are minted client-side when the document is created and live only inside the file, so possession of the file equals membership and Rotate keys is the revocation mechanism. Transport is an optional relay in server/sync-worker/, which the README describes as a blind relay storing ciphertext; by its own account the relay sees ciphertext, connection timing, and a hash of the room key, and cannot read content, names or structure. Encryption is AES-GCM. The README is candid that presence names are claims rather than proofs, which is acceptable inside a room where everyone already shares a key, and that enterprise identity would need signed frames, which are designed but not built. A second stated trade-off is undo: during live collaboration it is snapshot-based and can revert a collaborator's concurrent edit to the same property. Those two sentences are the most useful lines in the README, because they tell you exactly where the collaboration story stops.
Where Bento is the wrong tool
The README admits editing is desktop-first and that phones view and present well but are not the place to author. If your workflow assumes people will fix a slide on a train, Bento does not meet it. The single-file model has a second cost that follows from its strength: every collaborator holds a full copy of the document, so a 200 MB deck of embedded images is a 200 MB file per person, and there is no server-side asset store to thin it out. The relay is optional and blind by design, which means there is no server that can hold authoritative state, enforce roles, or recover a document nobody kept. Key rotation is the only revocation lever, and it is manual. Finally, the update path depends on a static manifest plus ECDSA signatures and version monotonicity verified in-app; the README says the check sends nothing about you or your document, but it also means you are trusting a locally held signing key and a manifest host. If your environment requires reproducible builds from CI with an audited release pipeline, this arrangement will not satisfy it as described.
The honest comparison: Reveal.js plus a JSON file
The nearest thing to Bento is not another office suite. It is Reveal.js, which the README confirms drives navigation inside Bento, combined with your own JSON or Markdown and a small build step. That combination gives you a deck you can version in git and render anywhere, and it is far easier to diff and review than a 560 KB HTML file with an embedded document block. What it does not give you is an editor inside the artefact. With plain Reveal.js, the person who receives the deck cannot open it and change a bullet without a toolchain; with Bento they open the file and type. The same split applies to morph transitions: Reveal.js exposes fragments and transitions, while Bento computes morphs from the model by matching element ids, which is a different mechanism with a different failure mode, since ids that do not match will not animate. If your team already lives in a text editor and a git workflow, plain Reveal.js is the smaller dependency. If your team hands decks to non-technical people who must be able to edit them, the embedded editor is the whole point.
Licence, maintenance and what upgrading costs you
The repository is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That matters here because the product is a distributable file: you can ship Bento_Slides.bento.html inside your own product, or fork slides/ and change the renderer, without a copyleft obligation on your changes. It does not give you the maintainer's signing key, so a fork cannot produce updates that the official app will accept, and a fork that wants its own signed update channel has to build that trust chain itself. On maintenance, the commit history shows active work through September 2026 and a release roughly every one to three weeks across the three versions listed. The upgrade mechanics are lighter than most desktop software: updating writes a new file and leaves the previous one in place, so rollback is a matter of reopening the old file rather than reinstalling. The cost that does not go away is the document format. docs/format.md is described as the normative spec for the bento/slides model, and any tooling you write against the #bento-doc JSON depends on that spec holding. This is a description of the licence terms, not legal advice; check the MIT text in the repository against your own distribution plans.
Editorial conclusion
Adopt Bento if you want decks that survive without a vendor: the file carries its own editor, the document is plain JSON at the top of the file, and the MIT licence lets you fork or vendor it. Do not adopt it if you need to edit on a phone, or if collaboration between people who do not already trust each other is a requirement, since presence names are described as claims rather than proofs and signed frames are designed but not built. Before committing, open a release file in your target browser, confirm File System Access save works there or falls back to download, and read docs/format.md against a deck you already own to see whether your content survives the round trip.
Community notes