See a document first. Integrate second. Edit third.

Real SumDoc editor, in your browser, no install and no sign-up — a demo cabin opens one of our real-world 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

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.

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 view-SDK is those same bits — the engine and the page from the store builds of SumDoc 2026.3.34 and SumSheet 2026.3.33 — packaged as a drop-in for your app, released together with each store build under the same version number.

SumDoc (.docx / .docm):

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

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

SumSheet (.xlsx / .xlsm):

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

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

• 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. 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.