The information you put inside a QR code is rarely innocuous. WiFi credentials, vCards with private phone numbers and home addresses, payment links, internal URLs, the destination of a marketing campaign that has not been announced yet — these are the kinds of payloads people generate dozens of times a day, often without thinking about where the data goes. On most online QR generators, it goes to a server. On NoTraQR, it does not. This page explains the technical reason behind that difference, the business model that makes it tempting for competing services to keep your input around, and a verification you can run in your own browser in under a minute.
What "online QR generator" usually means
Almost every popular QR generator works the same way under the hood. You type your input into a form. When you press Generate, your browser sends that input — the URL, the WiFi password, the vCard — to the generator's server as part of an HTTP request. The server runs the QR encoding logic, renders an image, and sends it back. The generator's website happens to be the front end; the actual generation is server-side.
That has two practical consequences. Firstly, your input is necessarily logged somewhere. Even services that promise not to keep it have to receive it, parse it, write it to a request log for at least a few seconds, and pass it through whatever cloud platform they run on. The data has, at minimum, briefly existed on hardware you do not control.
Secondly, the operator can do anything they like with it. Reputable generators delete request logs quickly; less reputable ones retain inputs as a marketing dataset, sell them as "trends" reports, or use them as raw material for analytics. There is rarely any way for a user to verify which kind of operator they are dealing with — the difference is invisible from the outside.
The shady-redirect business model
A second category of competing services is more aggressive. They generate what they advertise as a "dynamic" or "trackable" QR code. What this means in practice is that the QR pattern does not encode the URL you typed. It encodes a redirect URL controlled by the generator's server. When somebody scans the code, their phone first hits the generator's domain, which logs the scan and only then forwards the user to your real destination.
For paying customers, this is a feature: it provides scan analytics and lets you change the destination after the QR has already been printed. For users who choose the "free" option, it is a problem. The redirect is hosted by a third party. If that party goes out of business, raises prices, decides to change their policy, or simply wants to push users onto a paid plan, your printed QR code stops working — or, worse, redirects to a parking page or an unrelated landing page. Several open-source forums and blog posts describe exactly this scenario, where users discovered their printed business cards or product packaging had been silently broken months after a free trial expired.
NoTraQR does not generate dynamic QR codes by design. Every code is static: the destination — the URL, the WiFi credentials, the vCard — is encoded directly into the pattern of dark and light modules. The QR code in your hand is permanent. There is no redirect, no expiry, no tracker, and no third party between the scanner and the destination.
How NoTraQR is different
Open NoTraQR in your browser and you receive a single HTML page, some CSS, a JavaScript implementation of the QR specification, and the icons and fonts you would expect on any modern site. From that point on, everything that happens when you generate a QR code happens locally:
- Your input — URL, WiFi password, vCard fields, GPS coordinates — stays in the memory of your browser tab.
- The QR encoder is JavaScript that runs on your device's processor.
- The output image (PNG, SVG or STL) is constructed as a Blob inside your browser and downloaded directly. It does not pass through any server first.
- The encoder is deterministic: the same input always produces the same code, regardless of when or where it is generated. There is no version of "your" QR that lives on a third-party server.
The technical foundation that makes this possible is described in detail in QR codes explained: because the QR specification is fully published as an open standard (ISO/IEC 18004), there is no proprietary algorithm that has to be guarded behind a server. The encoder can ship to your browser as plain JavaScript. The right design choice — running it locally — is also the simplest one.
Verify it yourself in DevTools
You do not have to take the previous section on trust. You can confirm in your own browser, in under a minute, that NoTraQR does not transmit your QR payload to any server.
- Open NoTraQR in Chrome, Edge, Firefox or Safari on a desktop or laptop.
- Press F12 (or right-click anywhere and choose Inspect) to open the developer tools, then switch to the Network tab.
- Click the Clear button (often a circle-with-a-slash icon) so the request list is empty.
- Optional: tick the Preserve log checkbox so requests stay visible if the page reloads.
- Type something distinctive into one of the QR forms — a phrase like
NOTRAQR-NETWORK-CHECK-12345works well — and click Generate. - Look at the request list. You will see entries for the AdSense advertisement loading from
googlesyndication.com, possibly some font and analytics requests, and a single small request to NoTraQR's anonymous counter. Filter the list for your distinctive phrase. There will be no match. Your input never appears in any outgoing request body or URL.
If you want to be extra thorough, click on each individual request and inspect the Headers and Payload tabs. The QR payload you entered will not appear in any of them. The same holds for the SVG, PNG or STL download: the file is constructed as an in-memory Blob and saved directly, with no upload.
What is sent over the network — honestly
Three categories of traffic do leave your browser when you use NoTraQR. None of them carry the contents of your QR code, but transparency matters more than perfect minimalism, so here is the full list.
Static assets
The HTML page, the JavaScript QR library, the stylesheet, the fonts and the favicon all load from NoTraQR's own server when you first visit the site. These are the same files for every visitor and contain none of your data. After the first load they are cached by your browser, which is why the QR generator continues to work if you go offline after opening it once.
An anonymous +1 counter
When a QR code is generated, NoTraQR sends a single increment to its counter so the homepage can display the running total of codes generated since launch. The request contains no content, no cookies, no identifier, and no information about what you generated. A short-lived hashed IP is used solely to rate-limit automated abuse and is discarded within sixty seconds. The counter exists to show that the service is real and used; it does not retain any record of who generated what.
Google AdSense
NoTraQR displays one Google advertisement on the homepage to cover hosting and domain costs. AdSense loads from Google's own infrastructure and operates under Google's privacy policy. It is the only third-party service active on the site and is fully disclosed in the privacy policy. Crucially, the AdSense traffic is fundamentally different from a tracking generator: AdSense never receives your QR code payload because that payload never leaves your browser tab in the first place. The ad loads independently of whatever you type into the form.
For users in the European Economic Area, NoTraQR uses Google's Funding Choices consent framework, so personalised advertising requires explicit consent in line with the GDPR and the ePrivacy Directive.
Why this matters legally and ethically
The General Data Protection Regulation treats almost everything you put into a QR code as personal data the moment it is associated with a person. A vCard is personal data. A WiFi password belonging to a household is personal data. A URL containing a unique identifier ("share link") is personal data. Sending those values to a third-party server, however briefly, triggers a chain of legal obligations: a data processing agreement, a lawful basis, retention limits, the right of access and erasure, and so on.
NoTraQR's architecture sidesteps that chain entirely for the QR contents. There is no transfer of personal data to NoTraQR for the QR generation step, because the data never leaves the device. From a GDPR perspective, generating a QR code on NoTraQR has the same data-protection profile as opening a calculator app: a local computation on local input.
Ethically, the argument is simpler. People generating QR codes for their own WiFi password, their personal phone number on a vCard, a payment URL, or an internal link in their organisation should not have to trust a stranger's server with that information. They should not have to read a privacy policy, audit a vendor, or worry about a free trial converting into a paywalled redirect. The simplest way to deliver that is to keep the data on their machine in the first place — which is what client-side generation does.
Where this is most relevant
Several specific use cases are particularly sensitive to QR-payload tracking, and are the main reason NoTraQR is built the way it is:
- WiFi credentials. A WiFi password sent to an external server is, in practice, a secret leaked to that server.
- vCards with phone numbers and home addresses. Useful for events and business cards; an unnecessary risk if it is logged on a third-party generator.
- Payment links. QR codes used for payment requests should never depend on a third-party redirect.
- Pre-launch URLs. Marketing campaigns whose landing page is not yet public.
- Internal organisation links. URLs to intranet resources or staff portals that should never be exposed in any external system.
For everyday use cases — a coffee shop menu URL, a personal portfolio link — the privacy risk is small. For the sensitive cases above, it is significant, and a tool that demonstrably keeps the payload local is worth using by default. A short summary of the architecture is on the about page; the full privacy disclosure is in the privacy policy.