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.
Route inspection
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.
Try the merge routeLocal input
Files are read by the browser from your device.
Tab runtime
Supported operations execute in the current session.
No queue
No upload pipeline is used for core local tools.
Local output
The result is exported as a browser download.
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
| Vector | Cloud tools | DocuStitch |
|---|---|---|
| Document route | Upload to processing queue | Browser session for supported tools |
| Latency source | Upload, queue, download | Local CPU and browser memory |
| Privacy basis | Retention policy and vendor trust | Reduced document transfer |
| User check | Hard to verify after upload | Inspect network activity during processing |
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.