Skip to content
UseQR
ESC

↑↓ MOVE↵ OPEN48 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