GDPR and Privacy When Translating Your Website

This article is general information, not legal advice. Privacy law differs by country and by facts, and we are not lawyers. Check the primary guidance below and ask a qualified adviser about your own site.

Translating a website can involve personal data when the content or the tooling touches it. Marketing pages usually contain little, but user comments, account pages, checkout and support content often do. The practical questions are what text leaves your site, who receives it, in what role, where it is stored, and what the translation tooling sets in the visitor's browser.

What data does a translation service actually receive?

It depends on how translation is delivered. Map this before choosing a tool.

The choice between server-side and browser-side delivery has SEO consequences as well; see client-side vs server-side translation. From a privacy angle, also consider metadata: when a visitor's browser contacts a third-party domain, that vendor can normally see the IP address and user agent. Whether that is personal data and what the vendor does with it should be stated in the vendor's documentation.

Who is the controller and who is the processor?

The GDPR distinguishes controllers, who determine the purposes and means of processing, from processors, who process on a controller's behalf. The EDPB's Guidelines 07/2020 on these concepts (final version adopted 7 July 2021) explain how to assess the roles. A point stressed in commentary on the guidelines is that roles are a matter of fact: what the contract calls a party is not decisive on its own.

In general terms, and subject to your own facts:

• A site owner who decides to translate its pages and sends the text to a vendor for translation is typically the controller for its visitors' data.
• A vendor that translates strictly on the site owner's instructions is commonly a processor.
• A vendor that also uses submitted content for its own purposes, such as training its own models or analytics, may be acting as a controller for that use, which changes your obligations. Ask the vendor explicitly whether submitted content is retained or reused.

What should a data processing agreement cover?

If a vendor is your processor, GDPR Article 28 requires a binding contract. The UK ICO's guidance sets out what such a contract must include; the same Article 28 structure applies under the EU GDPR. According to the ICO, it must cover:

• the subject matter, duration, nature and purpose of the processing, the type of personal data and categories of data subject;
• processing only on your documented instructions, including regarding international transfers;
• confidentiality commitments for people handling the data;
• appropriate security measures;
• conditions for engaging sub-processors, including prior authorisation and flow-down of obligations;
• help with data subject rights requests, breach notification and impact assessments;
• deletion or return of data at the end of the contract;
• information and audit rights.

The ICO also notes that standard contract clauses can be used, referring to clauses adopted by the Danish Data Protection Agency and approved by the EDPB. Read what a vendor offers against this list, and check the sub-processor list when you sign and when it changes.

Where is the data processed, and what about transfers?

Where servers sit matters because transfers of personal data out of the European Economic Area need a transfer mechanism. The European Commission's page lists the available tools: adequacy decisions, standard contractual clauses (SCCs), binding corporate rules, certification mechanisms, codes of conduct and derogations. The Commission describes SCCs as pre-approved model clauses, with modernised versions issued on 4 June 2021. UK transfers are governed by separate UK rules; consult the ICO's own guidance for those.

Questions to put to a vendor:

1. In which countries are translation requests processed and stored?
2. Which transfer mechanism applies if data leaves the EEA or UK?
3. Which sub-processors (cloud hosts, machine translation engines) are involved?
4. How long are source texts and translations retained, and can retention be disabled?

What do language switchers and translation scripts store on a device?

Language switchers often store the visitor's choice in a cookie or in local storage so later pages open in the right language; see our UX guidance on remembering the choice. In Europe, rules on storing or accessing information on a user's device (the ePrivacy rules, implemented in the UK through PECR) can require consent unless an exemption applies. The ICO's UK guidance, finalised on 29 April 2026 according to its page, lists exceptions including communication, strictly necessary, statistical purposes, appearance, emergency assistance and a simple means of objecting. We could not confirm from the sources we read whether a language preference falls within an exception in your jurisdiction, so treat it as verify with your regulator's current guidance or your adviser.

Practical steps regardless of the answer:

• Store only a language code, with a short life, and nothing identifying.
• Document what each translation script sets, including cookies and requests to third-party domains. Test with browser developer tools rather than trusting a vendor summary.
• Make sure a visitor who declines optional cookies can still switch language through the URL.

How can you reduce exposure?

The ICO's guidance on data protection by design and default says to collect and use only the personal information necessary for each purpose, limit extent of processing and retention, and choose processors offering sufficient guarantees. Applied to translation:

• Translate templates and public content, not personal data. Keep account, order and support pages out of automated third-party translation unless you have a reason and a contract.
• Pre-translate and publish static output. Serving translations from your own infrastructure means visitors' browsers do not contact the vendor on each page view. This is also an availability benefit; see avoiding translation vendor lock-in.
• Strip or mask personal data before sending user-generated text to translation, or exclude it from translation by default.
• Use human or hybrid review where content is sensitive, and understand where reviewers work; see machine vs human vs hybrid translation.
• Update your privacy notice to name the categories of recipients and the purpose, and keep a record of the vendor's sub-processors.
• Run a data protection impact assessment if processing could be high risk. The ICO says a DPIA is required for high-risk processing and good practice otherwise.

We are building ResilientLang to favour pre-generated translations that you control, but it is not released, and nothing here is a statement about any product's compliance.

Key takeaways

• Translation tooling can touch personal data through user content, logged-in pages and request metadata; map it before you choose a tool.
• Controller and processor roles depend on the facts of the processing, as the EDPB guidelines explain, not only on contract labels.
• A processor relationship needs an Article 28 contract; the ICO lists the required terms.
• Check processing locations, sub-processors and the transfer mechanism, and confirm whether submitted text is retained or reused.
• Reduce exposure by minimising what is sent, pre-translating public content, and documenting cookies and scripts.
• This is general information, not legal advice.

Sources

• EDPB: Guidelines 07/2020 on the concepts of controller and processor in the GDPR – final version of 7 July 2021 on controller and processor roles
• ICO: What needs to be included in the contract – required terms of a controller-processor contract
• European Commission: Rules on international data transfers – transfer tools for data leaving the EEA
• European Commission: Standard contractual clauses (SCC) – what SCCs are and the 2021 modernised clauses
• ICO: Guidance on the use of storage and access technologies – consent and exceptions for cookies and similar technologies (UK)
• ICO: Data protection by design and default – data minimisation and DPIA points