ranuts/document: Edit DOCX, XLSX, and PPTX in a Browser Tab, Offline

What ranuts/document Does and Why It Is Different

Most browser-based document editors send files to a server for conversion and rendering. ranuts/document does the opposite: the OnlyOffice engine and its WASM-based format converter run inside the browser tab. No file leaves the device during editing. The live site is at edit.chaxus.com, where you can open a DOCX file and edit it without creating an account or accepting a privacy policy covering your file contents.

The project targets three kinds of users. Individuals who handle sensitive documents and do not want those documents on third-party servers benefit from the offline-capable, upload-free design. Developers who need to embed a document editor in their application can use the postMessage API without building or licensing a server-side document processor. Self-hosters who want a private document editing service for a team can deploy the static build behind any web server.

The README's feature list includes a point that distinguishes this from simple file viewers: real editing, not preview. DOCX, XLSX, PPTX, and CSV files are fully editable, not just readable.

Format Support and What Each Route Does

The editor opens and saves DOCX for documents, XLSX and CSV for spreadsheets, and PPTX for presentations. Legacy formats (.doc, .xls, .ppt) and ODF variants (.odt, .ods, .odp) open in those same editors. RTF and TXT files also open in the document editor. PDFs open in an annotation and form-filling mode and can be exported to PDF from any of the other formats.

CSV encoding is handled on both open and export: the README states that UTF-8, GB18030, and Latin-1 are sniffed on open. This is a specific detail for teams working with spreadsheets from non-English-language systems.

The application has four main routes. The root route at / is the landing page; the editor bundle is not loaded until you open a file, which keeps the initial page load lighter. The /editor route holds the editor itself. The /history route lists all documents the current browser is holding in autosave. The /help and /changelog routes are generated from Markdown files in the repository's content/ directory.

Running ranuts/document: Docker and From Source

The quickest self-hosting path is Docker:

docker run -d --name document -p 8080:80 ghcr.io/ranuts/document:latest

This pulls the pre-built image from the GitHub Container Registry and serves the application on port 8080. The docker-compose.yaml in the repository shows a named variant with optional configuration for basic authentication and TLS certificates.

To run from source:

git clone https://github.com/ranuts/document.git
cd document
pnpm install
pnpm run dev

This starts the development server with Vite. The build produces a static directory of files, as shown in the Dockerfile, which uses a static web server (joseluisq/static-web-server) for the final container image rather than Node.js.

The production Dockerfile builds with Node.js and copies only the built output into a static-web-server container. The sws.toml file in the repository configures cache headers for the Docker deployment to prevent stale browser caches after image updates.

Autosave, Seven-Day Retention, and the /history Route

While you edit, the browser saves the document into IndexedDB so a refresh, closed tab, or crash does not lose work. When you reopen the editor, it offers the saved copy back. These copies are specific to the browser and device; they do not sync across devices.

Each document is deleted from the browser automatically seven days after you last edited or opened it. The /history route lists everything the current browser is holding, with a delete button on each row, a delete-all button, and a switch to disable autosave entirely. On a shared machine, /history is the page to visit to clear documents left by a previous session.

On Chromium-based browsers, saving writes back to the original file you picked from the filesystem, so the document lives in your own file system rather than the downloads folder. On other browsers, each save downloads the file again. The README notes this browser-specific behavior plainly.

Embedding via iframe and the postMessage API

The full postMessage API allows you to drive the editor from a host page. Open a document from a URL, listen for save events, and upload the modified file to your own backend:

<iframe
  id="documentEditor"
  src="https://your-deployment/editor?embed=1"
  style="width: 100%; height: 720px; border: 0"
></iframe>

iframe.contentWindow.postMessage(
  { id: '1', type: 'document:open-url', payload: { url: 'https://example.com/doc.xlsx' } },
  'https://your-deployment',
);

window.addEventListener('message', (e) => {
  if (e.data?.type === 'document:opened') console.log('Ready to edit');
  if (e.data?.type === 'document:saved') uploadFile(e.data.payload.file);
});

Embedded editors keep no local history; the document belongs to the host page. A full API reference covering every message type, the origin allowlist, read-only mode, and the save flow is documented at docs/embed-api.md in the repository. The README notes the editor is also available as a component via the @ranui/preview npm package.

Limitations and Trade-offs

The WASM-based OnlyOffice engine has different performance characteristics than a native desktop application. Large files with complex formatting, many embedded images, or long spreadsheets may be slower to open or operate than in LibreOffice or Microsoft Office. The README does not specify file size limits.

The offline capability and client-side processing mean there is no server-side search, no server-side version history beyond the seven-day browser cache, and no multi-user simultaneous editing. Each browser holds its own local state. These are deliberate design constraints that follow from the privacy-first, no-upload architecture.

A practical alternative for the self-hosting case is OnlyOffice Document Server, which runs the same editing engine but with a full server component. OnlyOffice Document Server supports collaborative editing, server-side storage, and user management; it is a more complex deployment and involves its own license terms. ranuts/document is essentially a thin browser host for the same editor core without any of that server infrastructure.

Agent-Ready Mode, WebMCP, and License

The README lists an agent-ready feature: the editor exposes WebMCP tools so a browser AI agent can open, convert, and read documents. This is a newer capability in v0.0.6 and allows AI coding assistants or automation agents running in the browser context to interact with documents programmatically.

The project is licensed under AGPL-3.0. That means running a modified version as a public service requires publishing the source of the modifications. Teams that want to customize the editor for internal use without releasing their changes should read the AGPL terms before deploying. The current version is 0.0.6, released on 2026-09-02. The last push to the repository was on 2026-09-26, showing active development on this young project.

Editorial conclusion

ranuts/document is a good fit for anyone who needs to edit Office-format files without installing desktop software or uploading documents to a cloud service. The seven-day autosave in IndexedDB is a convenience, not a backup, and the README makes that distinction clearly: keep exporting anything you want to keep. The AGPL-3.0 license requires anyone running a modified version as a public service to publish their changes. For teams that need persistent server-side storage and user management, pairing the embedded editor with a custom backend via the postMessage API is the documented path.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. ranuts/document on GitHub
4. README
5. Releases