Collabora Online DOCX compatibility with Microsoft Word

How well does Collabora Online DOCX compatibility hold up for Word users?

Collabora Online can open, edit and save DOCX files, but how faithfully a given Word document survives the trip depends on the features that document uses. The Collabora Online product page lists docx among the Microsoft formats it supports, and the editor is built on LibreOffice technology, so the question for your organization is not whether DOCX editing works but which of your documents, in which features, need to be checked before users depend on them. Simple letters and memos usually behave predictably. Documents built on complex layouts, custom styles, field codes, tracked changes, comments and embedded objects deserve a closer look. Plan to treat the answer as a per-template decision rather than a single yes or no for the whole file store.

You need this check at three points. The first is before rollout, when you decide which templates and document families can be opened in the browser and which should stay in desktop Word for now. The second is during a migration from another editor or from a file share, when files are moved into a WOPI host and users will expect pages to look the same afterward. The third is when external partners, customers or suppliers send DOCX files that your team will need to edit. Those files come from sources you do not control, so they are the most likely to contain features you have not tested. Ask your implementation partner or internal team to build a representative sample of real templates, including the most complicated ones, before any go-live decision.

Run the test on the exact Collabora Online version you plan to deploy, because fixes to DOCX handling land in release branches over time. Confirm the current branch and its point release with Collabora, and record it in your test log so the results can be repeated after an upgrade. Compare each sample in Word and in the browser editor, noting layout shifts, lost or altered tracked changes, comment anchoring, fields that no longer update and style inheritance problems. Those observations, together with the fidelity test plan described elsewhere on this page, give you a defensible go-live list rather than an assumption.

Which Word features need checking first

Word documents carry formatting that a browser editor must rebuild on every open, save and round trip. The six areas below are where differences from desktop Word most often surface, so a test plan should cover each one with files from your own templates. Treat each card as a test case with a pass condition, not a general warning.

Page layout and pagination

Check page size, margins, headers and footers, section breaks, columns and keep-with-next rules against the original in desktop Word. Pagination is the first place readers notice drift, because a table that breaks one row earlier can push a signature block onto a new page. Open each template, make a small edit near a page break, and compare page counts before and after saving. Record which documents shift and whether the shift affects legal or regulated text.

Tracked changes

Confirm that insertions, deletions, formatting changes and the author and date metadata survive opening, editing and saving in both directions. Test accept and reject on a document with nested or overlapping revisions, since these are where editors most often disagree. Check that a reviewer working in Collabora Online sees the same revision markup that a Word user sees, and that changes made in the browser are attributed to the correct user.

Comments and review threads

Verify that comment anchors stay attached to the right text after edits, that replies keep their threading, and that resolved comments remain marked as resolved. Test comments placed on tables, text boxes, footnotes and across paragraph boundaries. Comments are often the first thing a reviewer loses when a document moves between Word and a browser editor, so include a document with a long comment thread in your corpus.

Fields and cross-references

Test table of contents, page number fields, cross-references to headings and captions, bookmarks, and mail-merge style fields. Check whether fields update on open, on save or only when a user triggers them, and whether the displayed result matches what Word shows. Pay attention to numbered captions and heading-based cross-references, which often display stale numbers after an edit until the field is refreshed.

Styles and templates

Compare paragraph, character and table styles, theme fonts, list numbering and the inheritance chain from your organization's corporate template. Confirm that a document created from a template in the browser inherits the same styles as one created in Word, and that custom styles are not renamed or flattened on save. Font substitution is a frequent cause of changed line breaks, so confirm which fonts are installed on the Collabora Online server and which are embedded in your templates.

Embedded objects

Test images, shapes, charts, equations, embedded spreadsheets and OLE objects. Check whether each object is preserved as the same type, whether it stays editable, and whether its position is anchored to the same paragraph after saving. Equations and charts built in Word are the most common source of visible differences, so record each object type in your corpus and mark it as preserved, changed or lost before go-live decisions are made.

How the editing and saving path works

Collabora Online is a browser editor, not a document store. When a user opens a DOCX from a WOPI host such as Nextcloud, the host keeps the file, decides who may open or edit it, and holds the version history, while Collabora Online imports the file into its LibreOffice-based engine, lets the user edit it, and writes the result back through the WOPI interface. Before rollout, confirm which party owns each control in your setup: storage and retention sit with the host, while the import filters, layout engine and save routine sit with the editor. A fidelity problem you see in the browser therefore usually traces back to the editor's import or export, not to the host, so your test plan should be run against the editor version you intend to deploy.

