SumOffice and WPS
WPS is a large, mature office suite with its own editors, its own query and macro tooling, an SDK and an AI assistant. If you are choosing a suite for staff, it is a serious answer. This page is for a different reader: the one deciding whose engine goes inside their product. There the question is not whose feature list is longer — it is where the engine runs, who controls the file, and what the licence counts.
Rule for this page: about WPS we link to what WPS publishes about itself, and we do not describe their internals. About ourselves we link to the measurement. Where nothing has been compared, we say so instead of implying a win.
What WPS publishes about itself
- A full office suite for documents, spreadsheets and presentations, free and paid tiers — wps.com.
- WPS 365, a productivity platform for companies — wps.com/business.
- WebOffice open platform — online preview and editing, format conversion and API integration for other products — solution.wps.cn.
- An open platform for developers — open.wps.cn.
Macro compatibility, a query tool and an assistant are part of that offering. We are not going to argue with any of it, and a product maker should read their pages as carefully as ours.
Where we are actually different
| The engine inside your product | Four shapes, one engine: a library in your code (Python, Node.js, .NET, Java), the local editor in your own window, mobile SDKs, and server images in your infrastructure. Your storage, your authorization, your domain. |
|---|---|
| What the licence counts | One annual licence per embedding application — not per seat, not per document, not per click; self-hosted and white-label (licensing). Your own pricing does not have to follow your customer’s headcount. |
| Control over the file | A macro runs on a copy and the changes are shown before they are applied; external objects are named and refused before anything touches the document; vbaProject.bin returns byte for byte. |
| What an agent gets | MCP: the structure of the real file, the sources of the macros, the steps of the queries — not a flattened text dump. In this version the agent reads and plans; it does not run. |
| Where it all happens | On your machines. No account, no external cloud, no document telemetry. |
Architecture: office as a capability, not as an application
SQLite did not ask you to launch a database server. FFmpeg did not ask you to open a video editor. WebKit did not ask you to start a browser. Each of them turned a heavy application into a capability you call from your own code — and the products built on top stopped looking like someone else’s software with your logo on it.
Office is the last of those to make the move. The surface belongs to your product. The computing capability belongs to the engine. That is the whole architectural idea behind SumOffice, and it is what the two pictures below differ about.
What we claim, and what each claim rests on
| The engine is the library | The native cores ship inside the packages on PyPI, npm, nuget.org and Maven Central and are called from your code — no office application is launched, and none has to be installed. Measured 03.10.2026 on clean Linux, macOS (including macOS 15) and Windows machines. |
|---|---|
| No identity layer, no cloud of ours | No login, no AppKey, no service to register with: 30 documents a day are free, and beyond that you drop in a key file that works offline. |
| A pinned version | The package number is the core number: 2026.4.3 of the library is 2026.4.3 of the engine. Nothing updates underneath you. |
| You pick the process boundary | In-process library, a helper process over stdio, or a container — the same engine in all three. The boundary is an architectural decision, and it stays yours. |
| Mobile SDKs run on the device | The native core sits in your app: no network and no service of ours is required. Acceptance on Android and iOS, 03.10.2026. |
What the libraries do not do, so that nobody plans a sprint around it: they keep macros and Power Query inside the file, they do not run or refresh them. Running a macro on a copy belongs to the editor; MCP reads and plans. For an agent the library scenario is “file → operation → result” for formulas, recalculation, text and slides.
What WPS publishes about its own architecture
Quoted from their documentation, read on 3 October 2026. Where their pages do not say something, we write “we did not find it published” — not “they do not have it”.
| A callback service is required | Integration has three parts: create a WebOffice application, implement a callback service on your server, and embed the front-end SDK — principle overview. The gateway “needs a public domain name or IP so that the WebOffice service can reach it” — integration flow. |
|---|---|
| One process per document, up to 200 people | “A single document process supports at most 200 people editing online at the same time”; “each document corresponds to a process inside the system”, and that process “uses the kernel library to process the document” — principle overview. |
| An application identity | A created application carries an AppID and AppSecret, and the AppID is passed into the document initialisation call; a production application additionally needs a purchased package and a review — integration flow. |
| Their strength, plainly | The document API “follows the VBA style and is in principle compatible with VBA interfaces and parameters” — integration flow. If you are migrating an integration that already drives Application.Run, Workbooks and Range, that breadth is a real advantage, and we do not have an equivalent object model. |
We did not find published pages for several things that are sometimes said about WPS — among them a library that runs without launching the office application, and the rules for a native document component on mobile. We leave them out rather than guess.
Where we are not ahead
- Breadth of the suite. WPS ships a complete end-user product family with years of polish. We are an engine first, and our own apps are younger.
- Reach. Their installed base and platform coverage are larger than ours. That is a fact, not a detail.
- Feature parity in the editors. Our own capabilities page lists what is supported and what is still missing, per feature, generated from the engine’s own audit — read it before you assume parity in either direction.
- Delivery maturity. Not every delivery shape is equally far along: the status table shows what each way of delivering the engine does today.
The run on the same files
A like-for-like run of the two engines on the same files — rendering, a macro corpus, timing — is being arranged, and when it is done the numbers will be published here, including the ones that do not flatter us. Until then, treat any “X is better” on this page as absent: we did not write it.
If you want to run the comparison yourself, both engines are available to try: open a real file in ours, no install and no account, and take your own corpus through it.
Who should pick which
| You are equipping staff with an office suite | A mature end-user suite — theirs or another — is a reasonable choice, and we will not pretend otherwise. |
|---|---|
| You are putting document editing inside your own product | That is what we are built for: four ways to embed, one licence per application, and control over what happens to the file. |
| You must keep every file on your own infrastructure | Both the server images and the libraries run entirely on your machines; nothing goes to us. |
Corrections welcome, including from WPS: if something here is out of date or wrong, write to hello@sumoffice.com and we will fix the page.