See a document first. Integrate second. Edit third.

Real SumDoc, SumSheet and SumSlide editors, in your browser, no install and no sign-up — a demo cabin opens one of our sample files. Edits live only inside the cabin and are not saved anywhere.

• Wild-horse adoption flyer — 1 page, photography
• Workshop brochure (EPA/USDA template) — 2 pages
• Annual manager's report — 32 pages, 33 MB
• Annual manager's report #2 — charts linked to a workbook
• Federal quality-assurance form — 18 fillable content controls
• Arabic romanization tables — right-to-left text, Library of Congress
• Research executive summary — 2 pages, real footnotes
• Working draft under review — 24 pages, comments & tracked changes
• Sample workbook — live formulas (SumSheet) — 3 sheets, SUM/AVERAGE/IF and cross-sheet references, recalculated in the cabin
• Full function surface (SumSheet) — 451 worksheet functions, one real formula each, across 9 categories; 432 of them verified value-by-value in the cabin, and the 1 that return no value yet plus the 10 that differ are named row by row
• Product launch plan (SumSlide) — 5 slides; every visitor edits a private copy that is discarded when the tab closes

Honest note, measured today: in the two long reports and the workshop brochure, some captions and headings are still drawn on top of body text — we built a measure for it and it names 19 such places; 17 of them a reader would notice. Text running past the sheet edge — 83 lines this morning — is fixed, and so is the brochure page that drew every glyph twice. No text is lost in any of these files: every word is on the page, and the files are verbatim originals — download them and compare.

No package manager, no install: download one binary from this site and turn any DOCX into a self-contained HTML page that opens with a double-click — offline, view-only, honest about what it didn't draw.

curl -LO https://sumoffice.com/dl/sumdoc && chmod +x sumdoc
./sumdoc render report.docx -o report.html

145 MB, darwin-arm64 today — more platforms and a slimmer build are coming; sha256. An npm wrapper may follow — it is not required.

Working with an AI agent? Paste this to it

Everything below is on this page already — the block just saves you the explaining.

