Testing Office Online integration

Before starting the Launch process, you should do the following testing on your integration.

WOPI validator tests

All of the automated tests in the following categories must be passing in the WOPI validator:

  • HostFrameIntegration (ValidLanguagePlaceholderValues may be skipped if the host is not using the UI_LLCC or DC_LLCC placeholder values)
  • BaseWopiViewing
  • CheckFileInfoSchema
  • EditFlows
  • Locks
  • AccessTokens
  • PutRelativeFile or PutRelativeFileUnsupported
  • RenameFileIfCreateChildFileIsNotSupported or RenameFileIfCreateChildFileIsSupported (applicable only if the host supports RenameFile)
  • FileVersion
  • PutUserInfo (applicable only if the host supports PutUserInfo)
  • ProofKeys (applicable only for hosts implementing proof key validation)


Hosts are not required to support RenameFile, PutRelativeFile or use proof key validation. However, hosts that do support these operations, or use application features that rely on them, those test groups must be passing.

For example, binary file conversion requires the PutRelativeFile operation be implemented, so hosts that support conversion must also pass the PutRelativeFile tests.

Manual WOPI implementation verification

The WOPI Validation application is a very useful tool in testing your WOPI implementation. However, it cannot find all potential problems in your implementation. Check the following items in addition to the results from the validator.


You should do this testing only after the WOPI Validation application tests are passing.

Non-empty response body

Most WOPI operations do not return a response body. You should not return a response body unless the operation specifically requires it. For example, successful PutFile responses should not have a body.

Office Online feature verification

Many Office Online features rely on a host’s WOPI implementation. You should test the following features to help ensure your WOPI implementation is correct and that the Office Online integration is well-executed.


Co-authoring support is a major boon to users, but it is also used to verify your implementation of file IDs and lock-related WOPI operations. For this reason, multi-user co-authoring must be testable using the test accounts provided.


The Office Online applications each have unique behavior with respect to co-authoring. Thus it is critical to test co-authoring in all three applications.

To check that co-authoring behaves as expected, you’ll need at least two different user accounts. Then, follow these steps:

  1. As User A, share a document with User B.
  2. Open the document in edit mode as User A.
  3. Open that same document in edit mode as User B.
  4. Check that both instances of the Office Online application are participating in the co-authoring session.
  5. Make edits to the document as both users and ensure that both instances of the application remain connected to the co-authoring session.
  6. After making some edits, leave the session and verify that the saved file contains the edits made by both User A and User B.

Common issues

  1. If the users remain in different sessions (i.e. co-authoring does not occur) then it likely means your WOPI file IDs are not consistent. See file ID for more information.
  2. If one of the users is ‘kicked out’ of the session while editing, then it likely means that you’re rejecting lock-related requests that come from a different user than the one who originally took the lock. WOPI locks are not user-owned. See Lock for more information.

Single-user co-authoring

While the typical co-authoring scenario is two or more users collaborating on a single document in real-time, the feature also provides other benefits as outlined in Benefits from co-authoring support.

To check that single-user co-authoring behaves as expected:

  1. Open a document in edit mode.
  2. Open a document in edit mode using the same user account originally used, but in a different browser.
  3. Check that both instances of the Office Online application are participating in the co-authoring session.

Downloaded files should have most recent document changes

If you are providing a DownloadUrl, you should ensure that a file downloaded using the Office Online Download a Copy buttons contain the most recent edits. To test this:

  1. Open a document in edit mode.
  2. Make an edit to the document and wait for the Saved to <HostName> text to display.
  3. Click the File ‣ Save As ‣ Download a Copy button.
  4. Check that the downloaded file has the most recent edits you made to the document.

Download a Copy should not re-direct

As describe in DownloadUrl, Office Online expects that when directing users to the DownloadUrl, the file will be immediately downloaded. This URL should not direct the user to some separate UI to download the file.


If you support renaming documents within Office Online (i.e. SupportsRename is true), you should check that the rename operation behaves as expected. To test this:

  1. Open a document in edit mode.
  2. Click on the document name in the top title bar.
  3. Rename the document.
  4. Exit the Office Online application and check that the file was renamed.

If you are displaying the document name in the browser window/tab using the HTML title tag, you should check that the document name is updated after the file is renamed. If it is not, check that you are properly handling the File_Rename PostMessage.

Save As in Excel Online

Excel Online supports saving an open document as a new copy of that document using the File ‣ Save As ‣ Save As button. This feature uses the PutRelativeFile WOPI operation. You should test that this feature works as expected.

UI integration

Ensure you follow the UI guidelines as well as the terms of the Cloud Storage Partner Program contract.