Choose the right search, bookmarks, and document navigation setup
Search, bookmarks, and document navigation can look similar in Nutrient Web SDK, Document Engine, and DWS Viewer API, but the ownership of search behavior and navigation state changes depending on the setup and document source.
The same navigation goal in each setup
| Setup | How search, bookmarks, and navigation work | When to use it |
|---|---|---|
| Web SDK with a license key | Web SDK handles search and document navigation in the browser. Your app owns document delivery and any persistence strategy for navigation-related state on top of the file. | Use this when your app opens documents directly in Web SDK and you want browser-side search and navigation. |
| Web SDK + Document Engine | Web SDK provides the UI, while Document Engine can back document search on the server and persist server-managed document state. | Use this when you need self-hosted search at scale, server-backed state, or multiuser continuity. |
| DWS Viewer API with DWS-managed documents | Web SDK provides search and navigation UI for DWS-managed documents, and DWS Viewer API can answer managed-document search requests on the backend. | Use this when you want managed document viewing and search without running your own Document Engine. |
| DWS Viewer API with app-provided documents | The document is provided directly to Web SDK, so search and navigation behave more like standalone Web SDK than DWS-managed workflows. | Use this when your app provides the document directly and only uses DWS Viewer API for session authorization. |
How to choose the right setup
Use Web SDK with a license key when search and document navigation happen primarily in the browser and your app already owns the document and any related persistence flow.
Use Web SDK + Document Engine when you need server-backed document search, better large-document search performance, or server-managed continuity for supported document state.
Use DWS Viewer API with DWS-managed documents when you want Nutrient to manage the backend search and viewing layer for uploaded documents.
Use DWS Viewer API with app-provided documents when your app provides the document directly and you only need DWS Viewer API session authorization, not DWS-managed document storage.
Common points of confusion
- Search UI and search backend are different concerns — The Web SDK search experience may look similar across setups, but the backend path differs between standalone, Document Engine-backed, and DWS-managed documents.
- Bookmarks and outlines aren’t identical — Nutrient distinguishes between bookmarks laid on top of a document and the document outline structure inside the file.
- Document outline editing is more limited than bookmark workflows — In Web SDK, creating, editing, and removing document outlines is a standalone browser workflow, not a general server-backed workflow.
- App-provided DWS documents are different from DWS-managed documents — If your app passes the file directly to Web SDK, treat search and navigation more like a Web SDK workflow first.
- Large-document search may need backend help — For very large files, Document Engine’s full-text search path or DWS-managed document search can be more relevant than browser-only assumptions.
Typical decision questions
Ask these questions before choosing a search or navigation setup:
- Should search run only in the browser, or do you need a server-backed search path?
- Will users work with very large documents where search latency matters?
- Do you need existing PDF outline navigation, app-level bookmarks, or both?
- Is the document stored and managed by your app, Document Engine, or DWS?
- If you’re using DWS Viewer API, is the document DWS-managed or app-provided?
Equivalent guides by product
- Web SDK
- Document Engine
- DWS Viewer API