MakeaURLQRcodewithoutsendinganythinganywhere

Server-side against browser-side

A server-side generator has to receive your payload to draw the pattern. That is not a criticism of any particular service — it is what the architecture requires. It means what you typed exists, however briefly, on hardware you do not control.

A browser-based generator loads the encoder into the page and does the work with your own processor. What you type is read by the tab you already have open, turned into a matrix in memory, and handed back as a download. There is no endpoint it could be sent to.

Even for a plain payload the principle holds: there is no reason for a third party to receive it in order to draw a square.

The ten-second proof

Load this page, turn off your Wi-Fi, and make a URL QR code anyway. It works, because everything it needs is already in the tab.

No privacy policy can demonstrate that. It is the one claim in this whole category you can verify yourself without taking anybody's word for anything.

What the scan needs

The code encodes the full web address, character for character, so a phone reads it instantly offline but needs a connection to open the destination.

Nothing about that involves us. There is no redirect through our domain, which is why the code has no dependency on this site continuing to exist.

Where this matters most

• Wi-Fi passwords, which should not be typed into a third-party form under any circumstances.
• Payment identifiers — a UPI ID or a wallet address, where a substituted character sends money to a stranger.
• Staff and client contact details, which are somebody else's data and not yours to upload.
• Anything made on a client's behalf, where sending it to a third party is a decision you are making for them.

If your organisation has a policy about where data may be processed, this is the version of the tool that satisfies it.