Every save is a round trip. Collabora Online reads the Word file into its internal model and writes a new DOCX, so the saved file is not a byte-for-byte copy of the original even when no one changed the content. Styles, numbering, fields, section breaks, embedded objects and revision marks can be rewritten in equivalent but different XML. Treat the first save of each representative template as a test event: keep the original, save it through the editor, then compare the two files in Word and in a text or XML diff, and record what moved. Also check that the host's version history captures the saved file so a regression can be rolled back.

Collabora Online's server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), so you can inspect and modify it under those terms. Collabora publishes release notes for each branch that list fixes, including fixes to document import and export. Before you pick a branch or schedule an update, read the notes for that branch and check whether any entries touch Word formats, tracked changes, fields or styles that your templates use. Confirm the exact point release you will run with Collabora, since a fix that matters to you may land only in a later point release on your branch.

Which Collabora Online release branch to test against

The free CODE edition is the quickest way to run your Word templates against a current build. Collabora describes it as suited to testing, home use or small teams, and it is not recommended for production. Use CODE to find layout, tracked change and field problems early, but treat its results as a preview of your production behavior, not as proof of it. The CODE page sets out the intended use.

Release cadence: CODE is released on average once a month as a rolling release, so the build you test on can change between runs. Record the exact version and build date with every result.
Production status: Because Collabora does not recommend CODE for production, a DOCX fix confirmed here does not establish what a supported production server will do.
Small team evaluation: A small team can use CODE to build and run its document corpus, then repeat the same corpus on the branch it will operate.
Support scope: Confirm with Collabora what support, if any, applies to CODE before anyone relies on it for a business decision.

Before you start, check that your test log names the CODE build for each run so a later comparison uses the same build.

How to test your own Word templates before go-live

This sequence turns your own Word templates and client documents into a recorded fidelity baseline, shows how each file changes after a Collabora Online round trip, and ends with a severity-ranked list that tells you which differences block go-live. Use it for the templates your organization depends on, not for a generic sample.

Build a corpus from your own templates
Collect the Word templates, letterheads, contracts, reports and client documents that your teams open every week, and copy them into a fixed test folder. Remove personal or client data where needed, keep the originals untouched, and record each file's source, author, Word version and the features it uses, such as tracked changes, comments, fields, content controls, headers and footers, and custom styles. Done when every file has a row in a simple inventory and the set includes the documents that carry the most risk, not only the easiest ones. For a broader corpus method, see the testing document fidelity topic.
Record the Microsoft Word baseline
Open each file in Microsoft Word on the desktop client your organization uses, and capture what it looks like: page count, pagination, fonts, tables, images, tracked changes and comment balloons, field results such as page numbers and cross-references, and any content that depends on the document settings. Save screenshots or PDF exports as the reference for later comparison. Done when every file has a baseline record that a second reviewer has checked against the screenshots, so the comparison is not based on one person's memory.
Open and save each file in Collabora Online
Upload the same files to a test instance of Collabora Online that matches your production version and configuration, then open each one through your WOPI host, such as Nextcloud, and save it back as DOCX. Keep the version number, fonts installed on the server and the editing permissions the same as production so the result reflects what users will see. Confirm the file opens, saves and downloads without errors, and log any warning the editor or host shows. Done when every round-trip file has a saved DOCX and a note of the Collabora Online version used.
Compare layout, tracked changes, comments and fields
Open each round-tripped file in Word and compare it with the baseline, checking page breaks, line breaks in tables, fonts and spacing, images and anchored objects, headers and footers, and list numbering. Then check tracked changes and comments for author names, dates, resolved status and placement, and check fields such as table of contents, page numbers, cross-references, and mail merge fields after updating them in Word. Done when each file has a completed comparison sheet with a note for every difference, including differences that look cosmetic.
Log each difference with a severity
Record every difference in a single issue list with the file name, page or location, the element affected, the baseline behavior, the Collabora Online behavior and a severity such as blocking, workaround available or cosmetic. Attach a screenshot or the saved file to each entry so a developer or template owner can reproduce it. Done when the list covers every difference found, each entry has an owner and a severity, and the same list can be filtered by template to show where the risk is concentrated.
Decide which differences block go-live
Hold a short review with the template owners, a representative from legal or records management where documents carry obligations, and the team that will support users. Agree which severities block go-live, which need a documented workaround or template change, and which can be accepted with user guidance. Then retest the blocking items after fixes and rerun the affected files through the full round trip. Done when every blocking item is closed or formally accepted with a named owner, and the decision is written down with the Collabora Online version it applies to.
Confirm the test covers each Collabora Online upgrade
Because Collabora Online releases change how documents are rendered, rerun the corpus after each planned upgrade of the server and compare the results with the last approved baseline. Confirm the vendor's current release notes for any DOCX fixes that relate to your findings, and check whether a fix affects templates you already accepted. Done when the test corpus, the baseline, the decision record and the upgrade checklist are stored together, so the next upgrade starts from the same evidence.

