Nutrient Web SDK can be used in three common ways. The viewer API in your frontend is similar across these options, but authorization, document storage, and licensing differ. If you’re comparing licensed Web SDK with DWS Viewer API specifically, refer to the Web SDK vs. DWS Viewer API guide.
Web SDK with a license key
Use this path when your app owns document delivery and authorization. Web SDK loads documents directly in the browser using document and a Web SDK licenseKey.
This path works well when:
Your app already controls document access.
Documents should render directly in the browser.
You want fixed Web SDK licensing instead of DWS Viewer API usage-based viewer sessions.
You need browser-only operation without DWS authorization.
Web SDK with DWS Viewer API
Use this path when you want DWS Viewer API to authorize and meter viewer sessions. Your backend creates DWS Viewer API session tokens, and Web SDK loads with session.
DWS Viewer API supports two document sources:
DWS-managed documents uploaded to and stored by DWS.
App-provided documents with session and document.
For app-provided documents, omit licenseKey. The DWS Viewer API session authorizes the load. Backendless public API key support is planned separately; today, your backend creates the session.
Web SDK with self-hosted Document Engine
Use this path when you want to run Document Engine in your own infrastructure. Document Engine handles server-side storage, rendering, synchronization, and advanced processing, while Web SDK provides the browser UI.
This path works well when you:
Need to operate the backend yourself.
Want server-side document rendering and processing.
Need built-in annotation and form synchronization.
Need Document Engine features such as OCR and Instant collaboration.