Mia Perese
Published July 15, 2026
Updated July 15, 2026
4 min
WebViewer 12.0: Key Changes, New Features, and How to Upgrade
Mia Perese
Summary: WebViewer 12.0 Is a Major Version Release
WebViewer 12.0 retires the legacy UI and standardizes on the current UI as the single supported way to customize the viewer, drops several deprecated APIs, and adds a set of viewer and form improvements. If your integration doesn’t touch the legacy UI or any removed API, upgrading is a version bump. If you forked or built on the legacy UI, the migration guide covers the move.
What Changed in WebViewer 12.0?
The legacy UI no longer ships with WebViewer 12.0. There is now one UI, one customization model, and one path forward, which also means a smaller download and less code running in the browser. The release also drops several deprecated APIs, adds a set of viewer and form improvements, and tightens the recommended content security policy (CSP).
Why did WebViewer 12.0 remove the legacy UI?
Carrying two UIs meant two ways to customize the viewer, two sets of behavior to document, and extra code in every bundle whether you used it or not. WebViewer 12.0 settles on the current UI and its modular component model as the single supported path. For developers, that is one clear way to build, fewer surprises when you customize, and a lighter package to ship.
Which APIs were removed in WebViewer 12.0?
Removed API | What to Use Instead |
|---|---|
instance.UI.enableHighContrastMode() and instance.UI.disableHighContrastMode() | No longer needed. The current UI ships as a WCAG 2.2 Level AA interface, so high-contrast support is built in. |
Tool.ENABLE_TEXT_SELECTION, Tool.disableTextSelection, and Tool.enableTextSelection | Text selection now applies per tool rather than statically, for more precise control. |
Direct tool prototype assignment | Replaced with dedicated tool APIs that define how customization is done and reduces the chance of regressions. |
documentViewer.enableReadOnlyMode and documentViewer.disableReadOnlyMode | Use enable/disableViewOnlyMode which replaces the older read-only toggle with clearer view-only state handling. |
The legacy APIs for modifying viewer headers are also gone. Search your codebase for the calls above before upgrading. The full list, with replacements, can be found in the migration guide.
How do I migrate from the legacy UI?
Whether you need to migrate depends on what you built on. If your integration does not use the legacy UI, there is nothing to migrate. If you forked it or built on top of it, the migration guide covers how to move each customization to the current UI’s components.
Teams that relied on the legacy UI’s tool toggle, the control for switching between tool groups, can rebuild that layout in the current UI. WebViewer 12.0 adds a toolgroup toggle button built from modular components, so you can reproduce the familiar arrangement without the legacy code behind it.
What’s new in WebViewer 12.0 for developers?
WebViewer 12.0 adds an API for setting the status options in the comments panel. Until now, changing that list meant forking the viewer UI; it is now a configuration call. The API lands in WebViewer first, with the same pattern planned for other SDK modes.
A new autosave API commits comment and notes-panel edits as users make them. Saved content is written in full rather than held as a draft, and it works with undo and redo, so a reviewer’s work is retained even if they never press save. That is most useful in review and approval workflows, where a lost comment means someone has to recreate their efforts.
Annotations can now be searched and sorted by their assigned number. In a document with a few hundred comments, that number is how a reviewer points at a specific one, which is the practical difference between describing a comment and naming it.
Date fields are now part of the form builder. WebViewer could already read and write a date field that existed in a form; however, it could not create one via the UI. In 12.0, the form builder allows adding date fields directly, so building a form with a date picker no longer requires writing custom field code.
Rounding out the release: multitab and multiviewer modes now work together, appearance support extends to text and checkbox widgets, RTL support extends to XOD files, and XFDF stamp data now fully conforms to the XFDF specification.
How do I upgrade to WebViewer 12.0?
Integrations not using the legacy UI or removed APIs can upgrade without code changes. Everything else is covered step-by-step in the migration guide.
More from this release
WebViewer 12.0 is part of the summer Web SDK release. The same release adds programmatic tracked changes to DOCX Editor through the new TrackedChangeManager API, and XLS and CSV support with chart interactions to Spreadsheet Editor. For the full set of changes, see the DOCX Editor tracked changes blog and the Spreadsheet Editor blog, along with the WebViewer 12.0 release notes.
