Understanding bulk QR generation
A list in, a zip of PNGs out.
What changes when you generate hundreds of QR codes instead of one, the error- correction levels that matter, and the size that prints reliably.
The job, in one paragraph.
A bulk QR generator takes N input strings (URLs, vcards, plain text) and emits N image files, named systematically, zipped for download. Each QR encoding is independent; the bulk operation is "run the generator in a loop, zip the results". Common use cases: event check-in (one QR per guest), inventory labels (one QR per product), payment requests (one QR per invoice), marketing campaigns (one QR per print location for analytics).
Error correction — pick L, M, Q, or H.
QR encodes with one of four error-correction levels. L recovers ~7 % of damaged data, M ~15 %, Q ~25 %, H ~30 %. Higher correction means more bits devoted to error recovery, which means a larger QR pattern for the same payload. For pristine screen-rendered QRs, L is fine. For printed QRs that might get smudged, scratched, or partially obscured by a logo overlay, M or Q is the realistic default. H is the right choice when you want to embed a logo in the centre of the code — the corrected bits make the logo tolerated.
Module size and print quality.
A "module" is one square of the QR. Phone cameras need at least 2-3 pixels per module to scan reliably, which translates roughly to "the smallest QR should be 2cm × 2cm at standard print resolution". Below that, scans start failing. For business cards, 1.5cm minimum; for posters, 5cm minimum; for warehouse labels, 3cm minimum (the camera distance is greater). Bulk generators should let you pick the output size in cm and emit at the right pixel resolution for the target printer.
A worked batch.
200 unique event-check-in URLs (https://event.com/check-in/<token>), each token a 16-char NanoID. Generate at 5cm × 5cm print size, error correction M, output as 300 DPI PNGs. Per QR: ~600×600 pixels, ~5 KB. 200 QRs = 1 MB total, zipped to ~300 KB. Naming: checkin-001.png through checkin-200.png. Match a CSV of tokens to filenames so the printer can collate.
200 print-ready QRs
5cm at 300 DPI, error M
One pass per row; zip the lot.
200 inputs → 200 600×600 PNGs → 300KB zip
= Print-shop-ready
The static-vs-dynamic distinction.
A QR encodes the literal string you give it. Once printed, you can't change it. "Dynamic QR" services solve this by encoding a short redirector URL — the QR points at qr.example/abc123, the service redirects to your real destination, and you can change the destination later in their dashboard. Useful for posters that need a destination change mid-campaign. The trade-off: dependency on the service, slower scan (extra HTTP hop), analytics collected by them. For most bulk operations, static QRs are simpler.
Payload limits.
QR versions 1-40 scale capacity from ~25 to ~4000 alphanumeric chars (about half that for binary). Most generators auto-pick the smallest version that fits the input. For long payloads (a long URL with tracking params), the QR gets denser and harder to scan. The fix: shorten the URL before encoding. example.com/?utm_source=...&id=42 becomesexample.com/q/abc123 via a redirector; the QR encodes the short form, the redirector reconstructs the long.