Stirling-PDF vs locally installed PDF editor (workflow)

[Utility9298]

Hi everyone,
I do support a company working a lot with PDFs. They most common use case is merging PDFs, deleting pages or to disguise some parts of PDFs before sending them.

A lot of these PDFs are stored in a CRM system, the currently installed PDF editor directly opens is, allows the user to edit and then save the file as it was.
I showed them stirling-PDF but it seems like it breaks the workflow. They have to upload the PDF to the web page, edit it, it automatically gets stored in the "Downloads" folder and then have to be manually moved back to the place of origin.

Is there something I am missing? I tried to install stirling-pdf as a Edge Web-App but I have not found any way to set it as default for editing PDFs.
Does anyone else came across this?

By the way: I love stirling-pdf so maybe someone have an idea if this could be optimized with stirling-pdf?

[dosubot[bot]]

Hi @Utility9298! I'm Dosu and I’m helping the Stirling-PDF team.

You're not missing anything—Stirling-PDF's workflow is fundamentally different from native PDF editors. Locally installed editors let you open, edit, and save files directly from your CRM or file system, which is seamless for users. Stirling-PDF, being web-based, always requires uploading the file, editing, and then downloading the result, which lands in your "Downloads" folder and must be manually moved back to the original location. This is a common pain point for teams handling lots of PDFs and is echoed by other users and companies considering Stirling-PDF as a replacement for tools like Adobe Acrobat or PDFsam [discussion].

Currently, there is no built-in way to set Stirling-PDF as the default PDF editor or to integrate it directly with CRM systems for seamless open/edit/save workflows [source]. There are feature requests and discussions about enabling direct file access via URLs or a "watch folder" approach, but these are not implemented due to security and architectural concerns [feature request].

If you want to optimize the workflow, the best options are:

• Use Stirling-PDF's API endpoints to automate PDF operations and integrate with your CRM or scripts, so users don't have to manually upload/download files [API info].
• Consider a custom integration or automation that uploads files from your CRM to Stirling-PDF, processes them, and returns the result to the CRM, but this requires development effort.
• Keep an eye on feature requests for direct integration or cloud storage support (like Google Drive/OneDrive), which may help in the future [cloud integration request].

For now, the manual upload/edit/download workflow is a known limitation of Stirling-PDF compared to native editors.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}