Security in the Rixoffice PDF Editor has two halves: opening protected documents and keeping your work private. The editor opens password-protected PDFs — enter the password, and the document unlocks locally on your machine, with the password never leaving it. Everything else in the editor already runs locally: rendering with PDF.js, editing with pdf-lib and pdfium, saving — no upload step exists for your documents, which is the baseline that makes it usable for confidential material.
Open a password-protected PDF
- Open the encrypted PDF as usual — from the Home screen recents or directly.
- The editor detects the encryption and prompts for the password.
- Enter it; decryption happens on your machine, in memory.
- The document renders and works like any other for the session.
- Ctrl+S saves your changes with the protection the file carries.
The prompt is the only gate — there is no separate unlock mode to find. If a colleague sends a protected file and the password separately, the editor is where they meet.
What "locally" actually means
The phrase does real work here, so precisely:
- The password you enter decrypts the document on your machine; it is not transmitted, logged or stored remotely.
- The document renders and edits through local engines — PDF.js for display, pdf-lib and pdfium for structural edits.
- The saved file writes to your disk, in your folder, under your control.
This is the same privacy model as the rest of Rixoffice: internet is for updates and, if you enable it, cloud AI. The documents themselves never leave the machine unless you send them.
AI and privacy, briefly
The AI assistant reads the PDF to answer questions and make edits — and it does so locally: the document content is processed on your machine by the local AI pipeline, not shipped to a server for analysis. If you run AI through Ollama on a local model, the entire path — document, prompt, answer — stays on the machine even of internet access. For the standard plan, cloud AI calls follow the provider you configured; see the AI provider setup guide. Either way, the editor never uploads your PDF behind your back.
| Concern | How it is handled |
|---|---|
| Password entry for encrypted files | Local decryption; password never transmitted |
| Document content in editing | Local engines; no upload |
| AI features | Local processing via Ollama, or your configured provider |
| Saved files | Your disk, your folders |
Protecting documents you send
The editor's security story is opening and privacy; for applying protection to outgoing documents, the practical pairing is:
- Finish the document — edits, stamps or watermarks, Bates numbering if it is a set.
- Apply the protection appropriate to the file's sensitivity with standard PDF security before sending.
- Share the password through a different channel than the file itself — the same rule as ever.
A watermark declares status to the honest reader; encryption enforces it with the rest. The two together are the standard for confidential sets.
What to explore next
- Getting started for the local workflow foundation.
- AI assistant for the privacy-aware AI tools.
- Metadata and properties — check what the properties say before sending.