QR Codes and GDPR: What Gets Collected and What to Say About It

Most articles on this subject are vague because most QR services are vague about what they collect. This one lists the fields.

It is not legal advice. It describes what the software does. Whether your particular use needs a consent banner, a notice line or a data processing agreement is a question for your own lawyer or data protection officer, and the answer depends on your sector and country as much as on the technology.

Exactly what a scan records

When someone scans a dynamic code, one row is written before the redirect. It contains:

• The time of the scan.
• The code that was scanned.
• Device type — mobile, tablet or desktop.
• Operating system and browser, as reported by the user agent.
• Referrer, if the browser sent one. A camera scan usually sends nothing.
• A hash of the IP address — SHA-256 over a secret salt plus the address. It exists to count unique visitors and is not stored alongside the address itself.

That is the whole row. There is no name, no email, no advertising identifier, and no link to any other website's activity.

What is deliberately not collected

• Location. There is no geolocation in the analytics at all — not country, not city, not coordinates. Many services derive a country from the IP address; this one does not, so "which city scanned this" is a question the dashboard cannot answer.
• Cookies on the redirect. Following a scan sets no cookie. The single exception is a password-protected code, where unlocking sets a functional cookie that remembers you got the password right — nothing else uses it.
• Identity. The counters cannot tell you who scanned. If you want to know that, the destination page has to ask, and then it is your form and your privacy notice.

The honest part about the IP hash

An IP address is personal data under GDPR. Hashing it with a secret salt is pseudonymisation, not anonymisation: the value cannot be read back into an address, and it is deliberately useless for looking anyone up, but it is a stable identifier for one visitor over time, which is what makes unique-visitor counts possible in the first place.

We would rather say that plainly than claim the data is anonymous. What it does mean in practice: an analytics table that could not identify a person even if it were handed to someone.

The moment your obligations grow: pixels

A code can carry Meta, Google Ads or LinkedIn retargeting pixels. This is the one feature that puts third-party tracking into the path of a scan, and it changes the picture completely — those companies do build profiles.

Because of that, pixels here are consent-gated. A code with pixels shows a brief interstitial with a consent choice, the pixels fire only after the visitor accepts, and the answer is remembered in the browser's local storage. If consent was refused or never given, the visitor is redirected and nothing fires.

That is the mechanism. Whether the wording of your banner is adequate for your jurisdiction is exactly the kind of question to put to your lawyer — and if you have no need for retargeting, leaving the pixels empty is the simplest privacy decision available to you.

Who is the controller?

The usual arrangement for a service like this is that you are the controller of the scan data for your codes — you decide the codes exist and what to do with the numbers — and the service is a processor acting on your instructions. Enterprise customers normally want that recorded in a data processing agreement.

We are describing the common arrangement, not certifying yours. Confirm it with your own advisers, particularly if you operate in a regulated sector.

What to put in your privacy notice

A line or two usually covers it. What tends to belong there:

• That scanning a code records the scan for statistical purposes, and roughly which technical fields — time, device, operating system, browser, referrer, a hashed IP.
• That no location data is collected.
• That the visitor is then redirected, and the destination has its own notice.
• If you enabled pixels: who receives the data and what the consent choice does.

Write it in the same language as the code's audience. Six privacy notices in six locales is a chore; a wrong one in the reader's language is worse than a plain one.

The trap that has nothing to do with analytics

The biggest privacy mistake with QR codes is not tracking. It is encoding personal data into a static code.

A static code carries its content inside the pattern. Print a vCard with someone's mobile number onto five thousand leaflets and that number is in circulation permanently — it cannot be edited, revoked or withdrawn, and an erasure request cannot reach paper. The same goes for a static code containing a private booking URL or a customer reference.

If personal data has to be behind a code, put it behind a dynamic one, where the destination can be changed or switched off, and keep the data on a page you control.

Deleting things

Deleting a code deletes its scan rows with it — that relationship cascades in the database, so there is no orphaned analytics history left behind. If you need a retention period shorter than "until I delete the code", that is a decision to make deliberately rather than assume.

Quick answers

• Does scanning a QR code collect personal data? Here it records device, OS, browser, referrer, time and a salted hash of the IP. The IP hash is pseudonymised personal data; the rest is technical.
• Do you record where the scan happened? No. There is no geolocation in the analytics at all.
• Do I need a cookie banner for a QR code? The redirect itself sets no cookies. Retargeting pixels are consent-gated. Whether your case needs a banner is a legal question, not a technical one.
• Am I the controller? Typically yes for your codes' scan data, with the service as processor. Have your advisers confirm it.
• Can I put someone's contact details in a QR code? Not in a static one — it is permanent once printed. Use a dynamic code and a page you can change.
• What happens to the data if I delete a code? Its scan records are deleted with it.

Again: this describes the software, not your legal position. For the legal position, ask someone qualified to give it.