What your QR code provider can see

Three windows into your data

A QR provider can observe you at three distinct moments: when you create a code, every time someone scans it, and through the account you hold. Most privacy discussion focuses on scanning. The creation window is the one almost nobody considers, and it is often the worst.

At creation — the window nobody thinks about

If the generator renders the image on its server, your payload travels there first. Type a WiFi password into a server-side form and the request looks something like:

GET /api/qr?data=WIFI%3AT%3AWPA%3BS%3AShopFloor%3BP%3Ahunter2%3B%3B

Default web server access-log formats record the full request URL, query string included, alongside your IP address and a timestamp. No one has to decide to collect your password; the standard configuration already does. Those logs are then routinely shipped to third-party logging and analytics platforms, multiplying the copies. The full comparison of architectures is in client-side vs server-side generation; the point here is what lands in the log: your network credentials from a WiFi code, your full contact record from a vCard, your payment identifier, your private event details.

At scan — dynamic providers only

A static code, once created, involves the provider in nothing further. A dynamic code routes every scan through the provider's redirect server, which can log the scanner's IP, device and timestamp — covered in detail in dynamic QR codes and privacy and what is actually logged.

At account level

Providers that require signup hold a third layer: your email address, name, billing details, and — more subtly — the association of every code with you. The provider knows that one identifiable person created the WiFi code, the vCard and the payment code, which is a profile none of the individual payloads reveals alone.

What a client-side generator sees — nothing

When the encoder runs in your browser, there is no creation request to log. UseQR works this way for all static codes: the payload never leaves your device, there is no account, and the code is MIT-licensed open source, so the claim is inspectable rather than promissory. Two checks anyone can run:

1. Open the browser's network tab, generate a code, and confirm no request carries your payload.
2. Switch on airplane mode and generate again. A client-side tool still works.

Questions to ask any generator

• Where does encoding happen — my browser or your server?
• Is the source code public, so the answer can be verified?
• Do I need an account, and what does it link together?
• If the code is dynamic, what is logged per scan and for how long?
• Does my payload appear in the page URL, where browser history and referrer headers can pick it up?

FAQ

Do QR code generators keep your data?

Server-side generators receive your payload in order to render the image, and standard server logging records the request by default. Whether it is retained beyond the logs is a policy question you cannot verify from outside. Client-side generators never receive the payload at all.

Can a QR generator see my WiFi password?

If it renders codes on its server, yes — the password is transmitted as part of the payload. This is exactly the case examined in why not to upload a WiFi password to a website, and the reason to use a client-side tool for credentials.

How do I check what a QR generator sends?

Open your browser's developer tools, watch the network tab while generating, and look for any request containing your data. Then try generating in airplane mode — a tool that keeps working provably sent nothing.

Does UseQR see the codes I make?

No. Static codes are generated entirely in your browser, with no account and no server request. The exception is the keyless API, which necessarily receives the payload — use it for public data like URLs, not credentials.