Show me report.docx as a web page, offline, without installing Office.
Use SumOffice: download the binary, verify the checksum, render the file.

  curl -LO https://sumoffice.com/dl/sumdoc
  shasum -a 256 -c <(curl -s https://sumoffice.com/dl/sumdoc.sha256)
  chmod +x sumdoc
  ./sumdoc render report.docx -o report.html

The result is one self-contained HTML file: no server, no network, view-only.
Machine-readable notes about this engine: https://sumoffice.com/llms.txt

Agents can also read llms.txt directly — it is the machine-readable front door of this site and states plainly what is live and what is not.

The same three cores as a library in your own process: open, edit, recalculate and save .xlsx and .xlsm with the macros kept, read .docx, add slides to .pptx. Native cores ship inside the package — nothing compiles on install, and no Microsoft Office or LibreOffice is needed. The file never leaves the machine your code runs on.

• Python — pip install sumoffice
• Node.js — npm install sumoffice
• .NET — dotnet add package SumOffice
• Java — com.sumoffice:sumoffice on Maven Central
• C and C++ — native libraries for macOS, Linux and Windows

Free without a key: 30 documents per day. Opening or saving a file in any of the three cores shares one daily count; edits inside an open file are free.

One binary, one localhost port, your WebView. The full walk-through with the bootstrap handshake, document events and the headless session protocol is the quickstart.

Our own SumDoc and SumSheet apps are exactly this integration shipped to the stores: a system WebView around the same surface. The SDK is those same bits — the engine and the page from the store builds — packaged as a drop-in for your app, released together with each build under the same version number. Three kits, all at 2026.4.3: SumDoc, SumSheet and now SumSlide.

SumDoc (.docx / .docm):

Android SDK 2026.4.3 · 23 MB → · README · sha256
arm64-v8a only · adds ~160 MB per architecture to your APK — ship as an App Bundle

iOS SDK 2026.4.3 · 83 MB → · README · sha256
FastDocMobileCore.xcframework (device + simulator, arm64) + page + bridge + reference view · iOS 16+ · adds ~130 MB to your binary

SumSheet (.xlsx / .xlsm):

Android SDK 2026.4.3 · 25 MB → · README · sha256
arm64-v8a only · adds ~90 MB to your APK — ship as an App Bundle

iOS SDK 2026.4.3 · 72 MB → · README · sha256
FastSheetMobileCore.xcframework (device + simulator, arm64) + page + bridge + reference view · iOS 16+ · adds ~50 MB to your binary

SumSlide (.pptx):

Android SDK 2026.4.3 · 15 MB → · README · sha256
arm64-v8a only · minSdk 26 · the core runs in your process over JNI, the editor page in a WebView

iOS SDK 2026.4.3 · 33 MB → · README · sha256
SumSlideCore.xcframework, static (device + simulator, arm64) + page + SlidesEditorView.swift · iOS 17+

SumSlide in three steps: Android — copy jniLibs/, assets/ and the two bridge classes keeping the com.sumoffice.slides package (the JNI symbols are bound to it), then new SlidesHost(activity, save), host.open(name, bytes) off the UI thread and host.createView() into your layout; iOS — add SumSlideCore.xcframework (do not embed, it is static), the sumslide/ folder as a folder reference and SlidesEditorView.swift, then SumSlideSession().open(name:data:) and SlidesEditorView(session:). Saving hands your own code the .pptx bytes — where they go is your decision.

• 1. Add: Android — copy jniLibs/, assets/ and the two bridge files into your module, add androidx.webkit and abiFilters += "arm64-v8a"; iOS — add the xcframework, the bridge (SumDoc: with its bridging header), the page folder (assets/a4 or assets/f1) as a folder reference and the reference EditorWebView.swift.
• 2. Show: Android — a WebView with JavaScript, DOM storage and file access on, the bridge attached (SumDoc: FastDocWebBridge(webView, bytes, …).attach(); SumSheet: a document-start script with the workbook and addJavascriptInterface(SumSheetWebBridge(…), "F1Native")), load file:///android_asset/a4/index.html or …/f1/index.html; iOS — a WKWebView with the bridge as its message handler (SumDoc via the sumdoc:// scheme handler, SumSheet via loadFileURL).
• 3. Open: hand over the .docx / .xlsx bytes — from your bundle, a picker, an ACTION_VIEW intent or onOpenURL — the reference activity and view in the zips do all of it.

Verified on empty projects built from the READMEs alone. SumDoc: Android — the bundled sample and a 37 KB business letter render 1.5–2 s after a cold launch on an arm64 emulator and about 3.5 s on a Galaxy A22 5G; iOS — 2–3.4 s on the simulator, 2.5 s / 2.1 s (first launch / relaunch) on an iPhone 12 and 3.2 s / 1.8 s on an iPhone 11 Pro Max, "Open in…" included. SumSheet: Android — the bundled workbook shows its grid, ribbon and sheet tabs 16 s after launch on an arm64 emulator and 18–20 s on a Galaxy A22 5G (the page is the full 30 MB editor; those are the store app's numbers on the same devices); iOS — 13 s from launch to the grid on the simulator, and the host runs on an iPhone 12. SumSlide: the 2026.4.3 kits were taken through from the finished archive on 03.10.2026 — a deck opens on an arm64 emulator and on the simulator, the title is edited, and the saved .pptx carries the edit in slide1.xml. Free to evaluate and prototype; for production licensing contact us.

Viewing and editing are one engine and one layout — upgrading is not a re-integration. Commands run sequentially, every response echoes your id, and a refusal arrives before the change: the document, its history and the file stay untouched. See quickstart, Path B.

The editors run as a server inside your system: no accounts, no passwords, no database of their own. Your users stay logged in to your portal with your SSO; the editor learns who they are from your API and gets the file from your API. Nothing to migrate, nothing to decide — the file that already lives with you opens in SumDoc or SumSheet.

If you have a personal cabinet and files, both required URLs already exist. Two people in one file already work on these two URLs. How the co-editing server is built and what is measured: Collaborative editing. Conflicts are honest: a version precondition (X-Layers-Attachment-Version) means nobody's edit is silently overwritten.

WOPI is in the image as a second driver of the same door (--wopi-hosts, an allow-list, off by default; /hosting/discovery and /hosting/capabilities; CheckFileInfo, GetFile, PutFile, locks, proof keys, the frame's postMessage). We have not yet run it against a real Nextcloud or other WOPI storage ourselves, so we do not list them as supported here; a measured walkthrough will replace this sentence when it exists.

docker run -d --name sumdoc-webhost --restart unless-stopped -p 127.0.0.1:8090:8090 \
  -v /srv/sumdoc-cabins:/data/cabins hissih/sumdoc-webhost:latest \
  --base-path /sumdoc --max-cabins 12 --idle-min 20 \
  --auth-url   'https://your-system/v1/me' \
  --attach-url 'https://your-system/v1/attachments/{id}/content'

Full contract with every callback, the comparison with WOPI and ONLYOFFICE, a sample host and a doctor that checks your host against the contract ship inside the image (HOST-CONTRACT.md, INTEGRATION-30MIN.md). Images: hissih/sumdoc-webhost · hissih/sumsheet-webhost; compose files and the standalone run: github.com/SumOfficeApp/sumoffice-docker; air-gapped archives on the download page. Evaluation is free with no time limit; production is a license per embedding application — licensing.