Does UniPDF send my documents anywhere?

No. UniPDF is a library, not a service. Parsing, rendering, extraction 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 conversion endpoint to send a file to.

The content never crosses your network boundary, so it never lands in a third party’s logs, caches or backups.

Three features do reach the network, and one of them sends document content. All three are opt-in.

What the license check transmits

A metered API key makes an outbound call to the UniDoc license server. The payload carries:

It does not carry document content, page text or filenames.

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.

An offline license removes this call entirely. It is verified from its own signature and makes no network connection at all, which is why it exists for air-gapped and OEM deployments.

OCR sends image data to a service you choose

This is the one feature that transmits document content.

UniPDF does not recognize text in images itself. The ocr package is an HTTP client: it packs an image into a multipart form, posts it to a URL you configure, and hands back the response unchanged. The recognition happens in whatever service sits at that URL.

That service is yours. Nothing is sent unless you set a URL and call the package, and where you point it is entirely your decision, so running the OCR service inside your own network keeps the images there too. Point it at a third-party cloud OCR API and the page images go to that third party, on their terms rather than ours.

If you do not use the ocr package, no image data leaves the process.

Signing reaches the network, but sends only hashes

Two parts of the signature workflow make outbound requests. Neither sends the document.

Timestamping. A PAdES B-T signature contacts the timestamp authority you set with SetTimestampServerURL. The request is an RFC 3161 message imprint, which in UniPDF is a SHA-512 hash of the signed data. The authority receives that hash and returns a signed token; it never sees the document, and cannot reconstruct it from the hash.

Revocation checking. Building an LTV-enabled signature, or validating one, fetches certificate revocation information over OCSP and CRL. Those requests go to URLs published inside the certificates themselves, meaning the issuing certificate authority’s servers, not UniDoc’s. They carry certificate identifiers, not document data. UniPDF logs and continues when a request fails rather than aborting.

Both are opt-in: a plain signature with no timestamp and no LTV makes no network call.

Running with no outbound connections at all

For an air-gapped deployment, or where a compliance rule forbids egress:

• Use an offline license rather than a metered API key.
• Do not use the ocr package, or point it at a service on your own network.
• Sign without a timestamp and without LTV, or supply revocation data yourself rather than letting it be fetched.

With those, UniPDF makes no outbound connection.

What this is not

Keeping content on your machine is not the same as securing the file. UniPDF has real encryption for that, which is a separate question with its own answers: locking a document with a password and opening an encrypted one.

Your license key is a credential. Read it from an environment variable or a secret store rather than committing it, since anyone holding it can spend your credits.