Choose the right page and document editing workflow
“Edit a PDF” can mean changing pages, modifying PDF text content, or preparing a transformed output file. Web SDK, Document Engine, DWS Viewer API, and DWS Processor API support different parts of those workflows. Choose based on the operation and where the document should be processed and stored.
The same editing goal across products
| Setup | How editing works | When to use it |
|---|---|---|
| Web SDK with the required licensed features | Web SDK edits the document in the browser. The available document/page editing and PDF content-editing features depend on the license and operational mode. Your app owns document delivery and saving the exported result. | Use this when users need browser-based editing and your app controls the document and its persistence. Check that your license and mode support each required operation. |
| Web SDK + Document Engine | Web SDK can edit in the browser and, through a supported persistence workflow, save changes to a Document Engine document. Separately, Document Engine Build API processes input and returns output; your application must store or deliver that output unless it uses a separate API/workflow to update a Document Engine document. Build API transformations don’t provide PDF text-content editing. | Use this when you need Document Engine-backed viewer persistence through a supported workflow, or server-side page/document transformations. |
| DWS Viewer API with DWS-managed documents | Web SDK can make viewer changes supported in DWS Viewer mode, and DWS Viewer API persists those supported changes to managed documents. This doesn’t imply support for every Web SDK editing feature or operation. | Use this when you need supported viewer changes on DWS-managed documents. Verify that the specific feature and operational mode are supported. |
| DWS Processor API | The Build API processes inputs and returns an output PDF. It can combine files, select/reorder pages, rotate pages, and apply other supported actions in one request. It’s a processing workflow rather than a persistent interactive viewer session. | Use this for backend or batch transformations when your application handles the input and returned output files. |
How to choose the right editing setup
Use Web SDK standalone when a user edits pages or PDF content in the browser and your application saves or replaces the document afterward. Editing capabilities depend on the licensed features and operational mode; verify that the required operation is supported.
Use Web SDK + Document Engine when you need Document Engine persistence through a supported viewer workflow. Also use it when your backend needs to transform a document using Build API. Build API processes the input and returns output. Your application must store or deliver that output unless it separately uses a workflow/API that updates a Document Engine document. Choose the browser content editor for text-content edits; Document Engine Build instructions don’t edit PDF text content.
Use DWS Viewer API with DWS-managed documents when users need supported viewer changes on a managed document. The application still decides access and permissions, while DWS manages the uploaded document and persists supported changes. This doesn’t mean every Web SDK editing feature or operation is supported in DWS Viewer mode, so verify the specific feature and mode.
Use DWS Processor API when the application needs a discrete processing job. Submit input documents and instructions, and then receive the transformed output. Use it for automation or batch work rather than interactive viewer editing.
Common points of confusion
- Page manipulation and content editing are different — Reordering, rotating, adding, or removing pages changes document structure. Editing text within a page changes PDF content and has a different API and support path.
- Interactive editing and document processing are different workflows — Web SDK presents a viewer/editor session. Document Engine and DWS Processor API can also run server-side transformations. DWS Processor returns a processed file rather than maintaining an interactive session.
- Saving is part of the workflow — Standalone Web SDK returns edited output for your app to save. DWS Viewer API persists supported viewer changes to DWS-managed documents. Document Engine persists changes made through supported document-update workflows. Your application must store or deliver Build API output unless a separate workflow/API updates a Document Engine document. DWS Processor API returns output that your app must store or deliver.
- Not every operation is available in every mode — Check the product documentation for the exact edit type, license, and operational mode before designing the workflow.
- Document Engine’s Build API doesn’t edit PDF text content — Use Web SDK content editing for that task, with an appropriate persistence workflow.
Typical decision questions
- Are users editing interactively, or is the operation an automated processing job?
- Are you changing page structure, PDF text content, annotations, or some combination?
- Where should the edited document be stored: your application, Document Engine, or DWS-managed storage?
- Do users need to review changes in a viewer before they’re saved or returned?
- Does the selected product and operational mode support each required operation?
Guides by product
- Web SDK
- Document Engine
- DWS Viewer API
- DWS Processor API