This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/document-engine/forms/choose-the-right-forms-workflow-setup.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Choose the right forms workflow setup

Choose the right forms workflow setup

Markdown version of this page, suitable for AI agents and automation

Forms can look similar in Nutrient Web SDK, Document Engine, and DWS Viewer API, but the persistence model and ownership of form state change depending on the setup and document source.

The same goal in each setup

SetupHow forms workWhen to use it
Web SDK with a license keyUsers can fill and edit PDF forms in the browser, but persistence is local or app-managed unless you add your own backend flow.Use this when you need standalone browser form filling or when your app already owns form data persistence.
Web SDK + Document EngineWeb SDK fills and edits forms, while Document Engine persists form state on your backend and can synchronize shared state.Use this when you need self-hosted server-backed forms, multiuser workflows, permissions, or controlled storage.
DWS Viewer API with DWS-managed documentsWeb SDK form changes are persisted by DWS Viewer API for managed documents.Use this when you want managed server-backed form workflows without running Document Engine yourself.
DWS Viewer API with app-provided documentsDWS Viewer API authorizes the viewer session, but your app still owns the document source and form persistence model.Use this when your app provides the file directly and doesn’t need DWS to store or manage form state.

How to choose the right forms setup

Use Web SDK with a license key when form filling happens in the browser and your app will save, export, or submit that form data itself.

Use Web SDK + Document Engine when you need self-hosted form persistence, shared state across users or sessions, permissions, or server-side import and export workflows.

Use DWS Viewer API with DWS-managed documents when you want Nutrient to manage the backend persistence layer for Web SDK form workflows.

Use DWS Viewer API with app-provided documents when your app provides the document directly and only needs DWS Viewer API session authorization, not DWS-managed form storage.

Common points of confusion

  • Form widgets are part of the PDF, but form values still need a persistence strategy — In standalone Web SDK, your app still decides how filled values are saved or restored.
  • DWS Viewer API isn’t a separate forms UI — It powers Web SDK sessions and persistence for DWS-based web workflows.
  • Document Engine is the self-hosted forms backend — It gives you server-backed persistence, permissions, and API-level control in your own infrastructure.
  • App-provided DWS documents are different from DWS-managed documents — DWS Viewer API can authorize the session, but your app still owns the document source and form data storage decisions.
  • Filling forms, exporting data, and flattening forms are different concerns — Saving editable form values for later use is different from exporting data or permanently flattening the filled result into the PDF.

Typical decision questions

Ask these questions before choosing a forms implementation:

  1. Should filled form values persist automatically on a server?
  2. Will multiple users or sessions need to continue working on the same form state?
  3. Do you want a self-hosted backend or a managed service?
  4. Does your app need to extract, import, or submit form data separately from the PDF?
  5. Is your app already the source of truth for the document and its form data?

Equivalent guides by product