Why We Skipped the Desktop App
PDF123 will not ship a second desktop UI. Offline and private use stay on Docker Compose plus pdfx, so the catalog cannot drift from the API surface.
When files must not leave a private network, the next request is often a Windows or macOS installer. We declined that shape on purpose. A desktop GUI would be a second UI codebase. Feature drift between “the app” and /api/v1/ is almost inevitable once those trees diverge.
The constraint is the boundary, not the chrome
“Bytes stay here” is satisfied by a pdfx-server you run, not by WinForms or Electron specifically. Compose plus pdfx (local or --cloud against your base URL) keeps one operation catalog behind browser, REST, MCP, and CLI.
How to stand that stack up is documented on Self-host: task docker:build / task docker:up for Compose (API on :8080, portal on :3000), or native task pdfx:dev beside the portal for local work. Set SECURITY_CUSTOMGLOBALAPIKEY when you want a fixed gate. This post is only about why that stack is not wrapped as a desktop product.
Local pdfx without --cloud runs pdf-core on the machine that has the files. That already covers offline batch jobs that never needed a GUI. Cloud mode is for when the same CLI should hit your self-hosted or hosted API base with the same multipart contract as curl.
What a desktop fork would cost
Consumer suites optimize canvas editing, visual compare, and store installers. Maintaining that surface means duplicating every new op (merge flags, OCR modes, sanitize defaults) in a GUI that is not the OpenAPI contract agents already call.
Plugins and store channels multiply support without improving MCP or Idempotency-Key behavior. Each store review cycle and OS permission prompt is time that does not land in /v1/openapi.json. Once the desktop tree ships a merge option the API lacks (or the reverse), automations and demos disagree silently.
OCR is a concrete example of why duplication hurts. The current server path returns Markdown (text/markdown) with Auto vs Force modes (ocrType=force-ocr for Force). A desktop UI that still promised “searchable PDF with a hidden layer” would be lying about a different pipeline. Keeping one op definition avoids that split.
One catalog, four clients, zero second UI
The product already has four handles on the same ops: the portal form, curl to /api/v1/…, MCP at /mcp, and pdfx local or cloud. Merge is the concrete example: combine PDFs in upload order without rasterizing pages into images, whether you clicked Process or posted fileInput parts.
A desktop edition would be a fifth handle with a separate release train. The failure mode we care about is not “missing a tray icon.” It is “the demo page still works while the script that depended on the same op silently regresses.”
What we are not claiming
Skipping desktop does not invent Acrobat-class interactive editing in the browser. Form tools and HTTP jobs remain the product. Online Edit canvases, visual compare, and consumer Sign UIs stay out of scope on purpose. If you need a private deployment, compose up and point clients at your API base. If you need a pixel editor, use a suite built for that; do not wait for a PDF123 .exe.
Hosted PDF123 stays the fast anonymous path. Self-host is the same toolkit behind your firewall. Neither path is a third, divergent desktop edition. For the contrast with browser-only converters, see Why self-host a PDF toolkit. For what you buy and what you operate, see What self-hosting actually buys you. For how the four non-desktop clients stay aligned, see Same operation, four clients.