HTML to PDF API data residency and GDPR: where your documents actually get rendered

Somewhere between picking a rendering vendor and shipping the integration, a security questionnaire lands on your desk. It asks where the documents are processed, who the sub-processors are, whether a data processing agreement exists, and how long anything is retained. Most HTML to PDF vendors answer two of those four questions on their public site, and the other two turn into a two week email thread with a sales engineer while your release slips.

This is a guide to answering those questions properly, and to asking them before you integrate rather than after. It is written for US teams, because US teams are the ones who get caught out: you may have no EU entity at all and still owe every one of these answers the moment a European customer's data passes through your PDF pipeline.

The short answer

An HTML to PDF API is almost always a data processor under GDPR, because it handles personal data on your instructions and for your purposes. That makes four things mandatory rather than optional: a written data processing agreement under Article 28, a documented list of sub-processors, a lawful basis for any transfer outside the EEA, and a retention period you can state in a number. If your rendering vendor cannot give you all four in writing, you do not have a compliance gap you can close later with a policy document. You have one you close by changing vendors.

Where does my data get processed?

The honest answer for most rendering APIs is "in whichever cloud region the vendor chose, plus wherever their CDN and logging providers sit." A render request is not one hop. Your HTML travels to the API endpoint, gets rendered in a browser process, the resulting file is written to object storage, a log line is emitted to a logging service, and often an error tracker sees a copy of the request context when something fails. Each of those can be a different provider in a different country.

That matters because the rendered document usually contains the most sensitive data in your system. An invoice carries a name, an address and a payment amount. A statement carries an account balance. A medical summary carries far more. The HTML you POST to a rendering service is frequently richer in personal data than the database row it came from, because it is the human readable version with everything already joined together.

So the question to ask is not "where are your servers" but "list every place a copy of my payload can exist, including logs, error reports, caches and backups, and tell me how long each one keeps it." Vendors who have thought about this answer immediately. Vendors who have not will answer the first half and go quiet on logs, which is itself a useful signal.

Is an HTML to PDF API a controller or a processor?

A processor, in essentially every normal configuration. GDPR draws the line on who decides the purposes and means of the processing. You decide what document gets generated, for whom, containing what. The vendor executes that instruction and does nothing else with the data. That is the textbook definition of a processor under Article 4(8), and you are the controller.

The line moves if a vendor starts using your payloads for its own purposes. Training a model on customer documents, building aggregate analytics that outlive your account, or enriching data against third party sources are all controller behaviours. Check the terms for a clause granting the vendor a broad licence to your content, because a licence written for product improvement can quietly convert a processor into a joint controller and take your Article 28 paperwork with it.

Do I need a DPA with a PDF API vendor?

Yes, if any personal data of EU or UK data subjects passes through it, and Article 28(3) is explicit that the contract must be in writing. The DPA is not a formality. It is the document that binds the processor to act only on your documented instructions, to keep the data confidential, to apply appropriate security measures, to help you answer data subject requests, to notify you of a breach without undue delay, and to delete or return the data at the end of the contract.

Two clauses in it deserve real attention rather than a skim. The first is sub-processor authorisation under Article 28(2): you want a published list and advance notice of changes, with a right to object, not a blanket permission to appoint anyone at any time. The second is the deletion clause, because "delete or return at your choice" is the default in the regulation and some vendor templates quietly narrow it to deletion only, which is a problem if you actually needed the archive.

Small practical note that saves weeks: ask for the DPA during evaluation, not after the contract. A vendor that will send you the DPA as a PDF the same day is a vendor that has done this before. A vendor that has to draft one is telling you that you would be their first customer to ask.

What about transfers from the EU to the US?

This is the part that has moved recently, so the date on your policy document matters. Transfers of personal data out of the EEA need a legal basis under Chapter V. For US vendors the two live routes are the EU-US Data Privacy Framework, if the vendor is certified, and Standard Contractual Clauses with a transfer impact assessment if it is not.

Where things stand as of August 2026: the Commission's 2023 adequacy decision for the Data Privacy Framework remains in force. It was challenged in the EU General Court by French MP Philippe Latombe, and that challenge was dismissed on 3 September 2025, which upheld the framework. An appeal to the Court of Justice of the European Union was filed on 31 October 2025 and is still pending. That is worth knowing rather than ignoring, because the CJEU is the same court that struck down both Safe Harbor and Privacy Shield, and a team that has built its entire transfer basis on the DPF alone would have work to do if the appeal succeeds.

The pragmatic position most well-advised teams take is to rely on the DPF where the vendor is certified but to have SCCs in the contract as well, so there is a fallback that does not require renegotiating anything under time pressure. Ask your rendering vendor which of the two they offer. If the answer is neither, they are not ready for an EU customer of yours.