Which DOCX handling choice fits each team

This table compares the main ways to handle Word files in Collabora Online, from keeping DOCX as the default save format to routing high-risk templates to desktop Word. Read each row as a policy choice: the first column names the option, and the other columns show when it fits, what it costs you, and what to check in your own environment before committing.

Option	When it fits	Trade-off	What to confirm
Keep DOCX as the saved format for all users	Teams that exchange files mainly with Word users and need the least change in habits	Round-tripped layout and tracked changes can drift on complex documents, so reviewers must check files after editing	Your template set passes round-trip tests in Collabora Online and Word
Allow ODF for new documents	Teams that control their own files and have no external Word dependency for new work	Recipients still using Word may need conversion, and existing DOCX files stay in their original format	The Nextcloud setting that controls the default format and how your partners open ODF files
Restrict editing to specific groups	Organizations where only trained editors should change contracts, policies or regulated documents	Other users can view but not edit, which can slow review cycles and needs a clear request process	Which groups Nextcloud Office can limit to editing and how those groups map to your directory
Route high-risk templates to Word on the desktop	Documents with heavy fields, complex numbering, legal layouts or macros that your test corpus shows are unstable	Users switch tools for some files, and the desktop workflow sits outside the browser audit trail	Which templates fail your tests and whether your Word licensing and desktop access cover those users
Keep originals in DOCX and edit a converted copy	Teams that need an editable working copy but must preserve the source file for records	Two versions can diverge, and conversion steps add review effort	Your retention rules and who owns the decision to publish the converted copy
Enable editing for all authenticated users	Small teams with low risk documents and a trusted user base	Little control over who changes shared templates, so accidental edits to standard text are more likely	Whether template folders can be made read-only for most users

Security and patching for document editing

Collabora Online sits between your users, your WOPI host and your document store, so each control below narrows who can reach the editor and keeps its code current. The four items cover request restriction, transport, vulnerability response and package trust, and each one needs an owner and a check in your environment.

Restrict WOPI requests by IP

The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of your Collabora servers. Confirm that the WOPI host only accepts requests from the Collabora nodes you run, and that any load balancer or proxy in front of Collabora forwards the address your host actually sees. Test the allow list after every change to network addresses, because a stale entry can break editing for every user at once. Record which addresses are permitted and who approves changes to them.

Use HTTPS for the server URL

The Nextcloud administration manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Mismatched schemes produce protocol errors that users often work around by weakening settings, so align both URLs before go-live. Check that certificates are valid for the exact hostname the WOPI host uses, and that internal certificate authorities are trusted by both sides. Document the URL pair in your change record.

Track Collabora security advisories

Collabora publishes security advisories for Collabora Online. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Subscribe to release notes for the branch you run, map each advisory to your installed build, and schedule point releases within your change window. Tie the test plan in this topic to each update so a document that renders correctly before patching is checked again after it.

Keep package signing keys current

Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users. If your installs rely on pinned keys, a missed rotation can block updates or push teams toward disabling signature checks. Confirm which key your package manager trusts, import the updated key through your normal change process, and verify package signatures during each upgrade. Keep the key source and the verification step in your runbook so the next rotation is routine.

Questions teams ask before testing DOCX fidelity

What drives the cost or effort of a DOCX fidelity test?

The main driver is how much of your document estate the test has to cover, and how much human review each document needs. Effort rises with the number of templates, the complexity of each one (tracked changes, comments, fields, cross-references, content controls, custom styles), and the number of rendering and editing paths you check, such as Collabora Online against Microsoft Word on desktop and in the browser. Cost components are the people who build the corpus, run the round trips, log and triage issues, and decide what blocks go-live. If you outsource part of the work, ask the provider for a quote built from a written scope that lists the documents, the test environments and the deliverables. Confirm the environment details with your own team, since these vary by deployment.

