Which editor handles our Microsoft Office files better?
Picture a team that must open, edit and return real Word, Excel and PowerPoint files from inside a self-hosted file platform, with contracts, budget models and client decks flowing both ways. The short answer is that ONLYOFFICE treats .docx, .xlsx and .pptx as its native formats, while Collabora Online is built on LibreOffice and handles Microsoft formats through that engine. Which one renders your files more faithfully depends on your document mix, so the decision must be confirmed with a sample of your own files rather than on the strength of a general claim.
Build the test set from the documents that cause pain today: templates with tracked changes, comments, complex tables, embedded charts, pivot tables in Excel, slide masters and custom fonts, and any macro-free forms your teams fill in. For each file, open it in both editors, edit it, save it, and then reopen the saved copy in desktop Microsoft Office to compare layout, pagination, formulas and chart rendering. Record which elements break in each direction, because a file that round-trips cleanly in one editor may lose formatting in the other. Ask both vendors which file types and features they consider in scope for their current versions, and confirm the answers against your own results.
Run the same test inside the file platform you actually plan to use, since the connector and the WOPI handshake can change how files are opened, locked and saved. Check the editing and saving behavior with several people working on one document, and check how conversions of legacy formats such as .doc or .xls are handled, including which version is stored after a save. Keep the results in writing, because they become your acceptance criteria and will show whether the difference between the two editors matters for your business, or whether either one is good enough for the documents you handle most often.
How each editor handles Office format parts
This table compares how Collabora Online and ONLYOFFICE Docs handle Office files, conversions, PDF editing, server licensing and paid support. Use it to decide which items to verify in your own document tests before you pick an editor. Items marked to confirm are not covered by the vendor facts we have, so ask the vendor directly.
| Area | Collabora Online | ONLYOFFICE Docs |
|---|---|---|
| Native Office formats | Built on LibreOffice technology; confirm fidelity for each .docx, .xlsx and .pptx file you use | Native handling of .docx, .xlsx and .pptx Office Open XML files |
| Underlying engine | LibreOffice technology | Confirm engine details and rendering differences with the vendor |
| OpenDocument support | Listed in scope; confirm which ODF versions and features are supported | Converts ODT, ODS and ODP files, per the DocumentServer README |
| Conversion coverage | Confirm which legacy Office and OpenDocument formats convert correctly | Converts DOC, ODT, RTF, ODS, CSV and ODP, per the DocumentServer README |
| PDF editing | Not covered by supplied facts; confirm text editing, annotations and form filling | Text editing, page manipulation, annotations and form filling |
| Server code license | Mozilla Public License 2.0 (MPL-2.0) | GNU Affero General Public License 3.0 (AGPL-3.0) for Community Edition |
| Paid support and editions | Business plan at 3 euros per user per month for up to 99 users, per the pricing page | Enterprise Edition with Basic, Plus or Premium support, per the edition comparison |
| Build for production tests | Use the supported build; CODE is described as not recommended for production | Community Edition support runs through GitHub and the forum |
Which document features decide the result
Document fidelity rarely fails on the first page. It fails on the features your organization uses every day, so the six factors below are the ones to test with your own files. Each card names a decision point, the risk it carries and what to check against both editors.
Macros and embedded objects
Macros, OLE objects and embedded charts or media often sit in legacy Office files that teams keep for years. Neither editor should be assumed to run or preserve every macro or embedded object identically, so treat this as a go or no-go test. Open a sample of macro-enabled and object-heavy files in each editor, then check that content survives a round trip back to Microsoft format and that your security team's macro policy still applies.
Tracked changes and comments
Legal, HR and regulated review workflows depend on tracked changes and comment threads surviving multiple editors and file versions. A reviewer who sees changes shifted or authors missing will stop trusting the platform. Run a document with multiple authors, nested replies and accepted or rejected revisions through both editors, and confirm the output reads correctly in desktop Microsoft Office as well.
Complex spreadsheet formulas and pivot tables
Finance and operations teams rely on array formulas, structured references, named ranges and pivot tables that refresh from source data. Calculation differences or lost pivot definitions can change reported numbers without any visible error. Compare a workbook of your own with its expected totals in both editors, and ask each vendor which function families and pivot features are covered in the version you plan to run.
Slide layouts and fonts
Presentations built from corporate templates depend on slide masters, theme fonts, custom layouts and embedded fonts. Missing fonts or substituted layouts usually show up at the last minute, in front of an audience. Check that your template's fonts are installed on every server and client, then open representative decks and compare slide-by-slide rendering against the original in desktop PowerPoint.
Form fields and PDF editing
Forms and PDFs drive approvals, contracts and public-sector submissions, so editing fields, annotations and page order must not corrupt the file. ONLYOFFICE Docs documents PDF editing with text editing, page manipulation, annotations and form filling. Collabora's PDF and form behavior is not covered by the supplied facts, so confirm it directly with Collabora against your own forms before assuming parity.
OpenDocument or Microsoft formats
The share of your archive that is OpenDocument versus Microsoft Open XML decides which editor is the more natural default. ONLYOFFICE treats docx, xlsx and pptx as native and converts formats such as DOC, ODT and ODS. Collabora is built on LibreOffice, so OpenDocument is its home format. Inventory your file types by count and age first, then weight the tests toward the formats that dominate your daily work.
Why LibreOffice lineage and native OOXML handling differ
The core difference is where each editor's file handling comes from. Collabora Online is built on LibreOffice technology, so its editing engine is the same family of code that opens and saves documents in the desktop LibreOffice suite. It reaches users through the WOPI protocol, which means your file platform hands a document to Collabora and receives it back after editing. ONLYOFFICE Docs takes a different path: its DocumentServer README names .docx, .xlsx and .pptx as its native Office Open XML formats, and it converts older or open formats such as DOC, ODT, RTF, ODS, CSV and ODP before editing. Neither architecture makes one format a guarantee for the other, so the practical question is how your own files behave in each editor.
If your team mostly receives Word, Excel and PowerPoint files from customers, vendors or regulators, start by listing the features those files actually use: tracked changes, comments, complex tables, embedded charts, custom styles, macros and fonts. Open a representative sample of each in both editors, edit them, save them back in the original format and compare the results in Microsoft Office. Because ONLYOFFICE treats OOXML as its native format, it is the natural first test for that mix, but you should confirm the outcome with your own documents rather than rely on the lineage alone.
If your team mostly stores OpenDocument files, the LibreOffice lineage is the more direct match, since ODT, ODS and ODP are the formats LibreOffice is built around. Check the reverse path as well: a file that starts in Word and is converted for storage or sharing may lose content on the round trip, so decide which format is the system of record before rollout. Confirm with Collabora which Microsoft Office features its current release supports, and record the test results so the decision can be reviewed when either editor publishes a new version.
How to test your own documents before choosing
This sequence shows how your own Office files behave in each editor before you commit. It produces a documented, signed-off record of which document types pass, which fail, and what needs remediation.
Build a representative document sample
Collect real working files from the teams that will use the editors most, such as finance, legal, operations and communications. Include a spread of .docx, .xlsx and .pptx files, plus any legacy .doc, .xls or .ppt files still in circulation, and files with embedded images, charts, macros or custom templates. Keep the originals untouched and record each file's owner, source application and version. The step is complete when the sample covers every document type your teams create and share, and the list is agreed by the business owners who will rely on the results.
Stand up test instances in your file platform
Deploy one test instance of Collabora Online and one of ONLYOFFICE Docs, each connected to a non-production copy of your file sync and share platform, so editing happens through the same integration your users will see. Use the same file platform version and the same test user accounts for both. Record the exact Collabora Online and ONLYOFFICE versions under test and confirm them against the release sources before you start, since both projects publish releases on their own schedules. The step is complete when both editors open a test file from the platform in a browser.
Open and render every sample file
Open each file in both editors and compare the first render with the original application's appearance. Check page breaks, table layouts, spreadsheet formulas and calculated values, slide transitions, speaker notes and embedded objects. Note any file that fails to open, opens with a warning, or shows a visible shift in layout. The step is complete when every file has a pass, minor difference or failure recorded for each editor, with a screenshot or description of each difference.
Test round-trip saves in each format
Edit a fixed set of changes in each file, save it back to .docx, .xlsx and .pptx, then reopen it in the original desktop application. Compare the saved result against the original for text, formatting, formulas, charts, slide layouts and object positions. Repeat for a sample of legacy formats if you still receive them, since conversion is a separate path. The step is complete when each file has a round-trip result for both editors, and any file that loses content or formatting is flagged with the specific element that changed.
Check comments, tracked changes and fonts
Create comments and tracked changes in a document, have a second user reply and resolve them, and confirm that authors, dates and change states survive a save and reopen in both editors. Check that the fonts used in your templates display correctly, including corporate or licensed fonts, and that any substitution is documented. Confirm how each editor handles fonts that are not installed on the server. The step is complete when the review workflow results and font behavior are recorded for each editor.
Test PDF forms and PDF handling
Open a sample of PDF forms and documents that your teams fill, annotate or sign, and test text editing, page changes, annotations and form field entry in each editor. Confirm that filled fields and annotations remain intact after saving and that the PDFs still open correctly in standard readers. Check whether PDF editing is available in the edition you plan to use, because feature sets differ between community and paid editions. The step is complete when each PDF in the sample has a recorded result for both editors.
Record sign-off owners and decision criteria
Before the results are reviewed, agree the decision criteria with the business owners, security reviewers and the platform team. Name who signs off for each document group, who approves exceptions and who decides on the editor. Define what counts as a blocking defect, such as lost tracked changes in a contract, and what counts as an acceptable cosmetic difference. The step is complete when the sign-off owners and criteria are written down and agreed before scoring begins.
Document results and confirm remaining gaps
Compile the results into one report that lists each document, each editor's outcome, the version under test and the sign-off decision. Include the known gaps and the mitigations you would accept, such as template changes or user guidance. Confirm with each vendor, through its documentation or support channel, any behavior you could not verify in your environment. The step is complete when the signed report is stored with the platform records and the team has an agreed decision and list of open questions.
When document fidelity should decide the choice
When most of your documents arrive from outside your organization as Office files, format handling affects how much rework follows each edit. Build your test set from the files your counterparties actually send, including the most complicated ones, and record every difference you find before you choose.
- Native Office Open XML: ONLYOFFICE Docs treats
.docx,.xlsxand.pptxas its native formats, so start there when you look for differences in layout, tracked changes and macros. - Round-trip edits: Open each file, edit it, save it, and reopen it in Microsoft Office. Check tables, numbering, comments, headers, footers and embedded objects.
- LibreOffice foundation: Collabora Online is built on LibreOffice technology, so test complex spreadsheets and templates where formula handling and rendering matter most.
- Support for format defects: If a broken file blocks a contract, ask which tier covers it. Collabora's Business plan includes a service level agreement, and ONLYOFFICE lists Basic, Plus or Premium support as Enterprise Edition features.
Ask each vendor to open your worst three files and show the saved result in Microsoft Office before you sign anything.
When your organization has settled on OpenDocument for internal records, the editor's native format becomes the main fidelity question. Collabora's LibreOffice base uses OpenDocument as its home format, which makes it the more direct fit, but you still need to confirm how each editor saves and reopens your own files.
- Native ODF editing: Confirm that documents, spreadsheets and presentations keep their structure, styles and fields through repeated saves in your chosen Collabora build.
- Conversion path in ONLYOFFICE: ONLYOFFICE lists ODT, ODS and ODP among its conversion formats, so ask whether converted files are stored as new copies, whether originals are kept, and how styles survive the round trip.
- Archival output: Check that PDF exports and any long-term retention copies match your records policy before you migrate existing archives.
- Edition effect: Once the format is fixed, support and maintenance usually matter more than the format list. Collabora's Business plan includes long term support and signed security updates, which suits a long-lived internal standard.
Ask both vendors to open a sample of your OpenDocument templates, with their macros and fields, and to confirm which build you would run for the next three years.
When staff must edit PDFs or complete fillable forms, the editor you pick has to handle PDF features directly, not only office files. ONLYOFFICE documents PDF editing as a built-in capability, so it is the clearer starting point here, but Collabora's coverage for your specific workflow needs confirmation before you rely on it.
- Documented PDF features: The ONLYOFFICE DocumentServer README lists PDF text editing, page manipulation, annotations and form filling.
- Collabora coverage: Test whether Collabora Online's office workflow meets your PDF editing needs, and do not assume the two editors offer the same PDF tools.
- Form field behavior: Test fillable forms from your own vendors, including field validation, calculated fields, dropdowns and checkboxes, and how completed forms save back to the file platform.
- Support for production forms: If forms drive payments, approvals or regulatory submissions, weigh ONLYOFFICE Enterprise support tiers against community support through GitHub and the forum.
Confirm with each vendor whether digital signing happens in the editor or in a separate service, since that decision changes the scope of your test.
When you plan to embed the editor inside a service you give to customers, licensing and support terms can decide the choice before format fidelity does. Format testing still matters, because customer files will show up in your product, but the commercial model determines whether you can ship the editor at all.
- Developer licensing: ONLYOFFICE sells a Developer Edition under a commercial license for software vendors that embed the editors in services they provide to customers.
- Community license limits: Read the AGPL-3.0 terms for the Community Edition against your delivery model, and have counsel review them before you build.
- Collabora licensing: Collabora Online's server code is under MPL-2.0. Confirm with Collabora how its paid terms apply to an embedded service.
- Published Collabora pricing: Collabora's pricing page lists the Business plan at 3 euros per user per month for up to 99 users, while the Enterprise plan for 100 or more users is quoted and includes customization services. Ask what ONLYOFFICE's Developer Edition includes for the same use.
Request written license terms and the support scope from both vendors before you commit to either editor for an embedded product.
Questions buyers ask about office format compatibility
What does format compatibility testing involve before choosing an online office editor?
It means opening, editing, saving and re-opening a representative sample of your real documents in each editor, then checking what changed. Start with the formats you use most, such as .docx, .xlsx and .pptx, and include documents with tracked changes, comments, complex tables, embedded charts, custom fonts, macros you rely on, forms and any PDF workflows. Compare the rendering in the browser against the original in desktop Microsoft Office, and record each difference with a severity rating. Both editors list native or supported formats in their documentation, but support does not guarantee fidelity for every file, so the sample has to come from your own estate. Confirm each vendor's current format list before you start.
Can our internal team run office format tests on its own?
Usually yes, if someone can build a test corpus, run the editors in a staging environment and score the results consistently. The work is mostly sorting documents, defining pass and fail criteria and repeating the checks after each editor update. An internal team does need access to desktop Microsoft Office for reference renders and enough time to review differences in layout and formulas, which is often the hard part. If your team lacks that time or independent judgment, an outside partner can run the same protocol under a written scope. DeployOpen plans and runs this kind of testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts.
What drives the cost of office format testing up or down?
The main drivers are the number of documents, the number of formats, how complex the files are and how many integrations you must test. A corpus of a few hundred simple letters costs less to assess than thousands of spreadsheets with macros, linked data and pivot tables. Each additional platform, such as Nextcloud, ownCloud or Seafile, adds a round of WOPI integration checks. Access to reference software, the number of reviewers and the depth of sign-off all add effort. Ask the provider to split the quote by corpus preparation, test execution, integration work and written reporting, so you can see which lever reduces cost.
What should a quote for office format testing include?
A useful quote lists the scope in writing: the editors and versions under test, the document corpus size and formats, the integrations and the test environment. It should name the deliverables, such as a defect register, a severity-rated comparison report and a go or no-go recommendation, and state what is out of scope. Ask whether the fee is fixed, how changes to scope are priced, who performs the testing, and what the timeline depends on. Also confirm whether licensing, hosting or support costs for the editors appear separately, because those are paid to the vendors, not to the testing provider. DeployOpen does not publish a price list, so a quote follows from the written scope.
How long does office format compatibility testing take?
The duration depends on the scope, mainly the corpus size, the number of formats, the number of editors and integrations, and how many review rounds your stakeholders need. A narrow test of one editor against a small set of templates is much shorter than a multi-editor evaluation covering every department's documents. No fixed duration applies to all environments, so ask any provider for a timeline tied to the agreed scope and a list of the dependencies that could move it, such as access to test accounts, reference installs and reviewer availability. Build a buffer for a second round of fixes if an editor version changes during the evaluation.
Is switching from one online office editor to the other expensive later?
The cost depends on how much your organization has built around the editor. Documents themselves are standard Office Open XML or OpenDocument files, so the content can usually be kept, but layout, macros, custom templates, plugins, integration settings and user habits need retesting. Both editors connect to file platforms through their integrations, so you will need to repeat the integration work and the format sample after any change. Keep the original files in their native format, document the configuration, and test a migration on a copy before cutting over. Confirm with each vendor which features and file types are supported in the version you plan to run.
Which licensing terms affect how we can run the editors in our environment?
The licensing terms define what you can deploy, modify and distribute, so check them before testing. Collabora Online's source is under MPL-2.0, while the free CODE edition is described by Collabora as not recommended for production. ONLYOFFICE Docs Community Edition is AGPL-3.0, and its Enterprise Edition adds features such as an admin panel, white labeling and paid support tiers. Testing a build you plan to run in production can also reveal whether you need a paid tier for support or for features you depend on. Have your legal and compliance teams confirm the terms that apply to your specific use.
Can a partner help us prepare evidence for compliance reviews about document handling?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For office format testing, that can mean documenting the test method, the corpus, the results and the configuration used, so an internal or external assessor can review them. Whether a given evidence set satisfies a particular framework depends on that framework and your auditor, so confirm the requirements with them before you define the deliverables.
What the paid editions add beyond file fidelity
The paid editions change what surrounds the editor, not how it reads a file. The core engines do not change between editions: a Microsoft Office document that opens with formatting problems in a Community build will open with the same problems in a paid build, so fidelity testing belongs in the Community or evaluation setup you plan to run. Paid tiers are bought for operations, support and licensing terms, and that is where the two vendors differ.
ONLYOFFICE's edition comparison lists an admin panel, white labeling and Basic, Plus or Premium support as Enterprise Edition features, with Community support handled through GitHub and the forum and configuration done through config files only. If your operators need a graphical admin view or branded editing screens for internal users, price the Enterprise Edition against that need. If your team already manages configuration as code, the Community configuration model may be sufficient, but confirm that your support expectations can be met through community channels.
Collabora's paid model is different. Its pricing page lists a Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Ask each vendor in writing which support hours, response targets and patch channels apply to your user count, and confirm current terms before budgeting, because both vendors may revise their plans.
How DeployOpen helps teams test and implement
DeployOpen plans, implements and tests self-hosted open-source platforms inside your own infrastructure, including Collabora Online and ONLYOFFICE Docs next to your file platform. We help you build a test set from your own Microsoft Office documents so the editor choice rests on your files, not on a generic feature list.
How we scope
- Scope is agreed in writing before work starts, covering which editors, file platform and document types are in the test.
- We list the document families that matter to you, such as templates, macros-free spreadsheets, tracked changes and embedded objects.
- Engagements are fixed-scope, with deliverables and timelines confirmed in the written scope; ongoing support is available as a retainer.
How we build
- We build a test environment in your own cloud account, data center or air-gapped network with both editors connected to your file platform.
- Test documents are opened, edited, saved and re-opened in each editor, with results recorded per format and per feature.
- Where a gap appears, we document the workaround, the affected users and the fallback format agreed with your business owners.
How we hand over
- You receive the test results, the document inventory and the configuration used for each editor in writing.
- Installation, integration, hardening and backup procedures are documented so your own team can repeat the tests later.
- We walk your administrators through the chosen setup, including upgrade steps for the editor version you deploy.
How we support
- Ask whether a retainer covers re-running the document test set when a new editor release is published.
- Confirm with us which upgrades, security testing and documentation updates the retainer includes before signing.
- Plan a repeat test after any change to your file platform, fonts, templates or Office versions your users rely on.