US teams with no EU customers: does any of this apply?

GDPR may not, but the same questions arrive through a different door. Your enterprise customers' security reviews ask them regardless of geography. State privacy laws increasingly require you to describe categories of personal information disclosed to service providers and to flow contractual terms down to them. Sector rules add their own layer: financial services firms have recordkeeping obligations that reach any vendor holding a copy of a customer communication, and healthcare organisations need a business associate agreement before protected health information goes anywhere near a third party renderer.

The practical version is simpler than the legal version. If you cannot say, in one sentence, which vendors hold a copy of your customers' documents and for how long, you will fail an enterprise security review eventually. Teams that get this right tend to have already mapped where customer records travel across their warehouse and downstream tools, which is the same exercise; a data lineage view of where each field flows turns a two week questionnaire scramble into an afternoon. The document pipeline is just one more branch of that map, and it is the branch people forget because it feels like a rendering detail rather than a data flow.

Retention, and the request that breaks most pipelines

Erasure is where document pipelines fall over, because documents are copies and copies are exactly what a deletion request has to find.

Work through what happens when a customer asks you to delete their data. You delete the database rows. You delete the files in your own object storage. Then you remember that every one of those documents was rendered by a third party, which may still hold the payload in a log, the output in a cache, and both in last night's backup. If the DPA does not give you a deletion path at the processor, you cannot honestly tell the customer the data is gone.

So pin down three numbers before you integrate, and get them in writing rather than from a marketing page:

• Payload retention. How long the HTML or URL you submitted is kept after the render completes. The best answer is that it is discarded once the file is produced.
• Output retention. How long the generated PDF stays on the vendor's storage and whether you can set that number yourself. Some services delete after 24 hours, which is a feature if you did not want copies and a problem if you did.
• Log retention. The one everybody forgets. Request logs frequently contain URLs, and a URL with a signed token or a customer identifier in it is personal data sitting in a logging system with its own retention policy.

There is a real tension here worth naming, because it cuts against the way this site usually argues. Short retention is good for privacy and bad for auditability. If you are in a regulated industry you may be required to keep a copy of what you sent a customer for years, which means aggressive deletion at the vendor is not automatically the safe choice. Decide which obligation is stronger for each document type rather than applying one policy to everything: marketing PDFs should vanish quickly, while a disclosure document may need a retained, timestamped record for the full retention period.

The other half: what your renderer can reach

Data residency questionnaires focus on where data goes. The sharper risk with a rendering API runs the other way, because you are handing a vendor a browser and asking it to fetch a URL you supplied.

If your application lets users influence that URL, you have built a server side request forgery path into someone else's network, and possibly back into yours if the renderer runs anywhere near your infrastructure. Cloud metadata endpoints and internal admin interfaces are the classic targets. Ask whether the vendor blocks private address ranges and link-local metadata addresses by default, and whether rendering runs in an isolated sandbox per request rather than a warm shared browser that can carry cookies or cached credentials from one customer's render into another's. Our guide to HTML to PDF API security works through the specific controls in detail.

Seven questions to put to a rendering vendor

Question	What a good answer looks like
Which regions process my payloads?	A named list, with the option to pin processing to one region
Who are your sub-processors?	A published page, plus notice and a right to object before changes
Can I have your DPA?	Sent as a document the same day, with SCCs attached
Are you certified under the Data Privacy Framework?	Yes with a certification number, or SCCs as the stated alternative
How long do you keep my HTML, my PDFs and your logs?	Three separate numbers, not one vague sentence
Is rendering isolated per request?	A fresh sandboxed context per render, with private ranges blocked
What happens to my data if I leave?	Deletion or export on request, within a stated window

Notice that none of these is a feature question. They cost nothing to ask during evaluation and are painful to raise after you have shipped, which is the whole argument for asking early. If you are still shortlisting on price, the PDF API pricing comparison sets out what each vendor publishes, and the best HTML to PDF API guide covers rendering quality. This checklist is the third axis, and it is the one that decides whether procurement signs.

Where Sitepdf stands

Sitepdf is pre-launch, so the useful thing to publish is the design commitments rather than a compliance badge we have not earned. Rendering happens in a managed Chromium sandbox created per request and destroyed after it, so nothing carries between customers. The submitted HTML or URL is not retained after the render completes unless you explicitly ask for it to be archived, which is a parameter you set rather than a default we chose. Where a render is archived, the retention window is yours to set, because the whole point of that feature is meeting an obligation rather than creating one.

What we do not have yet: a SOC 2 report, a DPF certification, or region pinning. Those are on the roadmap and we are not going to imply otherwise on a page aimed at people running a vendor review. Our security page states the current position in the same plain terms, and if your requirement list needs any of those three today, buy from someone who has them and come back when we do.