Skip to content
←Back to Open Source

OPEN SOURCE DEEP DIVE

AI OfficeBrowser OfficeOOXMLLocal-First

VibeOffice: A Local-first Office Suite in the Browser

VibeOffice runs three Office-style editors in the browser and writes real DOCX, XLSX and PPTX files locally. Its immutable OOXML baseline preserves untouched structures, macros and embedded objects; Scout is not yet generative AI, but the suite supplies a credible local execution layer for future office agents.

tcchen2026/VibeOffice1.2kJavaScriptApache-2.010 min read

Editing a Word document, spreadsheet or presentation in a browser usually begins with a format conversion. The file is uploaded, loaded into a simplified web editor, and exported again in a form that may look similar while its internal structure has changed. VibeOffice takes a different route. It runs a word processor, spreadsheet editor and presentation editor locally in the browser, and it makes preservation of untouched Office content a central product requirement.

The project is licensed under Apache 2.0 and is written in plain HTML, JavaScript and CSS without a runtime framework or a required build step. Its current suite has three applications: Quire for documents, Ledger for workbooks and Lectern for presentations. It is not yet a complete replacement for Microsoft Office. It is better understood as a focused execution layer: files enter the browser, local code reads, edits and repackages them, and no document-processing backend is involved.

What the three applications do

Quire is the word processor. It opens and saves DOCX, DOCM, DOTX and DOTM files and also handles RTF, HTML, plain text, GitHub-flavored Markdown and Markdown archives with pictures. Its document model includes pagination, sections, tables, styles, headers and footers, comments, tracked changes, tables of contents, mail merge, content controls and equations. Proofing tools include English spelling and grammar checks, a thesaurus and readability statistics. PDF is an export format, not currently an editable input format.

Ledger is the spreadsheet editor. It opens and saves XLSX, XLSM, XLTX and XLTM workbooks, with additional support for CSV, tab-delimited text, plain text and XML Spreadsheet 2003. The project documents 519 worksheet functions, including dynamic arrays, structured references, LAMBDA, XLOOKUP, FILTER, SORT and VSTACK. It also implements pivot tables, conditional formatting, charts, sorting and filtering, data validation, named ranges, scenarios, goal seek, formula auditing and print pagination. Macros remain in macro-enabled workbooks but are not executed in the browser.

Lectern is the presentation editor. It supports PPTX, PPTM, PPSX, PPSM, POTX and POTM. The editor covers masters and layouts, shapes, text, charts, tables, animations, transitions, notes, custom shows, comments, media and SmartArt. It contains 26 built-in diagram layouts and can turn PowerPoint SmartArt into editable content when the source layout is supported. PDF, PNG and single-file HTML are export targets rather than same-format preservation paths.

ApplicationPrimary useSame-format filesAdditional formats
QuireDocuments and long-form layoutDOCX, DOCM, DOTX, DOTMRTF, HTML, TXT, Markdown, Markdown archive
LedgerWorksheets, formulas and chartsXLSX, XLSM, XLTX, XLTMCSV, text, XML Spreadsheet 2003
LecternSlides and presentationsPPTX, PPTM, PPSX, PPSM, POTX, POTMPDF, PNG, single-file HTML

The scope is deliberately concentrated on Office Open XML rather than every legacy office format. The applications do not open DOC, XLS or PPT directly and instead explain how to convert those files. This improves the focus of the preservation work, but it also means the suite is not yet suitable for organizations with large workflows tied to binary Office formats.

Local-first is more than an upload policy

The web edition has no account system and no backend that receives document contents. Files arrive through the browser's picker or drag and drop. Parsing, editing, encryption, decryption, saving and export happen inside the current browser tab. Static programs, fonts and dictionaries are served by the site, but the documents themselves are not sent to a VibeOffice application server. Password-protected files are decrypted locally with the Web Cryptography API and the project's own AES and SHA implementations.

The suite can be installed as a progressive web application and register itself as a handler for DOCX, XLSX and PPTX files. Once installed in Chrome or Edge, it can be opened from a file manager. Its service worker caches versioned static assets for offline use. A Tauri desktop edition keeps the same interface but adds real file writes, desktop draft recovery and native window behavior instead of limiting Save to a browser download.

Local-first does not mean that every network request disappears. The web build needs an initial download, its optional update check contacts VibeOffice's own site, and some fonts and proofing dictionaries are fetched over the same origin. The stronger claim is that document content does not need to pass through a business backend. That boundary can be inspected through the code paths, browser network activity and deployment model, which makes it more actionable than a broad privacy slogan.

The original OOXML package is the baseline

Many browser editors unpack an Office file into a simplified model and generate a new package when the user saves. Any object absent from that model is at risk of disappearing. VibeOffice instead keeps the opened package as an immutable baseline outside ordinary undo snapshots. The editable model records what the user actually changed, and the writer merges those changes back into the original package.

The package graph separates parts into three ownership classes. Opaque parts are not understood by the editor and retain their original bytes and relationships. Merged parts, such as settings-like structures, keep the original document and replace only properties owned by the model. Regenerated parts are rebuilt from editable content while carrying forward retained fragments, identities and dependencies. Macros, embedded objects, unsupported SmartArt, media, ink, 3D models, custom XML and newer Office extensions can all follow this preservation strategy.

