EdenText: a browser word processor for .docx and .odt that keeps files on your machine

A word processor with no server and no account

EdenText presents itself as a full-featured word processor right in the browser, free, open source and private by design. The privacy claim is architectural rather than a promise: there is no server, no account, and processing runs locally, so documents never leave the computer. The consequence for the user is that opening the app is the whole setup. You can use the hosted page at edentext.app, or install it as an app and work offline, and the first download is about 2 MB for most languages, with dictionaries and fonts loading as needed. The privacy story has one documented exception. The site counts anonymous visits with GoatCounter, which is EU-hosted and sets no cookies, and the editor itself sends nothing, unless the optional AI assistant is switched on, in which case requests go straight to the provider you chose. Documents are autosaved in the browser, and Recent documents can be configured to delete closed ones at the next start, or not to keep them at all.

Round-trip and layout tests against Word and LibreOffice

The hard part of a browser word processor is not the editing, it is the file format. EdenText opens and saves .odt and .docx, exports PDF, and handles templates in .ott and .dotx formats, plus password-protected files in both formats. The README states that documents keep their layout in Word, LibreOffice and EdenText, verified by automated round-trip and layout tests, and the script list in package.json shows how much of that verification is machine-driven: there are separate suites for LibreOffice round trips, a fuzz test, a render consistency test and a password test, alongside smoke, DOM, layout, monkey, tabs and render parity suites. The parity fixtures are generated by their own script. The README also asks for bug reports specifically on documents that display differently from Word, LibreOffice or WPS Office, and offers to turn the attached file into a test case, which is a candid description of where the compatibility boundary sits.

Page layout, styles, tables and the apparatus of a thesis

The feature list is closer to a desktop office suite than to a web editor. Layout covers A4 and Letter pages, margins, headers and footers, footnotes, columns, page and line numbering and watermarks, and for books it offers mirrored margins and chapters opening on a right-hand page. Styles cover paragraph, character, table and list styles with inheritance, plus chapter numbering. Tables have styles, sorting and spreadsheet-style formulas. The thesis-oriented set includes a table of contents, captions, cross-references, citations and a bibliography, an alphabetical index, and formulas written in LaTeX. Password-protected files are supported in both formats, and a letter gallery following DIN 5008 covers the German business letter layout. The gallery in the README shows what these combine into: a thesis with numbered chapters, formulas and a running header, a book spread on facing pages, a two column newsletter, and a table with formulas.

Track changes, comments and an AI assistant you can switch off

The review tools are the part that separates this from a plain editor. EdenText provides track changes and threaded comments with margin balloons, printable markup, spell check for English, German, Spanish, French, Portuguese, Greek, Russian and Ukrainian, a synonyms feature for all of those except Greek, and a grammar check for English. The AI assistant is optional and described as coming with your own provider or a local model. It answers questions about the document and edits it as tracked changes, so an AI edit lands in the same review surface a human editor would use. It can be switched off, and when it is on, requests go directly to the provider, without an EdenText server in the middle. That design keeps the privacy claim intact by construction, at the cost of the user having to pick and configure a provider themselves.

Saving in the browser, and the download fallback

Saving is where a browser based editor has to negotiate with the browser, and the README is specific about the tiers. In Chrome and Edge, Save writes back to the file that was opened. Brave does the same once the flag brave://flags/#file-system-access-api is enabled. Everywhere else, each save is a download, and the advice is to turn on Always ask where to save in the browser settings so the location can be picked. The file system access API is what makes the difference, and the fallback is a download rather than an overwrite, which is safer but changes the workflow of repeated saves. The same browser integration also handles the recovery case: the browser keeps the last three versions of the open document in case it fails to load, and a private window leaves nothing behind once closed.

Self-hosting is a static build behind nginx

The project is set up to be hosted by someone else, and the Dockerfile shows how little a server has to do. The build stage compiles the Svelte and TypeScript application into static files, and the runtime stage is only nginx serving that directory:

FROM --platform=$BUILDPLATFORM node:24-alpine AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

The comment above it makes the point that there is no server side and no state, and that the build stage is pinned to the builder's architecture because only the nginx stage differs per target platform. The scripts in package.json are the ordinary Vite and Vitest set, with svelte-check for type checking and a check script that points it at the project's tsconfig. A developer runs the dev script for a local server on the host, the build script to produce the dist directory, and the preview script to serve the built output. Everything above that layer runs in the browser, which is why the deployment story is this short.

Beta status, an AGPL licence and a commercial licence file

The project labels itself beta, and the README says plainly that it is still in beta and actively developed, that tests and round-trip checks verify that it works, and that bugs cannot be ruled out at this stage, so documents you care about need backups. The readme badge and the version list agree on the pace: v0.11.0 on 2026-10-20, then v0.10.1 and v0.10.0 both on 2026-10-17, with the last push on 2026-10-20. The licence is AGPL-3.0-only, and the repository root contains both a LICENSE file and a LICENSE.commercial.md, so a commercial path exists alongside the copyleft one, along with a THIRD-PARTY-NOTICES.md file. The interface is available in English, German, Spanish, French, Portuguese, Greek, Russian, Ukrainian, Japanese, Simplified Chinese and Traditional Chinese, with a separate readme per language. Each release also carries unsigned desktop installers built with Electron, and the macOS one has to be opened through a right-click Open the first time because it is unsigned, with an xattr command given for the quarantine attribute.

Editorial conclusion

EdenText fits a writer or researcher who needs to open, edit and save real .docx or .odt files on a machine where uploading documents to a web service is not acceptable, and who can self-host the static build. It does not fit a production document pipeline that needs a signed release, since the project is still labelled beta and the desktop installers are unsigned. Verify first that your files survive a round trip in LibreOffice and Word, since the project itself asks for bug reports on documents that render differently, and keep the backup the browser keeps only as a safety net rather than as a strategy.

Frequently asked questions

Official sources

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