Does UniOffice send my documents anywhere?
No. UniOffice is a library, not a service. Parsing, layout and writing all happen inside your own process, so document content is never uploaded, never queued and never stored anywhere outside the machine running the code. There is no rendering endpoint to send a file to.
That includes PDF conversion, which is the one people ask about most. The converter is UniOffice and UniPDF code running in your binary, not a call to a conversion service.
The content never crosses your network boundary, so it never enters a third party’s logs, caches or backups.
What the license check does transmit
A metered API key makes an outbound call to the UniDoc license server. The payload carries:
| Field | What it is |
|---|---|
| Usage counts | How many documents were processed, for billing. |
| Instance identifier | A generated id for the running process. |
| Hostname, local IP, MAC address | Machine identifiers. |
| Package name and version | Which UniDoc library and release. |
| Timestamp | When the report was made. |
It does not carry document content, filenames, or anything read out of your files.
By default usage is cached and reported periodically.
license.SetMeteredKeyPersistentCache(false) reports immediately instead, which
is what you want where there is no writable persistent storage. The cache
location follows UNIDOC_LICENSE_DIR, defaulting to the home directory, which is
worth setting explicitly in a container or under a service account with no home.
Removing the outbound call entirely
Where any outbound connection is unacceptable, use an offline license. It is verified from its own signature and makes no network call at all, which is the whole reason it exists:
if err := license.SetLicenseKey(offlineLicenseKey, `My Company`); err != nil {
panic(err)
}That is the right answer for air-gapped deployments, and for OEM products shipping to customers whose networks you do not control. See How to load the UniOffice license key?
What UniOffice does not protect
Keeping content on your own machine is not the same as securing the file, and the distinction matters.
Workbook protection is not encryption. UniOffice does support Excel’s
protection mechanism: WorkbookProtection and SheetProtection lock the
structure, windows, a sheet or its objects, each with a password. It is worth
being clear about what that buys you, because the name suggests more than it
does.
The password is stored as a hash produced by spreadsheet.PasswordHash, which
is Excel’s legacy algorithm: it folds the whole password into a 16-bit value
written as four hex digits. Two different passwords collide easily, and the file
contents are not encrypted at all, so anything in the workbook can be read
without knowing it. It asks Excel to refuse edits. Treat it as a guard against
accidental changes, not as access control, and note this is Excel’s design rather
than a UniOffice limitation.
Word documents and presentations have no protection API at all.
Encrypted files cannot be opened. There is no support for reading a password-encrypted document, and none for writing one. If the file itself must be protected at rest, encrypt it in your storage layer.
Your license key is a credential. Read it from an environment variable or a secret store rather than committing it. Anyone holding it can spend your credits.