How Collabora Online PDF handling fits your document workflow
Teams that work with PDFs usually want to open them in the browser next to their Word, Excel and PowerPoint files, and some also need to export or convert PDFs for archiving or accessibility. In Collabora Online, PDF handling is part of the document editor, but the editor does not decide who may reach a file. That decision sits with the WOPI host, such as Nextcloud, which controls who can open, view or edit each document and passes that permission to Collabora Online when the session starts. Before you roll out PDF access, decide which user groups may open PDFs at all, and which of them may do anything beyond viewing.
The Collabora Online product page lists PDF among the formats it supports, but a listed format does not tell you how a given host will treat it. Some hosts, including Nextcloud, let administrators limit which groups can use the editor and which groups can edit rather than only view. Other WOPI integrations may apply their own rules to PDFs, so confirm the behavior with the host vendor and in your own environment rather than assuming it matches the Nextcloud setup. The Collabora Mattermost plugin documentation, for example, states that PDF files can only be viewed and not edited in that integration.
Plan a short test with your own PDFs before users depend on the workflow. Open a representative set of files from each group that will use them, check view and edit permissions for each role, and confirm that the export or conversion options you expect to offer are available in your deployment. Record which results depend on the host configuration and which depend on the Collabora Online version you run, since the release you choose will affect both. Use these results to write the access policy that the host enforces, and document it alongside your other document handling rules.
Why viewing a PDF is not the same as editing one
PDF handling is a permission question as much as a format question. When a user opens a PDF in Collabora Online, the file may be shown in a viewer while the editing controls stay unavailable, and that outcome depends on what the WOPI host allows, not only on what the editor can technically read. Before rollout, separate two decisions: whether users can open PDFs at all, and whether they can change them. Some integrations treat PDF as a view-only type, and others expose the same editor for every supported file. Your choice affects user expectations, support tickets and which documents end up being re-created in Word or another tool.
A useful example is the Collabora Mattermost plugin, which states that files such as PDF, JPG and SVG can only be viewed and not edited. That limit is set by the integration, so it is not a statement about the Collabora Online server itself. Your own WOPI host may behave differently, and it may allow editing for some extensions and not others. Ask your platform vendor or integrator to list, for each file type you care about, whether the host offers view only, edit, or both, and whether that rule can be changed by administrators. Record the answer alongside your test results.
Treat this as a configuration check you run in a staging environment with real accounts. Create one user from each group that matters to you, upload representative PDFs, and confirm what each role can do from the browser. Also check what a user can download or export, since a view-only session may still allow a copy. The results should go into the same fidelity log you use for Office formats, so that PDF permissions and document behavior are reviewed together before go-live.
Which PDF options to decide before rollout
This table lists the PDF decisions that shape a Collabora Online rollout, with the purpose of each, who usually makes it and what to confirm before go-live. Read each row as a question to settle in writing, since several answers depend on the release and configuration you run.
| Decision | Purpose | Who usually decides | What to confirm |
|---|---|---|---|
| View only or edit | Sets whether users can change PDFs opened in the editor or only read them. The Mattermost plugin notes that PDF, JPG and SVG files can only be viewed and not edited, so host behavior may differ by integration. | Records or compliance owner with the document platform team | Whether your WOPI host opens PDFs in view mode, and which edit permissions your host applies per user or group |
| Tagged PDF output required | Decides whether exported PDFs must carry structure tags so screen readers and automated checks can read reading order and headings. | Accessibility lead with legal or procurement | Whether the release you run exports tagged PDFs, and which Writer and Impress documents need tagging checked |
| PDF/UA export needed for accessibility review | Decides whether exported files must meet the PDF/UA standard for accessibility review, which is a stricter target than tagging alone. | Accessibility lead, with the review body or auditor | Whether PDF/UA export is available in your target release and how the output is validated with an independent checker |
| PDF as a conversion target for Writer or Impress | Decides whether users may save or export Writer or Impress output as PDF, and whether that output becomes an archival or distribution copy. | Document owner and records team | Export formats allowed per template, and whether the original editable file must be kept alongside each PDF |
| Who may export | Limits which users or groups can create PDF copies, since an exported file can leave the controlled storage. | Security team and data owner | How your WOPI host restricts download and export actions by group, and whether export is logged |
| Fidelity testing for PDF output | Sets how exported PDFs are checked against the source, including fonts, layout and embedded content, before users rely on them. | Document platform team with a representative user group | Test corpus, sign-off criteria and the release used for each test, recorded in the release notes or with Collabora |
Which WOPI host settings decide who can open PDFs
Whether a user can open a PDF in Collabora Online depends as much on the WOPI host as on the editor itself. The host decides which requests reach Collabora, which Collabora URL it trusts, and which users may open or edit files. Check these controls before rollout, then repeat the check for each host you connect.
Restrict WOPI requests to Collabora IPs
The Nextcloud administration manual recommends limiting WOPI requests to the IP addresses of your Collabora servers. This keeps requests from arbitrary sources away from the WOPI endpoint that serves document content. For PDFs, confirm that the allow list covers every Collabora node, including nodes added later by a load balancer or autoscaling group, so that a new node does not silently fail to load files. Test with a PDF after each change.
Match the Collabora URL protocol
The Nextcloud manual advises using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. A mismatch can block the editor frame or produce mixed content warnings, and PDFs may appear to fail to open even when the file itself is fine. Check the configured URL, the protocol of the host, and the certificate chain your browsers trust. Confirm the same rule in the documentation of any other WOPI host you use.
Limit which groups can use the editor
In Nextcloud Office, administrators can restrict the editor to selected groups. Users outside those groups may still see the file listed, but they will not get the Collabora view for PDFs. Decide whether PDF viewing should follow the same group policy as document editing, and confirm that group membership is synced from your identity provider before you rely on it.
Limit which groups can edit
Nextcloud Office also lets you separate view-only access from edit access by group. PDFs are read-only in Collabora Online, so the practical question is whether the same users should be able to annotate or change related Office files. Review the group rules for each host, because a user who can edit Word files in one tool may still be read-only for PDFs in another.
Check other WOPI hosts separately
The controls above come from the Nextcloud manual and do not apply in the same form to every platform. Some hosts expose allow lists, group rules or protocol settings under different names, and some do not expose them at all. Read the documentation for each host, record the setting that governs PDF access, and test with a PDF from each user group.
How to set up and check PDF handling in a test environment
This sequence builds a disposable Collabora Online test environment, connects it to a test WOPI host, and locks down that connection. It then checks how PDF files open, view, export and convert for view-only and edit users, producing a logged record of permitted PDF actions for each group before any rollout decision.
Install a test Collabora Online server
Install the free CODE edition as a test server, typically from the collabora/code Docker image, which is published for x86-64, ppc64 and arm64. Collabora describes CODE as suited to testing, home use and small teams, but not recommended for production, so keep this server outside your production path and match the version family you plan to deploy. Confirm that the container starts, that its web address resolves from the test WOPI host's network, and that the server responds. The check is a reachable server with its exact version recorded in your test log.
Connect a test WOPI host
Connect a disposable WOPI host to the test server. Nextcloud is a common choice, so install a test Nextcloud instance with the Nextcloud Office app, then enter the Collabora server URL in the app settings. Use test accounts and no production data. The check is that a sample DOCX file opens in the editor from the host. If the editor does not load, record the error message before changing anything, because every later step depends on a working connection.
Restrict WOPI access and enable HTTPS
Apply the controls the Nextcloud administration manual recommends. Limit WOPI requests to the IP addresses of the Collabora servers, and use the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Set these on the test host and on the test server's proxy or firewall, using your own certificate and network tooling. Then confirm that the editor still opens over HTTPS. Also try a machine outside the allowed addresses, where the editor should not load. If it does, the restriction is not working. Record both results.
Assign view-only and edit test groups
Create two test groups on the host, one for viewing and one for editing, and add a test user to each. In Nextcloud Office, administrators can choose which groups can use the editor and which groups can edit, in addition to those that can only view. Include both test groups in editor access, and grant edit rights only to the edit group. The check is that the view-only user opens a sample PDF with no editing controls available, while the edit user's session allows changes. Log each user's result separately.
Load a representative PDF corpus
Build a small corpus of PDFs that reflects the documents your teams actually handle. Include text-based files, scanned pages without a text layer, forms with fields, files with embedded fonts, a large multi-page file, a file with bookmarks or tags if you have one, and a password-protected file. Store the corpus on the test host in a location both test groups can reach. Record each file's name, size, page count and origin in your log. The check is that every file is listed with its origin before any open test begins, so each result traces to one specific file.
Check opening, viewing and exporting
Open each corpus file as both test users and record whether it opens, whether it renders correctly, and whether the view-only user can make changes. Then export a native document to PDF from the editor and compare the output with the original in a separate PDF reader. For tagged PDF and PDF/UA output, confirm the exact options and results for your Collabora Online version with Collabora before relying on them, using the release notes. If your host is Mattermost, expect PDF files to be view only. The check is a completed results table covering both groups.
Test PDF conversion results
Where your workflow needs PDF as a conversion target, convert supported source files through the editor's export path and log whether layout, fonts, links and images survive. Repeat the same test after any server version change, so you can see what changed. Compare the results across both groups and against the originals. The check is a signed-off list of allowed and blocked PDF actions for each group, reviewed by the people who own your document policy, which shows which workflows can go to production.
Testing tagged PDF and PDF/UA output by role
Document owners know what a finished document should look like, so they judge whether PDFs exported from Collabora Online still read correctly. Give them a representative set of files from your own templates, such as contracts, reports, forms and slide-based handouts, and ask them to export each one and compare the result with the original. Their work is about visible content, not about the internal structure of the file.
- Layout: Record page breaks, table column widths, headers and footers, image placement and any text that wraps or overlaps.
- Text: Check that characters, ligatures, special symbols and right-to-left or non-Latin text appear as expected, and that fonts are embedded rather than substituted.
- Links and fields: Note whether internal links, bookmarks, page numbers and table of contents entries still work in the exported file.
- Comments and tracked changes: Record what happens to open review markup, since PDF export may show, hide or drop it depending on settings.
- Blocking failures: Treat missing text, wrong page count, broken tables or unreadable fonts in a document that must be delivered as a PDF as go-live blockers.
Record each issue with the file name, the page, the Collabora Online version and the export settings used, so the same case can be retested after a fix or upgrade.
Accessibility and compliance leads check whether the exported PDF carries the tagging that assistive technology relies on. Tagged PDF and PDF/UA output must be validated with the validator your organization has chosen and accepts for its own policy. DeployOpen does not supply validation results, and the outcome of any validator run must come from the tool you select and the version you record.
- Validator choice: Decide in advance which PDF/UA validator and version will be used, and record its name, version and rule set in the test log.
- Structure: Check reading order, heading levels, lists, tables with header cells, alternative text for images and language metadata against the validator's output.
- Source documents: Test the same files with and without the tagging options you intend to use, so you can tell whether a failure starts in the source document or in the export.
- Screen reader pass: Have a tester read exported files with a screen reader to confirm that the validator's findings match what a user actually hears.
- Blocking failures: Set the rule for go-live before testing begins, such as which validator findings must be cleared, and record any accepted exceptions with a named owner.
Keep the validator report, the settings and the sign-off together so an auditor can trace each claim back to a test run.
IT operators test how PDF files move through the WOPI host and Collabora Online, and what the host allows users to do with them. The Collabora Mattermost plugin documentation notes that files such as PDF, JPG and SVG can only be viewed and not edited, so the host integration decides which PDF actions are available. Confirm these behaviors in your own host and version rather than assuming they match another integration.
- Permissions: Test view-only and edit roles separately, and confirm that users without edit rights cannot change or save a PDF through the editor. In Nextcloud Office, administrators can limit which groups can use the editor and which can edit.
- WOPI allow list: Confirm that requests for PDF files come only from approved WOPI hosts and that the allow list is applied to every host that will open these files.
- Logs: Check that opens, exports and failed conversions are logged with user, file and time, and that logs can be retained for the period your policy requires.
- Downloads and sharing: Verify whether exported PDFs can be shared or downloaded under the same controls as the source file.
- Blocking failures: Treat a permission bypass, a missing audit trail or an allow list gap for PDF requests as a go-live blocker.
Finish by checking that the test evidence from the other two roles is stored where operators can reproduce each run after an upgrade.
Patching Collabora Online to keep PDF handling secure
PDF parsing is part of the Collabora Online server's attack surface, so patching is a PDF control in its own right. When a user opens a PDF in the browser, the server side of the stack parses and converts the file, and a flaw in that code can be exploited by a crafted document uploaded to a file store that your WOPI host connects to. Collabora publishes security advisories for Collabora Online, and the 25.04 release notes give a concrete example: release 25.04.7.5, dated January 29, 2026, fixed CVE-2026-23623 and updated the package signing keys for RPM and DEB users. Treat that as the pattern to plan for, not a one-off. Each advisory should be mapped to the branch you run, the release that fixes it and the date you apply it.
Start by making advisories and key changes reach a named owner. Subscribe to Collabora's release notes and forum announcements, and record which branch each Collabora Online server runs, including any CODE installs that are not on a supported subscription. Before you install any point release, verify the package signature against the signing key Collabora publishes, and check that key rotations in the release notes are reflected in your package manager configuration. A key change that you accept without checking is a supply chain gap, and a key change that breaks installs without warning is an operational one. Confirm with Collabora which key fingerprints and repositories apply to your distribution before the first update window.
Plan point-release updates on a fixed cadence and test them against your own PDF samples before production. The Business plan on the Collabora pricing page includes signed security updates, long term support and a service level agreement, so ask whether those terms cover the specific branches and distributions you run and what response times apply, since those terms are contractual rather than something this page can state. Include the upgrade cost in your planning: the time for a patch window, regression checks on PDF viewing and export, and a rollback path for each server. Where your team cannot absorb that work, a DeployOpen retainer can carry the advisory watch, testing and patch execution, with the scope written down before work starts.
Limits to confirm for PDF files in your environment
PDF behavior in Collabora Online depends on the version you run, the files you open and the host that starts the session. The items below are the checks that connect those factors, and each one should be confirmed against your own branch and a representative test corpus rather than assumed from this page.
Feature survival on export and round trip
Confirm which PDF features survive the path from source document to PDF export and back. Annotations, form fields, bookmarks, embedded fonts, hyperlinks and layered objects can change when a file is edited and re-exported. Build a corpus of your own PDFs and compare each item before and after a save. Record which losses are acceptable for your workflow and which block go-live.
Tagged PDF and PDF/UA output
Check whether the tagged PDF and PDF/UA output produced by your version meets the accessibility standard your organization must follow. Ask the vendor which export options apply and then validate the output with an independent PDF accessibility checker. Tag structure, reading order, alternative text and language settings are the usual points of failure, so test them on documents that carry real structure.
Where view-only limits are enforced
Determine whether a view-only restriction is applied by the WOPI host, by the editor or by both. A host that grants read-only access and an editor that ignores the flag can produce different results in different integrations. Test download, print, copy and export paths separately for each host you connect, and confirm the behavior with the host's documentation and your own test accounts.
File size and page count
Measure how large PDFs and high page counts affect load time, memory use and conversion time on the server size you plan to run. Scanned pages, large embedded images and long documents tend to dominate resource use. Set a maximum file size and page count for your test corpus, then compare results against the per-pod resource recommendations in the Helm chart before you choose replica counts.
PDF behavior in your chosen branch
Confirm that the branch you plan to run supports the PDF behavior your workflow needs, because export options, accessibility output and rendering fixes change between releases. Review the release notes for your branch and its point releases, and check the security advisories that affect it. Plan a repeat of your corpus test whenever you upgrade or move between branches.
Conversion targets and format handling
When PDF is a conversion target, confirm how source formats map to PDF output in your environment, including fonts, page layout and embedded graphics. Check whether the conversion path your integration triggers produces the same output as a direct export. Document any differences so users know which files to review manually before sharing.
Questions buyers ask about PDFs in Collabora Online
Can our own team set up PDF handling in Collabora Online, or do we need a partner?
Your own team can do it if it has someone who runs the Collabora Online server, the WOPI hosts and the reverse proxy, plus time to test PDFs against your own files. Most of the PDF work is verification, because viewing and export behavior depend on your documents and on each host. A partner adds the most value when you need a written test plan, a sign-off record that your compliance or accessibility owner can review, and someone who keeps the setup current across point releases. Ask for the scope in writing before work starts, so the split between your staff and the partner is clear.
What drives the effort of PDF work in Collabora Online?
The main drivers are the number of PDF types you must cover, the accessibility requirements attached to exported files, the number of WOPI hosts that open PDFs, and the permission model that decides who can view, edit or export. A set of plain text reports is quick to check. Scanned forms, tagged PDFs from design tools, and files with embedded fonts or form fields take longer, because each needs its own result. Every additional WOPI host multiplies the checks, since each host can set its own limits. Ask any provider to break its quote down by these drivers so you can see where the time goes and which items you can reduce.
How long does a PDF test cycle take in Collabora Online?
The length of a PDF test cycle depends on the size and variety of your document corpus, the number of hosts, and how many issues your reviewers must triage and retest. No duration is given here. Plan the cycle around three steps: build a representative set of files, run each file through viewing, editing where allowed, and export, then log the results and retest any fixes. Ask providers for a timeline tied to your corpus size and your sign-off steps, and confirm which reviewers must be available during the cycle.
What must our team provide for PDF testing and rollout?
Your team should provide a representative set of sample PDFs drawn from the documents your organization exchanges, and note which ones contain scans, forms, signatures, embedded fonts or tagged structure. You also need a group design that states who may view PDFs, who may edit them in each host, and who may export them. Add the accessibility requirements that exported files must meet, and name a reviewer who can judge fidelity along with a person who approves go-live. Confirm where each host stores its permission settings, because that determines where the rules must be applied.
Do Business or Enterprise plans change PDF support in Collabora Online?
Confirm this with Collabora before you decide, because plan terms can change and the researched material does not tie PDF features to a plan. According to the Collabora 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, for 100 or more users, is quoted with volume discounts and adds integration support, customization services and roadmap input. Ask whether any PDF-specific fix or service depends on your tier, and whether your plan changes how quickly you receive security advisories.
What happens to PDF handling after go-live?
After go-live, PDF behavior can change with each release, so someone must watch Collabora's release notes and security advisories and retest PDFs when your version changes. Collabora publishes advisories. For example, the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Set up a recurring step to review advisories, rerun your sample set against new point releases, and record the results. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and you should ask any provider which tasks it covers and which stay with your team.
Can we stop users from editing PDFs in a WOPI host?
In many setups you can limit editing, but the control sits in each host, so you must check every one. Nextcloud lets administrators limit which groups can use the editor and which groups can edit, as opposed to only view. The Collabora Mattermost plugin notes that PDF, JPG and SVG files can only be viewed, with editing unavailable. Other hosts may behave differently, so open a PDF in each one with a test user from each group. Record what the user sees, and confirm the behavior with the host vendor and the Collabora release you run.
Does Collabora Online export tagged PDF and PDF/UA files?
Confirm this for your specific version and settings before you rely on it in an audit, because the researched material here does not settle export behavior for every release. Tagged PDF and PDF/UA export are the two areas to check, and they matter most where documents must be usable by people with assistive technology. Build a small test set with headings, lists, tables, alternative text and reading order, export it from Collabora Online, and check the output with a PDF accessibility checker and a screen reader. Keep the results with the version and settings you used. They are evidence for your own review, not a certification.
How DeployOpen works on this
DeployOpen plans, implements, tests, documents and supports Collabora Online inside your own infrastructure. For PDF handling, we start from the document types your teams actually open, export and convert, then build and verify the behavior your policy requires before anything reaches users.
How we scope
- Inventory which PDF workflows matter: viewing, exporting, converting to PDF and sharing from each WOPI host.
- Confirm whether tagged PDF or PDF/UA output is a requirement, and who owns that decision.
- Agree the written scope, deliverables and timeline in writing before work starts, as engagements are fixed-scope.
How we build
- Configure export and conversion settings in Collabora Online to match the agreed PDF policy.
- Set WOPI host permissions so PDF files are viewed only where editing is not intended.
- Test representative PDFs for viewing, export and accessibility tagging, and record the results against the agreed criteria.
How we hand over
- Document the PDF settings, host behavior and test results so your team can repeat the checks.
- Walk through known limits, such as PDF files that a host can only view, with the people who answer user questions.
- Provide a runbook for re-running the test set after each Collabora Online upgrade.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Re-run the PDF test set when Collabora Online branches or WOPI host versions change.
- Ask your compliance or accessibility assessor to review the evidence; DeployOpen prepares it but does not issue certifications.