How long does a DOCX test cycle take for a given corpus size?

Duration scales with corpus size and with how many documents need manual comparison, so the number of documents is the first thing to fix. A small set of representative templates can be checked in a short cycle, while a large archive with varied authors takes longer because each document may need several round trips and a human check of layout. We do not have a supplied figure for a typical duration, so do not plan against a number from this page. Ask any provider for a timeline tied to the agreed corpus, the number of test rounds and the review capacity on your side, and confirm the schedule against your own release calendar.

What does our team need to provide for the test?

You need to supply the documents that matter to your business, access to people who know what correct output looks like, and a working copy of Microsoft Word for the reference rendering. In practice this means:

Representative templates, such as letters, contracts, policies and forms, with their real styles and fields
Sample documents with tracked changes, comments and any content controls your users rely on
Named reviewers from the teams that own those documents, who can judge whether a change is acceptable
Access to Microsoft Word versions your staff actually use, so the reference is accurate

Ask the provider to list these inputs in the written scope before work starts.

Can our internal team run the DOCX fidelity test alone?

Yes, a team with document expertise and a test environment can run a basic round-trip test without outside help. The work is methodical: build a representative corpus, open and save each file in Collabora Online, compare the result with Word, log each difference and agree which differences block go-live. The harder parts are judging layout changes that look minor but affect legal or regulatory text, and keeping the test repeatable across Collabora Online updates. Your team needs time from people who understand the documents, and it needs someone to own the issue log. If those resources are not available, a fixed-scope engagement with DeployOpen can cover the test design and execution in writing before work starts.

What licensing applies to Collabora Online if we roll it out to many users?

Licensing depends on the number of users and the plan you choose. According to the Collabora Online pricing page, the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan applies to 100 or more users and is quoted with volume discounts, and it adds integration support, customization services and roadmap input. The server code is licensed under MPL-2.0, and the free CODE edition is described by Collabora as not recommended for production. Confirm the current terms directly with Collabora before you budget, because pricing pages change.

Does the licensing choice affect how we test and support fidelity?

It can. The Business and Enterprise plans include support, security updates and long term support, which matter when you have to keep a fidelity baseline stable across patches. The free CODE edition is a rolling release that Collabora describes as suited to testing and small teams, so a fidelity baseline built on it may need repeating after each update. If you test on CODE first and move to a supported plan for production, plan to repeat the round trips on the production build. Ask Collabora which release line and support terms apply to your user count before fixing the test plan.

Which Collabora Online version should we test against?

Test against the exact release line and build you intend to deploy, because formatting behavior can change between releases. Collabora publishes branch-level release notes, and the 25.04 branch was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. Record the version used in every test run, and repeat the corpus when you upgrade. Confirm the current supported branch with Collabora before you choose a baseline.

How DeployOpen scopes DOCX compatibility work

DeployOpen treats DOCX fidelity as a measurable part of a Collabora Online deployment, not a yes or no question. We work from your own Word templates and documents, agree what must match Word exactly and what can change, and record the results in a written scope before any work starts.

How we scope

The written scope lists the Word templates, document types and features in your corpus, such as tracked changes, comments, fields and styles.
Each feature is marked as must match, acceptable with a documented change, or out of scope for the browser editor.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ask for the scope to name which Collabora Online and Nextcloud versions the testing covers.

How we build

We assemble a representative DOCX corpus from your real templates, with owners who can confirm the expected layout.
Round-trip tests run in Collabora Online and in Microsoft Word, with differences logged against each document and feature.
Where fidelity gaps affect your templates, we test template changes and server settings before recommending them.
Results are reproducible, so the same corpus can be rerun after a Collabora Online upgrade.

How we hand over

You receive the corpus, test scripts, issue log and a go or no-go list tied to the agreed must-match features.
The documentation records known differences, workarounds and the owner who accepts each residual risk.
We document the retest procedure so your team can repeat the checks after each Collabora Online release.
Handover is agreed in the written scope, including what your team needs to run the tests independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so DOCX checks can run with each Collabora Online point release.
Retainer scope covers rerunning the corpus when Collabora publishes fixes that touch document handling.
Security advisories from Collabora are reviewed against your corpus before rollout to production.
Ask for the retainer scope in writing, including how new templates and features are added to the test set.