# 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.

Source: https://useqr.app/docs/security/client-side-vs-server-side-qr-generation · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## 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

1. Open the browser's network tab and generate a code. If a request goes out carrying your
   payload, it is server-side.
2. Turn off your network connection and try to generate. A client-side tool still works.
3. 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](/developers) 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.

## Try it

- https://useqr.app/wifi
- https://useqr.app/vcard
- https://useqr.app/upi