Are QR codes GDPR-compliant? Data, consent, and what a tracked scan really collects

Every agency that prints a tracked QR code eventually gets the same question, either from a client or from its own legal team: is this even allowed? You are, after all, measuring what people do with a printed object, and nobody who scans it ever signed up for anything. The honest answer is that QR codes are not a privacy problem in themselves, but a tracked QR campaign does touch personal data in two specific places, and the rules everyone worries about (the GDPR, plus the often-forgotten ePrivacy rules behind cookie banners) apply there, not to the code on the wall.

This guide is for the people running the campaign, not for lawyers. It is sourced to the actual statutes and court rulings rather than to vendor marketing, and it is honest about the parts the industry tends to gloss over. It is not legal advice: a campaign that collects sensitive data, profiles individuals, or runs at large scale deserves a look from a data protection officer. But for the ordinary case, a poster or a flyer or a packaging code that counts scans and sends people to a page, the path to compliance is short and concrete once you can see where the data actually lives.

A QR code collects nothing. The tracking happens somewhere else

Start with the thing itself. A QR code is a printed pattern defined by an international standard, ISO/IEC 18004. It encodes a short string of characters, almost always a URL, and that is all it does. It cannot run code, it has no callback, and it is identical on the wall whether nobody scans it or ten thousand people do. A static QR code, where that URL points straight at your destination, logs nothing and collects nothing. There is no data to protect because there is no data.

Tracking enters the moment you make the code dynamic. A dynamic QR code does not encode your destination directly. It encodes a short URL on the provider's domain, and scanning it makes a brief stop at that address before the provider redirects the phone on to the real page. That stop is an ordinary web request, and like every web request it carries information: the visitor's IP address, the user-agent string (which reveals device, operating system and browser), a timestamp, and sometimes a referrer. From the IP the provider can derive an approximate location, usually at city or country level, and from the user-agent it can derive the device type. None of that is the code's doing. It is the redirect's.

Then there is the third layer, and it is the one people forget: the page you send the scan to. A landing page is a normal web page, and it can do everything any web page does, which is to say it can set cookies, load Google Analytics, fire a Meta or TikTok pixel, and build a far richer profile than a redirect ever could. Most of the real tracking in a QR campaign lives here, on the destination, not in the scan.

So the mental model that makes the whole legal picture click is three layers, not one.

1. The printed code is inert. It stores a URL and collects nothing, scanned or not.
2. The redirect is a short URL on the provider's domain. It logs the request: IP, user-agent, timestamp and referrer, plus the rough location and device type it can derive from them.
3. The landing page is where cookies, analytics tags and marketing pixels live, and where the richest tracking actually happens.
4. The dashboard you read is the aggregate: counts by day, place and device. How personal the data behind it is depends entirely on what layers two and three kept.

It is worth separating two worries that often get mixed up, because the search results for QR privacy are full of the wrong one. This guide is about privacy: what data a scan involves and how to handle it lawfully. Whether someone can hijack your code with a sticker is a security question, and a different article. Keep them apart and each gets a cleaner answer.

Is scan data "personal data"? Usually, yes

The GDPR only applies to personal data, so the first real question is whether a scan log counts. The regulation defines personal data as any information relating to an identified or identifiable person, and it explicitly includes "online identifiers". The pivotal point is about IP addresses. In its 2016 Breyer ruling (case C-582/14), the Court of Justice of the European Union held that a dynamic IP address is personal data in the hands of a party that has the legal means to identify the person behind it, typically by going to the internet provider. The practical takeaway for an agency is blunt: treat the IP addresses in your scan logs as personal data by default, because a court already decided that they usually are.

This is where a common vendor claim falls down. Plenty of QR providers say they "anonymise" IP addresses and conclude the data is therefore outside the GDPR. Hashing or truncating an IP is genuinely useful, but it is usually pseudonymisation, not anonymisation, and pseudonymous data is still personal data. The line, set by Recital 26 of the GDPR, is identifiability by "all the means reasonably likely to be used". A consistent hash of a small, guessable value like an IP address can often be reversed or linked back, so it does not clear that bar. The Court reinforced the point in 2024 in the IAB Europe case (C-604/22): a coded string is still personal data if it can, by reasonable means, be tied back to a person. Your scan data only stops being personal once it is irreversibly aggregated, for example into counts per city per day with no underlying per-scan records kept.

The cookie-banner question, where most campaigns get it wrong

Here is the distinction that almost no vendor page gets right, and it is the single most useful thing in this guide. Cookie banners do not come from the GDPR. They come from a separate, older set of rules, the ePrivacy Directive, whose Article 5(3) says you need consent to store information on, or read information from, a person's device. That is a different test from "are you processing personal data". It is specifically about touching the device.