Editable objects also keep their original names, IDs and relationship identifiers where possible. Comments, animation targets, hyperlinks, pictures and dependencies therefore do not all receive new identities after a small edit. Moving an unsupported object should change only its outer transform. Changing a shadow should replace that property while leaving unknown effects intact. Copying an object requires copying its dependencies and remapping identities together rather than duplicating only the visible appearance.

A Compatibility Checker runs before save. It is intended to show losses that cost the user content or a working feature, not every internal normalization. Strict Open XML is converted to Transitional Open XML, digital signatures become invalid after a new save, and editing some opaque objects may require conversion into ordinary shapes. Those effects must be reported before the download instead of appearing later as a damaged file in Microsoft Office.

This architecture addresses the hardest part of office compatibility: looking the same is not the same as preserving the package, and a file that opens successfully may still have lost comments, macros, animations or embedded objects. VibeOffice does not attempt to replace the Office model with a simpler one. It keeps the editable model and the original package side by side and treats preservation of untouched content as a save contract.

What the test numbers show, and what they do not

According to the project's own final measurement, the test corpus contains 4,697 real files from public collections associated with LibreOffice, Apache POI and the Open XML SDK. The run records 14,091 driver attempts and 30,919 package or SDK states: 29,341 passed, 670 failed and 908 were excluded. Exclusions include unreadable originals, missing outputs and cases that could not produce a comparable state. The project records them separately rather than counting them as successes.

In LibreOffice render checks for unedited saves, the result is 2,869 of 2,880 Word files, 930 of 935 Excel files and 836 of 837 PowerPoint files. Text inventory retains 776,207 of 776,869 words in Word and all 58,022 words in PowerPoint. Excel cell comparisons match exactly in 883 of 889 saves. These figures show that the project has built a serious, repeatable preservation program. They are still project-reported results from its corpus, not third-party certification, and they do not prove that every enterprise document will be safe.

The known-gap section is equally important. Ledger can still drop SmartArt on a worksheet and loses sheet drawings in another set of 16 test files. Lectern has two named cases that fail to retain an image or PDF media object. Complex layouts, long-running tasks, macro behavior, damaged source packages and full Office acceptance still have boundaries. The README tells users to keep a copy of important files before editing them. That disclosure is more credible than a blanket claim of perfect compatibility because it exposes the failing inputs and the work still remaining.

The project also states that AI coding assistants were used and that it reviews code for similarity to source material that may have appeared in model training. Its first full review was completed in October 2026. For teams evaluating open-source compliance, that statement still needs to be read alongside the license inventory, review records and the organization's own risk process. A technical demonstration is not a legal audit.

The current AI boundary

The suite includes Scout, an assistant character that greets users, performs animations and points to command search, help and keyboard shortcuts. Its own greeting is explicit: "soon-to-be-AI assistant. For now, I mostly fetch." There is no evidence in the inspected repository that Scout already calls a language model or can rewrite a document, generate spreadsheet formulas or execute an end-to-end office workflow.

The accurate description is therefore a local office execution layer aimed at the coming generation of AI agents, not an office suite with a mature generative assistant. It solves three difficult prerequisites first: reading and writing real Office files in the browser, preserving unknown structures and reporting losses. That matters to agent systems because a model can propose intent or edits, but something still has to handle ZIP packages, XML, relationships, identities, compatibility and the final save. VibeOffice does not yet expose a public MCP service or stable agent API, so this remains foundational capability rather than a finished agent integration.

That boundary should remain visible. Office files are not plain text. Macros, comments, external relationships, animations and embedded workbooks can carry real business logic that a model never sees. A useful AI office tool must first know what it changed, what it left alone and which capabilities will fail after saving. Most of VibeOffice's engineering is directed at that layer.

Where it fits, and where it does not

It fits individuals and small teams that prefer documents to stay on their own machine, browser-based tools that need local file processing, offline demonstrations and developers studying Office Open XML or agent execution layers. It is a natural candidate for users who receive complex DOCX, XLSX and PPTX files from mixed sources, need to make limited edits and want the rest of the package to remain as close to the original as possible.

It is not yet a complete Microsoft Office replacement. Real-time collaboration, macro execution, every advanced Excel analysis path, complex PowerPoint master and SmartArt editing, legacy binary Office files and complete compatibility with all enterprise templates are outside the demonstrated scope. Organizations that require formal compatibility certification, uninterrupted team collaboration or guaranteed behavior from every Office feature should continue to use a mature office suite and treat VibeOffice as a supplemental tool.

The practical evaluation is to choose a representative set of real files covering fonts, headers and footers, comments, formulas, charts, embedded objects and macros. Save without editing, make a local edit, undo it, save again, and reopen the results in Microsoft Office or LibreOffice. With original backups retained, VibeOffice is already worth testing as a local-first option and as a concrete example of the execution layer that AI office tools still need to build.

Repository: github.com/tcchen2026/VibeOffice. Live application: vibeoffice.work.

Related Projects

As an Amazon Associate, we earn from qualifying purchases.