Where the Document Lives Changes the Product
In Stirling PDF, the choice between a browser interface, a desktop application, and a self-hosted server is not merely a choice of packaging. It changes who owns workbench state, where a backend is reached, and which operational responsibilities remain visible to the user or administrator. This chapter compares those arrangements so that a reader can choose a mode for a real document workflow without mistaking a local-looking interface for an entirely local execution path.
The most useful comparison is not “web versus desktop.” It is a four-part question: where is the document held while a person works on it, where does the transformation run, where does the result go, and who has to maintain the boundary? Stirling PDF's repository describes all three arrangements, but it also supplies enough implementation detail to show why they behave differently.
A browser is a workbench, not a complete deployment definition
A browser is the most obvious place to confuse interface and execution. Stirling PDF's React editor has a local workbench backed by IndexedDB. It can save a file and its metadata, generate a thumbnail, load the file again, report storage statistics, mark a file as processed, and remove one or many stored files. It also keeps a bounded in-memory cache so that recently used files do not have to be reconstructed from browser storage on every interaction.
That design gives the editor a useful kind of continuity. A person can select a document, inspect it, process it, and return to the result without treating every intermediate action as a new upload from scratch. The workbench can also preserve the relationship between an input and a same-format processed version. For a user, this feels like one coherent editing surface rather than a sequence of disconnected requests.
The storage location, however, does not determine the processing location. The shared operation layer filters selected files for compatibility, checks whether a backend is ready, and then chooses among several execution patterns. A single-file operation may make separate calls for each input. A multi-file operation may submit several files to one endpoint. A custom operation may take over the request logic itself. In each case, the editor receives results and writes them into its own file context.
That means a browser-based Stirling PDF workflow has at least two seams. One seam is between the browser and its local workbench. The other is between the workbench and whatever processor the operation uses. Some client-side rendering or manipulation is part of the documented frontend architecture, but the shared operation path explicitly supports backend calls. A local copy in IndexedDB is therefore evidence about state ownership, not proof that the bytes never leave the browser.
This distinction becomes important for a sensitive document. Suppose a user opens an invoice and sees it listed among locally stored files. Before treating the workflow as offline, they still need to know which endpoint handles OCR, conversion, or compression. The interface may be local while the transformation is performed by a backend on the same machine, by a separate server, or by a service route selected by the particular build. The browser has not answered the execution question by itself.
Desktop packaging moves the seam
Stirling PDF also packages the editor as a Tauri desktop application. The repository describes a desktop build that prepares the backend JAR and creates a custom Java runtime through JLink before producing a platform-specific application. This changes the user's operational experience in a meaningful way: the backend can be carried with the desktop package instead of being treated as a separately installed service.
Packaging the backend and runtime reduces one class of friction. A user does not need to assemble a browser frontend, a Java installation, and a separately managed local server before opening the application. The desktop package can present a single product boundary, and the editor can preserve local file associations and local paths as part of the desktop experience.
But packaging is not the same as removing dependencies. The developer guide lists optional tools such as LibreOffice, Tesseract, WeasyPrint, and qpdf for particular features. A bundled Java runtime can make the application itself more self-contained while a conversion or OCR operation still depends on language data or an external engine. The desktop mode changes where the core application is installed; it does not guarantee that every provider required by every tool is inside the package.
It also changes maintenance rather than eliminating it. A packaged runtime must be built, updated, and distributed. The operator or user still has to know which version is installed, which optional features are present, and whether an update changes the available processing path. If a desktop workflow is used for a single person's private documents, that responsibility may be acceptable because state and execution can remain close to the person using the application. If many people need the same tools and policy, reproducing and maintaining the same desktop arrangement across machines may be less coherent than centralizing it.
The desktop choice is therefore about the location of the seam. In a browser-only arrangement, the seam between interface and backend is visible as a network or local-service relationship. In a desktop package, that seam may be hidden inside the application, but it still exists conceptually. The document passes from the workbench to an operation implementation, and the implementation still has a runtime, dependencies, temporary state, and an update lifecycle.
Self-hosting centralizes the service boundary
The self-hosted arrangement makes the server explicit. Stirling PDF describes itself as deployable on a user's own servers with a private API, and its development documentation separates the frontend, Spring Boot backend, and processing engine into services that can be run independently during development. The documented container arrangements likewise distinguish a frontend entry point from a backend API, making the service boundary visible during deployment.
This arrangement is especially useful when documents move through a shared workflow. A server can provide one place to configure the available providers, set resource policies, expose API endpoints, and apply an organization's access and update practices. It also gives automation a stable service boundary: a script or another application can call the private API rather than depending on a particular person's desktop state.
Centralization brings its own ownership questions. The server administrator becomes responsible for the runtime, logs, configuration, network exposure, and the external tools that enable particular operations. The repository's Docker examples show that different images encode different feature and resource choices. An ultra-lite image disables additional features and uses a smaller example memory limit; standard and fat variants include broader capability assumptions and larger example limits. These values are configuration examples, not universal limits, but they illustrate the trade-off: the server owner chooses a bundle, and that choice affects what a client can request.
A self-hosted API also does not automatically mean that every document is stored durably on the server. The frontend can use a local workbench, while a particular operation sends a file to a backend and returns a result that is saved back into the workbench. A different server-side storage feature can retain files for shared access. Execution and persistence are related decisions, but they are not one decision. A self-hosted deployment gives an organization control over the server boundary; it does not tell us, without configuration, which operations retain which bytes and for how long.
Comparing the three arrangements
The differences can be made concrete with the same invoice workflow.
In a browser-centered workflow, the editor's IndexedDB workbench may hold the original and the processed result. The user needs to verify which transformations call a backend and whether the backend is local or remote. The advantage is a low-friction interface and a workbench designed around local file state. The risk is that “in the browser” can be heard as “no bytes cross the browser boundary,” which the architecture does not establish for every operation.
In a desktop workflow, the editor and a backend runtime can be distributed together. The advantage is a compact local application boundary and a path to file associations and local execution. The risk is that bundled core software can make optional dependencies less visible. A desktop package still needs a clear account of which features are included, which language or conversion resources are installed, and how updates are verified.
In a self-hosted workflow, the browser is usually a client of a service that an individual or organization operates. The advantage is centralized configuration, a private API, and a common processing environment for shared or automated work. The risk is concentrated responsibility: the server becomes the place where network exposure, dependency availability, resource limits, and possibly durable document storage must be governed.
None of these is universally more private or more capable. A desktop application may keep processing close to one user but be difficult to standardize across a team. A self-hosted server may make policy and automation easier while requiring stronger administration. A browser workbench may reduce setup while relying on a backend for operations. The appropriate choice follows from the document workflow, not from the label of the interface.
The diagram separates entry point from processor and persistence. The three arrangements may converge on similar operations, but they assign state and maintenance to different owners. That is the decision surface a deployment plan should document.
The crucial distinction: local persistence versus local processing
The editor's local workbench is valuable precisely because it gives the interface a stable state model. It stores files and metadata, generates thumbnails, tracks revisions, and can undo an operation. Those behaviors improve usability and help a user understand which result belongs to which input. They do not decide how the operation itself is executed.
The shared operation layer makes that separation explicit. Before processing, it identifies compatible files and rejects empty or unusable inputs. It checks backend readiness for operations that need a backend, then processes files according to the operation's pattern. Afterward, it maps outputs back into the workbench. A same-format one-to-one operation can replace an input in a version chain; a conversion, merge, or split produces independent artifacts. This is a state-management decision in the editor, not evidence that the transformation happened in the browser.
The same caution applies in the other direction. A server-backed operation does not mean that the user has surrendered all local state. The editor may keep a local copy of the returned result, and a desktop package may keep the workbench and backend on one machine. To understand the actual boundary, a reader must inspect the operation route and configuration rather than infer it from the surface.
This is also why deployment documentation should describe more than ports and installation commands. It should say which operations are expected to run locally, which dependencies are installed, where workbench files live, whether server-side storage is enabled, and what happens to temporary inputs and outputs. The repository supplies the architectural pieces, but the deployment supplies the final arrangement.
The practical choice
For a personal workflow in which documents should remain close to one user and the required operations are available in the package, desktop or browser-centered use may be the simplest fit. The critical verification is not the interface; it is the processing path for the specific operations and the behavior of the local workbench.
For a team that needs a common toolset, repeatable configuration, or a private API, self-hosting is a more coherent boundary. The benefit comes from centralization, but so does the obligation to maintain the runtime and its providers. Shared operation should not be added without deciding whether results are merely returned to clients or retained by the service.
The durable lesson is simple: “local” is not a single property. It can refer to a browser's storage, a desktop package's runtime, a server under the organization's control, or a processing engine that is available without a third-party service. Those are different boundaries. Once they are separated, the next question follows naturally: even after choosing where Stirling PDF runs, what determines whether a particular tool is present, equivalent, or degraded?