Privacy Policy

UseQR is a free tool maintained by Raj Karia. There is no company behind it and no support desk. For anything in this policy, the contact route is the maintainer, by email, or a private security advisory for anything sensitive. We have deliberately not printed an email address rather than print one nobody reads.

This is not a marketing line, it is an architectural fact, and it is checkable. There is no user table because there is no database. There is no session because there is no login. There is no key-value store, no object storage and no queue in this application.

• No accounts. No email address, no password, no profile, not even an optional one.
• No analytics. There is not a single analytics dependency in this project. You can verify that in your browser’s network tab without taking our word for it.
• No cookies. UseQR sets no cookies at all, first-party or third-party. Nothing here requires consent, so nothing asks for it.
• No third-party scripts beyond the web fonts that load with the page. No ad network, no tracker, no chat widget, no A/B tool.
• No selling or sharing. There is no data to sell, and none is shared with anyone for advertising or any other purpose.

A few things are written to your own browser so the tools behave sensibly. They live on your device, they are readable only by this site, and no code in UseQR reads them and sends them anywhere.

• useqr-theme Local storage. Holds the single word light or dark when you use the theme toggle, so the page does not flash the wrong colours on your next visit.
• useqr-scan-history Local storage. Holds up to your 20 most recent decodes on /scan so you can copy one again later. Remove it at any time with the Clear button beside “Recent scans”, which erases the list immediately and completely.
• An offline cache. A service worker stores pages and build assets in your browser’s Cache Storage so the generator keeps working with no connection. It never caches API responses, and it holds only the same public files anyone else would download.
• Camera frames are not stored at all. When you scan with a camera, frames are drawn to an in-memory canvas, read by a decoder compiled to WebAssembly, and discarded. No frame is uploaded, written to disk, or kept after the next frame replaces it. Stopping the camera releases it.

To remove all of it at once, clear site data for useqr.app in your browser settings. We cannot do this for you and we cannot see it, which is the point.

Every static QR code on this site: URL, text, WiFi, vCard, UPI, PIX, EPC, crypto and the rest: is encoded, rendered and decode-verified inside your browser. There is no upload step. There is no “generating…” round trip. Open your browser’s network tab while you type a WiFi password into the generator and you will see no request carrying it, because none is made.

The same applies to the scanner, the validator, the bulk CSV generator and the sticker sheet builder. Files you drop in are read locally; nothing is posted.

This is the detail most privacy policies would quietly skip, so here it is plainly. The generator mirrors your current configuration into the page URL so that a design is shareable and reproducible. That happens locally with a history replace: typing does not cause a network request.

But a URL is only private until it moves. If you copy that link and open it fresh, or send it to someone, the query string travels inside the HTTP request to our host, the same way any web address does, and can appear in the host’s access logs.

Fields a tool marks private are never written into the URL in the first place. Today that is the password field on the WiFi generator, which is deliberately excluded so a shared link can never carry it. If you are encoding something sensitive, download the image rather than sharing the link.

UseQR is hosted on Vercel. To deliver a page to you, Vercel’s edge network necessarily receives and processes your IP address, the requested path and query string, your user agent, and the other standard headers your browser sends. It uses them to route the request, serve from a cache near you, and to absorb attacks and abusive traffic.

We will not tell you “we log nothing”, because that would be a claim about infrastructure we do not own. What we can state exactly is this: UseQR adds no logging of its own, writes no request records, enriches nothing, and exports nothing anywhere. The platform-level records that exist are Vercel’s, generated as a byproduct of serving and protecting the site, and Vercel acts as our processor for them.

Vercel’s privacy policy and data processing addendum describe what it retains and for how long.

The REST API and MCP server are keyless and stateless. There is no key to issue, so there is no identity attached to a call, no usage record per caller, and no account to correlate. They render a response and return it. Nothing is written down.

The honest trade-off: the API is the hosted path, so whatever you put in data is transmitted to our server to be rendered there. The in-browser generator is the private path. If you can generate a WiFi or payment code in the browser instead of through the API, do that.

Because output is deterministic, API responses are cached aggressively at the CDN edge. An identical request URL can therefore be answered from a shared cache. Treat anything you send through the API as public: do not put a secret in a URL that a cache is designed to keep.

Two features take a URL you supply and fetch it from our infrastructure rather than from your browser: GET/POST /api/v1/decode when called with a url parameter, and the MCP tool qr_decode when given a url.

Two consequences you should know about:

• The URL you pass is transmitted to us, because we need it to make the request. If it contains a token or a private path, we receive it.
• The destination server sees a request from UseQR’s infrastructure, not from you. Your IP address is not disclosed to it; ours is. That is useful for privacy and worth knowing for attribution, from the destination’s point of view, UseQR fetched the image.

The fetched bytes are decoded in memory and the text returned. The image is not stored, cached by us, or logged.

For nearly everything UseQR does there is no personal data at all, so data-protection law simply does not engage. Where it does, this is the framing we rely on:

• Serving the site. The connection metadata a host must process to answer a request (IP address, request line, user agent) is handled under legitimate interests, Article 6(1)(f): delivering the page you asked for and keeping the service available and free from abuse. You can object under Article 21, though in practice the only way to stop a web server receiving your IP is not to make the request.
• Storage on your device. The theme setting and the scan history are strictly necessary to provide a feature you explicitly asked for, which is the exemption in Article 5(3) of the ePrivacy Directive. No consent is required for them, and no consent is required for anything else here because there is nothing else.
• No profiling. There is no automated decision-making, no profiling, and no special-category data processing. We are not capable of it; we do not know who you are.

Under the GDPR and UK GDPR you have rights of access, rectification, erasure, restriction, objection and portability, and the right to complain to your supervisory authority. Under the CCPA and CPRA, California residents have rights to know, delete and correct, and to opt out of the sale or sharing of personal information, UseQR sells and shares nothing, so there is nothing to opt out of.

The practical problem with a service like this one is that there is no account to look up. A subject access request to us would return an empty set, not because we refuse but because no record exists that is keyed to you. So here is what actually works:

• Erasure of everything we could conceivably touch is something you can do yourself in seconds: the Clear button on /scan, or clear site data for useqr.app in your browser. That is complete. There is no server-side copy to chase, because there never was one.
• Platform-level records sit with Vercel under its own retention schedule. We hold no identifier that maps a log line to a person, so we cannot single you out in order to erase you. If you need to pursue that, go to Vercel with the request; contact us via GitHub and we will help where we usefully can.
• Complaints. You may lodge one with your national data protection authority at any time, and you do not need to talk to us first.

UseQR is a general-purpose utility, not a service directed at children, and it is not marketed to them. It collects no personal information from anyone, so it collects none from children either, knowingly or otherwise. There is no age gate because there is no account and nothing to gate.

Vercel serves the site from a global edge network, so the location that answers your request is generally the one closest to you and may be outside your own country, the EEA or the UK. Those transfers are covered by Vercel’s data processing addendum and the standard contractual clauses it incorporates.

UseQR itself transfers nothing, anywhere. There is no export, no backup, no replica and no third-party destination, because there is no data to move.

We will update the date at the top when this page changes, and note anything material in that summary box rather than burying it.

There is no mailing list and no notification channel, and we would rather say that than pretend otherwise: the date above is the thing to check. What will never change is the shape of it: static generation stays in your browser, and there is no analytics dependency to start collecting anything later.

Ask in the email. If a claim on this page is wrong, that is a bug and we want the report, the source is open, so a correction can be a pull request.

Terms of Service → · Security policy → · Report abuse →