Apply that test to the three layers and the picture is clear. The redirect log generally does not trigger it. When a phone makes the web request to your short URL, it sends its IP, user-agent and referrer as a normal part of how the web works; the provider is receiving information the device volunteered, not instructing the device to store or hand back stored information. The European Data Protection Board's guidance on the technical scope of Article 5(3) draws the line at exactly that "instructing the device" step. So a plain server-side scan log usually needs no cookie banner.

The landing page is the opposite. The moment it loads Google Analytics, a Meta pixel or any similar tag, it is writing to and reading from the device, and analytics cookies are not "strictly necessary", so you need consent first. The UK's Information Commissioner is explicit that analytics cookies require consent, judged from the user's perspective rather than the business's, and EU regulators take the same line. The one-sentence version worth taping to your monitor: the scan usually does not need a cookie banner, but the page you send people to usually does.

One honest caveat, because the industry is already trying to game this. You cannot dodge the banner by quietly assembling device signals into a fingerprint on the server side. The same EDPB guidance treats deliberate fingerprinting and instructed identifier collection as in scope for Article 5(3). The "redirect log is exempt" rule holds for an ordinary log that records what a request happened to contain. It is not a licence to build a covert identifier.

Which lawful basis do you actually need?

If the scan data is personal data, the GDPR says you must have one of six lawful bases for processing it. For ordinary, aggregate scan analytics, the workable basis is usually legitimate interest. Measuring how a campaign you paid for is performing is a legitimate purpose, the data involved is modest, and the Breyer ruling above expressly accepted that a site operator can have a legitimate interest in logging this kind of request data. Legitimate interest is not a free pass, though. You have to actually run the three-part test, which means naming the interest, showing the processing is necessary for it, and balancing it against the rights and reasonable expectations of the people scanning, and then writing that assessment down.

You move into needing consent when you go beyond counting. Building a profile of an individual across scans, following the same person across sites or sessions, capturing precise GPS location, or combining scan data with other identifiers to single someone out: those raise the stakes, and the safer (often required) basis becomes consent that meets the GDPR standard, which is to say freely given, specific, informed and unambiguous, with no pre-ticked boxes.

And here is the trap to avoid. Legitimate interest under the GDPR does not buy you out of the ePrivacy consent requirement. They are two separate questions. You can have a perfectly good legitimate-interest case for your analytics and still need consent for the cookie that powers it on the landing page. Answer both, every time.

A compliance checklist for the campaign

None of this is hard to honour in practice. For the ordinary tracked QR campaign, the work comes down to a short list.

1. Choose a provider that aggregates by default and does not build personal profiles. This is data minimisation (Article 5(1)(c)) made concrete: if you only need counts, only collect counts.
2. Truncate or anonymise the IP at the redirect, and store aggregate metrics. Be honest that truncation reduces risk rather than guaranteeing anonymity, but it is the right default and exactly the kind of measure the minimisation principle asks for.
3. Put a privacy notice on the landing page. Articles 13 and 14 require you to tell people, at the point of collection, who you are, what you collect, why, your lawful basis, how long you keep it, and what rights they have. The landing page is that point of collection.
4. Get consent before any non-essential cookie or pixel on the destination. If your page runs GA4 or a marketing pixel, the consent banner is not optional, and it has to offer a real choice rather than a wall.
5. Sign a data processing agreement with your QR and analytics provider. When they process scan data on your instructions, Article 28 requires a written DPA. Remember the chain: you are usually the processor for your client, who is the controller, and your QR provider is your sub-processor.
6. Check where the data lives. Prefer a provider that hosts in the EU or EEA. If scan data lands in the US or elsewhere, you need a proper transfer mechanism, either the provider's EU-US Data Privacy Framework certification or Standard Contractual Clauses plus a transfer assessment.
7. Set a retention period and keep to it. Identifiable scan logs should not live forever. Decide how long you genuinely need them, document it, and delete or aggregate after that.
8. Keep a route open for data-subject requests. If someone asks what you hold about them or asks you to erase it, you need to be able to answer for whatever identifiable scan data you still have.

Most of this is provider configuration plus one page of notice text. The agencies that get into trouble are rarely the ones running tracked codes; they are the ones running marketing pixels on the landing page with no consent and no notice, which is a website problem that happens to sit behind a QR code. If you keep each client's campaigns in their own separate workspace and resist the urge to pool scan data across clients, you also satisfy purpose limitation almost for free.

What changes in the Netherlands and Germany

The GDPR is one regulation across the EU, but it is implemented locally and enforced locally, and two of the markets this product serves are worth a specific word.

