Does UniHTML send my HTML anywhere?

Yes, and this is the one UniDoc library where that is the honest answer. The markup, or the URL, is sent over HTTP to the UniHTML server, because the server is where the browser lives. Nothing renders in your process.

The part that matters for a review is where that server is. You run it. It is a container in your own infrastructure, on your own network, behind your own firewall rules. There is no hosted conversion endpoint, UniDoc operates nothing in the path, and the content is not sent anywhere else.

Compared with a document-conversion API, the difference is who owns the machine doing the work rather than whether the content moves.

What crosses the wire

One POST to /v1/pdf on your server, carrying JSON:

Field	Contents
`content`	Your HTML, or a zip of your asset directory. Empty for the URL method.
`contentURL`	The URL to fetch, for the URL method only.
Page parameters	Page size, orientation, the four margins.
Render parameters	Wait time and any selectors to wait for.

The response is the PDF bytes. That is the whole protocol.

Put the server on a private network. The endpoint has no authentication of its own, so anything that can reach it can convert. Use TLS as well if the hop crosses a boundary you do not trust, either by terminating it at a proxy in front of the server or by connecting with https.

What the server keeps

Nothing, for long. There is no database. Uploads are held in memory below 1MB and written to the container’s filesystem above that, and either way they are registered with a cleaner and expire after three minutes. Generated PDFs go the same way.

A container with no persistent volume therefore holds your content only for the length of the request plus that expiry window, and loses everything on restart.

Outbound fetches from the container

Whatever your page references, the container fetches. A stylesheet from a CDN, a web font, a charting library, an <img> on a public URL: all of those are requests from the container to the internet, not from your process.

An air-gapped deployment cannot load any of it, so the page has to be self-contained. And the container’s outbound traffic tells whoever hosts those resources which of them your documents reference.

Bundle the assets into the directory you upload if either matters. See asset directory.

What the license check transmits

Separate from the conversion, and the same as the rest of UniDoc. A metered key makes an outbound call to the UniDoc license server carrying:

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, HTML, URLs or filenames.

Both the client and the server do this, since both are licensed.

Removing the outbound call

Use an offline license. It verifies from its own signature and makes no network call, which is the reason it exists. Give it to the server through the environment:

docker run -d -p 8080:8080 \
  -v /path/to/license.txt:/license.txt \
  -e UNIHTML_LICENSE_PATH=/license.txt \
  -e UNIHTML_CUSTOMER_NAME="My Company" \
  unidoccloud/unihtml

And to the client in code:

if err := license.SetLicenseKey(offlineLicenseKey, `My Company`); err != nil {
    panic(err)
}

With offline licenses on both, and pages that reference no external resources, the whole pipeline runs with no outbound connections at all. That is the configuration for an air-gapped deployment. See how do I license the UniHTML server?

Your license key is a credential

Read it from an environment variable or a secret store rather than committing it, and treat the container’s environment the same way. Anyone holding the key can spend your credits.

Last updated on August 22, 2026

How do I license the UniHTML server?