Client-side vs server-side QR generation, and why it matters

If a QR generator renders the image on its server, your data — including WiFi passwords, contact details and payment identifiers — is transmitted to and processed by that server. Client-side generation keeps it on your device, which is the only version that is private by construction.

What "generated on our servers" means for your data

To render an image server-side, the generator must receive your payload. For a URL that is usually harmless. For other types it is not:

Payload	What the server receives
WiFi	Your network name and password
vCard	Name, phone, email, employer, address
UPI / PIX / SEPA	Your payment identifier and bank details
Calendar	Where you will be, and when
Email / SMS	Your address and the message

Whether it is logged, retained or shared is a policy question you cannot verify from outside. The only structural answer is not to send it.

Client-side generation

The QR encoder is a few kilobytes of code that runs perfectly well in a browser. Everything — encoding, styling, rasterising, exporting — can happen on the device, with the payload never crossing the network.

UseQR does this for all static codes. There is no server request to generate, which is also why the site keeps working offline after the first load.

The URL is a second leak most tools miss

Many generators keep state in the page URL so it can be shared. That is convenient, and it means the payload ends up in browser history, in Referer headers to any third-party resource on the page, and in any analytics that record page paths.

UseQR keeps tool state in the URL deliberately — it is what lets you share a prefilled editor link — but excludes secrets. WiFi passwords are marked private and never enter the URL.

How to tell what a generator is doing

Open the browser's network tab and generate a code. If a request goes out carrying your payload, it is server-side.
Turn off your network connection and try to generate. A client-side tool still works.
Look at the image URL. If it is something like /api/qr?data=YOUR-PASSWORD, your payload went over the wire and is probably in a server log.

When server-side is fine

For a plain public URL there is little to protect, and a server-rendered image is often more convenient — it is exactly what our own keyless API provides. The distinction matters when the payload is a credential, a contact record or a payment identifier.

FAQ

Is it safe to make a WiFi QR code online?

Only with a generator that builds the code in your browser. A server-side generator receives your network name and password in plain text, and you cannot verify what happens to them.

How do I know if a QR generator sends my data to its server?

Disconnect from the network and try to generate a code. A client-side tool still works. You can also watch the browser's network tab for a request carrying your payload.

Does UseQR see my data?

No. Static codes are generated entirely in your browser and nothing is sent to us. WiFi passwords are additionally excluded from the page URL so they never reach browser history or referrer headers.

Is the keyless API also private?

No — an API call necessarily sends the payload to a server. Use the API for public data such as URLs, and the in-browser tools for credentials and contact details.