The Netherlands (AVG)

In Dutch the GDPR is the AVG, and the regulator is the Autoriteit Persoonsgegevens (AP). Cookie consent lives in Article 11.7a of the Telecommunicatiewet, which requires consent for tracking cookies while exempting strictly necessary and certain privacy-friendly analytics cookies. What matters right now is enforcement. Through 2024 and 2025 the AP has been actively sending warning letters to organisations that use tracking cookies without valid consent, and going after misleading cookie banners, typically giving recipients around three months to put things right. A Dutch landing page running GA4 with no consent sits squarely in the AP's current line of fire, which makes point four on the checklist the one to take most seriously.

Germany (DSGVO)

In German the GDPR is the DSGVO, sitting alongside the federal BDSG and enforced largely by the state authorities coordinated through the DSK. Device-access consent has its own statute, paragraph 25 of the TDDDG (the 2024 successor to the TTDSG), which requires prior consent for cookies and similar storage and carries fines up to 300,000 euros. Germany has historically been the strictest country on IP logging: it is no coincidence that the Breyer case started there, with a citizen suing the state over its web server logs. The reassuring part is that even Germany treats the IP and referrer in an ordinary HTTP request as data the device sends on its own, not as device access needing paragraph-25 consent. The redirect-versus-landing-page distinction holds in the strictest market too.

Frequently asked questions

Are QR codes GDPR-compliant?

The code itself is out of scope, because a printed QR code is inert and collects nothing. Compliance is about the two layers behind it. The redirect that logs a scan needs a lawful basis (usually legitimate interest) but generally no cookie banner, and the landing page needs a privacy notice and consent for any non-essential cookies. Get those right and a tracked QR campaign is fully GDPR-compliant.

Do QR codes track you?

A static QR code cannot track anyone; it is a printed link with no logging. A dynamic, trackable code logs the scan event at its redirect: your IP address, device type, rough location and the time. It is tracking the scan, not your name, and how far it goes depends entirely on the provider and the destination page, not on QR technology itself.

Do QR codes collect personal data?

The image collects nothing. The redirect behind a dynamic code logs your IP address, user-agent, timestamp and referrer, and an IP address is generally personal data under the GDPR. So a tracked QR campaign does process personal data, which is why it needs a lawful basis and a privacy notice, even though it never learns your name.

Do you need consent to track QR code scans?

Not for ordinary aggregate scan analytics done server-side at the redirect, which can rest on legitimate interest. You do need consent for anything that touches the visitor's device on the landing page, such as Google Analytics, a marketing pixel, or other non-essential cookies. The scan log and the landing-page cookies are two separate consent questions.

Is an IP address personal data?

Yes, as a default. The Court of Justice ruled in Breyer (2016) that a dynamic IP address is personal data for anyone with the legal means to identify the person behind it. Treat the IP addresses in your scan logs as personal data, and minimise or truncate them accordingly.

Do QR codes use cookies?

No. Neither the code nor the redirect sets a cookie; the redirect is a server-side hop. Cookies appear only if the destination page sets them, exactly as on any other web page. That is also why the cookie-consent rules apply to your landing page rather than to the scan.

Does a QR code campaign need a privacy policy?

Yes, if the landing page collects any personal data or sets non-essential cookies, which most do. Articles 13 and 14 of the GDPR require a privacy notice at the point of collection, telling people what you gather, why, your lawful basis, how long you keep it, and their rights. A clear link to it from the landing page is the norm.

Do I need a data processing agreement with my QR code provider?

Yes, if the provider processes scan data on your behalf, which a tracked-QR provider does. Article 28 of the GDPR requires a written data processing agreement between you (the controller, or your client's processor) and the provider (the processor or sub-processor). Reputable providers offer one as standard; if yours cannot, treat that as a red flag.

The short version

A QR code is not a privacy risk. The pattern on the wall stores a link and collects nothing, and a static code logs nothing at all. Tracking lives in two places behind a dynamic code: the redirect, which logs the scan request (treat those IP addresses as personal data, lean on legitimate interest, and you usually need no cookie banner), and the landing page, which is where cookies, analytics and pixels live and where consent is required. Keep the two straight and most of the confusion in this area simply disappears.

To run a tracked campaign cleanly: pick a provider that aggregates by default and hosts in the EU, truncate the IP, write a privacy notice for the landing page, gate any marketing tags behind real consent, sign a data processing agreement, and set a retention limit. That is a short list, and none of it slows the campaign down. Do it once, build it into your template, and you can give the client the answer they actually want: yes, we measure this, and yes, it is done properly. Then print the code.