Skip to content
UseQR
ESC

Jump to

MOVEOPEN50 places

Security & privacy

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.

View as MarkdownPaste this page into any AI assistant. It is plain, portable Markdown.

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. 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.

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.

Designing for minimisation

The lowest-exposure design is also the simplest: a static code pointing directly at your own domain, generated client-side so no third party sees the payload: see client-side vs server-side 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.

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: free, no signup