A QR code generator that doesn’t want anything from you.
kemek/qr is a free utility from KeMeK Network. It runs entirely in your browser — no upload, no account, no expiry, no tracking. This page explains exactly what that means and where the limits are.
What kemek/qr is
A static-page web app for generating QR codes. You pick a content type (URL, plain text, WiFi credentials, vCard contact, mailto:, SMS, tel:, geo:), tune the styling, and download a print-ready PNG, SVG, or PDF. The generator and every export run in your browser — there is no backend involved at any step.
"Static" here means the QR encodes its destination directly. There is no shortener, no redirect server, nothing tracking the scan. A static URL QR works for as long as the URL itself works; a static WiFi QR works as long as the network credentials match. None of these can be edited after the fact — to change the destination you regenerate the QR.
The generator is a single SvelteKit app, prerendered to static HTML and bundled JavaScript. Cloudflare Pages serves the artifact; Cloudflare touches no request payloads beyond standard CDN logging.
What we don’t do
No client-side analytics, no tracking scripts. No Google Analytics, no Plausible, no Umami — anything that injects a script tag and pings a server while you generate. We see what our host sees — aggregate pageview counts, no individual tracking, no cookies, no third-party scripts.
No third-party assets. Fonts (Fraunces and JetBrains Mono) are bundled locally via npm packages, not loaded from Google Fonts. There is no CDN-hosted JavaScript, no embed scripts, no tracking pixels.
No signup, no account, no email gate. Every feature is free at the same point: open the page, generate the code, download. Permalinks (the COPY LINK button on each generator) encode every setting into the URL hash so you can share or bookmark a configured QR without an account.
No dynamic QRs, no scan analytics. Editable destinations and per-scan analytics require a server-side redirect, which would mean accounts, hosted endpoints, and tracking by construction. That is a different product. If you need it, choose a SaaS QR provider — there are many.
How your data flows
Anything you type into a form (URL, WiFi password, contact name, etc.) stays in the browser tab. It is not sent over the wire. The QR image is rendered locally by a JavaScript library (qr-code-styling) and the file you download comes out of the same tab.
If you upload a logo to embed in the QR, the file is read with the browser’s built-in FileReader, kept in memory, and composited into the output. It is never uploaded
anywhere.
Your last inputs persist between sessions via localStorage on the same device — also local, also under your control. Clearing
site data clears the saved session. Loading a permalink (a URL with a #s=… hash) overrides
the saved session for that visit.
License & source
The kemek/qr source is on GitHub under the MIT license. Read the code, fork it, run your own copy if you’d prefer. The privacy claims on this page reduce to "we ship no telemetry code"; the source is the proof.
kemek/qr is part of the KeMeK Network family of utilities. KeMeK Network builds privacy-first, local-first tools and full-stack apps — each one drawn to spec, opinionated in design, and built for the common good.
Error correction & scan reliability
Every QR code carries redundant data so the code still scans when part of it is damaged, smudged, scratched, or partially obscured. The redundancy level is called error correction and the spec defines four of them — L, M, Q, H — recovering roughly 7%, 15%, 25%, and 30% of the code respectively. Higher levels survive more damage but make the code denser (more modules in the same data) so dense codes at very small print sizes can be harder for cheap cameras to read. M is the everyday default for most uses.
The AUTO setting in the generator picks M as the everyday-default baseline and H when a logo is embedded. For short payloads — most URLs, contact rows, brief text — AUTO quietly takes the stronger Q or H level when it fits in the same minimum version M would land on, free recovery margin at no module-count cost. The logo case stays at H because the logo physically obscures part of the data region and H builds enough redundancy to reconstruct the obscured cells at scan time. If you're embedding a logo at the default 25% size, AUTO is almost always the right call. Manual override is there for the cases AUTO doesn't anticipate.
Reach for Q if the code will be printed on something that sees real-world wear — sticker on a delivery box, label on outdoor signage, business card that lives in a wallet. The extra recovery margin pays for itself in scan success. Reach for H when you want a logo and a margin of safety on top, or for industrial-environment placements (workshop walls, construction sites) where scratches and dust are a given.
Error correction is only half the scan-reliability story. The other half is contrast — the foreground/background combination must be readable by a
camera. The convention is dark-on-light (most decoders assume it). The picker shows a live CONTRAST n.n:1 readout — anything below 3:1 is flagged as LOW; foreground brighter
than background is flagged as INVERTED. It's informational, not a gate: we trust you to ship what
you mean. But if your scans fail in real-world lighting, contrast is the first thing to check.
Size matters too. A QR code shrunk too small relative to the scanning distance won't resolve. Rule of thumb: the smallest visible square (a single module) should be at least 0.4 mm at the viewer's eye-distance for reliable scanning. For arm's-length scans (palm-sized prints), the code itself should be at least 2 cm × 2 cm. For across-the-room scans (poster on a wall), scale up proportionally.