Processing model
Know where your PDF is processed before you start.
DocuStitch labels the processing route before you select a file. For supported tools, the browser handles the document work in the current session instead of sending every file to a remote processing queue.
Before a file moves, the route should be obvious
DocuStitch separates browser-side tools from workflows that would require server infrastructure. Core tools are designed around file-picker access, in-tab processing, and local downloads.
The four steps
Local referencing. When you select files, the browser gives the page temporary access to those files for the current session.
Browser runtime. Supported operations use browser-side libraries and WebAssembly where appropriate, so routine PDF work can run without a remote queue.
Browser sandbox. The workflow stays inside normal browser security boundaries. Files are not available to the page unless you choose them.
Local download. The output is prepared in the browser and offered as a download. Large or complex files can still take time on slower devices.
Cloud vs. local
Document route. Cloud tools upload to a processing queue. DocuStitch keeps supported workflows in the browser session.
Latency source. Cloud workflows depend on upload, queue, and download. Local workflows depend on CPU and browser memory.
Privacy basis. Cloud tools rely on retention policy and vendor trust. Local workflows reduce document transfer.
User check. After an upload, verification is harder. During local processing, you can inspect network activity in the browser.
The result
The product should make document handling understandable. When a workflow stays local, we say so. When a workflow needs different infrastructure, it should be labeled separately.