Questions people actually ask

Yes and no, in that order. Every content type, every design option and every export format is free, and there is no sign-up step. Codes are generated in your browser.

No. Every code produced here is static: the content is encoded directly in the pattern. Nothing is stored on a server and there is no redirect that could be switched off later.

There is no limit. Generation happens on your device, so there is nothing to meter.

Yes — on packaging, in print, in advertising, in products you sell. No attribution is required.

SVG or PDF for anything that gets printed, because they are vector and stay sharp at any size. PNG for screens and social media. JPG only when a file-size limit forces your hand — it has no transparency and can introduce compression artefacts around module edges.

A logo covers data modules, so the code needs more redundancy to survive. Adding a logo raises the level to H, which lets roughly 30% of the code be obscured and still decode.

Contrast, then quiet zone, then logo size, in that order. Those three account for the large majority of failures. There is a full checklist in our troubleshooting guide.

Yes, under Set colors. Transparent backgrounds only survive in PNG, WEBP and SVG — JPG and PDF will fill the background with white.

No. A static code points directly at your content, so a scan never touches our infrastructure. We could not count scans even if we wanted to.

No. Encoding and rendering run entirely in your browser. Logos you upload are read locally and embedded into the SVG on your device.

Yes. A single GET or POST endpoint returns SVG or PNG with the same design options as the web interface. See the API documentation for parameters and examples.

Q is a good default. Use H when you supply a logo, and drop to M or L only when the payload is long and the code would otherwise become too dense to print at your target size.