# QR codes and GDPR, when a scan becomes personal data

> A static QR code generated client-side and pointing straight at your site adds no personal-data processing beyond an ordinary web visit. Dynamic codes are different: every scan log containing an IP address is personal data under GDPR, so you need a lawful basis, a processor agreement with the provider, and transparency at the code.

Source: https://useqr.app/docs/security/qr-codes-and-gdpr · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## Where GDPR enters a QR flow

A QR code is printed text; the ink itself processes nothing. GDPR becomes relevant at three
possible points: what you put **in** the payload, what happens at **creation**, and what
happens at every **scan**. This page is educational background for designing lower-risk QR
flows. It is not legal advice, and specific questions belong with a qualified adviser.

The three cases:

| Flow | Personal data processed? |
|---|---|
| Static code, client-side generated, pointing at your site | Only the ordinary web visit your site already handles |
| Payload containing personal data (a vCard, an email address) | Yes, at creation, by any server-side generator that receives it |
| Dynamic code via a redirect provider | Yes, per-scan logs held by a third party |

## Scan logs are personal data

A dynamic provider records the scanner's IP address, device details and timestamp on every
scan: the mechanics are in
[dynamic QR codes and privacy](/docs/security/dynamic-qr-codes-and-privacy). An IP address
is personal data even when you cannot identify the person yourself; the EU Court of
Justice settled that in its Breyer judgment. Consequences follow directly:

- **You are the controller** of a campaign's scan analytics; the provider processing them
  for you is a **processor**, which requires a data processing agreement (Article 28).
- A provider hosted outside the EU/EEA adds an **international transfer** to analyse.
- Data subjects hold their usual rights over the logs (access, erasure), which you can
  only honour if the provider supports them.

## Lawful basis for scan analytics

Counting scans in aggregate is commonly argued under **legitimate interest**; building
per-person profiles from scan behaviour points toward **consent**, which is awkward to
collect before a redirect fires. The practical guidance is data minimisation (Article
5(1)(c)): collect scan counts if counts answer the question, and resist the dashboard
maximalism of tools that log everything because they can. A fuller inventory of what gets
recorded is in [what is logged when you scan](/docs/security/qr-codes-and-tracking-what-is-logged).

## Transparency at the code

A person deciding whether to scan cannot see where the code goes or what the scan triggers.
The clean pattern is a **notice at the code**: print the destination domain and, where
analytics run, a short honest line ("Scans are counted anonymously") next to the code.
This does double duty: it is a transparency measure and it makes fraudulent sticker
overlays easier to spot. Wording that tells people what scanning does belongs to the same
craft as a good [call to action](/docs/marketing/qr-code-call-to-action).

## Designing for minimisation

The lowest-exposure design is also the simplest: a
[static code](/docs/basics/static-vs-dynamic-qr-codes) pointing directly at your own
domain, generated client-side so no third party sees the payload: see
[client-side vs server-side generation](/docs/security/client-side-vs-server-side-qr-generation).
Measurement then runs through your existing, already-documented site analytics using
campaign parameters, with no new processor and no new scan-log dataset to account for.

## The CCPA contrast

California's CCPA/CPRA takes a different shape: an opt-out regime rather than opt-in, built
around rights to know, delete and opt out of "sale" or "sharing" of personal information,
definitions broad enough that scan analytics passed to an adtech-flavoured provider may
qualify. The design conclusion is the same on both sides of the Atlantic: the less a scan
generates about a person, the less law you drag into a piece of printed matter.

## FAQ

### Are QR codes GDPR compliant?

The code itself is out of scope. It is printed text. Compliance questions attach to the
flow around it: what the payload contains, whether generation sends data to a server, and
whether scans are logged by a provider. A static, client-side-generated code pointing at
your own site adds nothing new to comply with.

### Is a QR code scan personal data?

A scan handled by a dynamic provider produces a log entry containing the scanner's IP
address, which is personal data under GDPR. A static code produces no scan record beyond
the ordinary visit to the destination site.

### Do I need consent for QR code analytics?

Aggregate scan counting is commonly run under legitimate interest; anything approaching
individual profiling points toward consent. Either way you need transparency, a lawful
basis you can articulate, and a processor agreement with any provider holding the logs.

### Do I need a privacy notice next to a QR code?

It is good practice: print the destination domain and a short line saying what scanning
does. It satisfies the spirit of transparency and simultaneously makes a substituted
malicious sticker easier to notice.

## Try it

- https://useqr.app/url
- https://useqr.app/vcard
- https://useqr.app/validate