Skip to content
Does UniOffice send my documents anywhere?

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:

FieldWhat it is
Usage countsHow many documents were processed, for billing.
Instance identifierA generated id for the running process.
Hostname, local IP, MAC addressMachine identifiers.
Package name and versionWhich UniDoc library and release.
TimestampWhen 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.

Last updated on