Making one QR code takes twenty seconds. Making two hundred, one at a time, in a tool built for one at a time, takes a morning and produces at least three files named qr-code (7).png that nobody can identify later.
The problem isn't generation. It's naming, labeling, and laying them out for print.
What bulk generation should give you
Three things, and most free tools give you one:
Named files. A ZIP where every file is named after the thing it points to, not qrcode1 through qrcode200. If you have to open a file to know which asset it belongs to, the batch was useless.
Captions on the artwork. A QR code on an inventory tag with no human-readable label is a bad tag. Somebody will need to read it without a phone eventually, usually while standing on a ladder.
A print sheet. Codes laid out at a specified physical size on a specified paper size, with gaps and trim lines, ready to cut. This is the step people underestimate. Dropping 200 individual PNGs into a Word document by hand is worse than generating them one at a time.
The workflow
In QR Studio, design one code the way you want all of them to look. Colors, module shape, logo, frame, error correction. Everything you set carries across the whole batch.
Then open batch mode and paste your list, one per line. Two formats work:
https://example.com/asset/1001
https://example.com/asset/1002
Or with labels, which is what you usually want:
Bay 3 Compressor, https://example.com/asset/1001
Loading Dock Camera, https://example.com/asset/1002
Break Room Printer, https://example.com/asset/1003
The label before the comma becomes the filename and the printed caption. The part after is what the code encodes.
From there you get two exports.
ZIP export gives you every code as a separate file, named from its label, at whatever PNG size you set, with SVGs alongside if you check that box. This is what you want when the codes are going into a spreadsheet, a CMS, a product database, or a designer's layout file.
Print sheet lays them out on paper. You set paper size, code size in inches, and the gap between them. Toggle captions on so each code prints with its label underneath. Toggle trim lines on so whoever's cutting has something to follow. Copies lets you print multiples of each, useful when every table needs four identical tents.
Getting the size right on a sheet
The code size setting is the physical printed width, and it's the number that decides whether the batch works.
Remember the ten-to-one rule: scan distance divided by ten. Asset tags scanned from a foot away need about 1.2 inches. Table numbers scanned from a seated position need about 1.5. Shelf labels scanned from an aisle need more than people expect.
Then check density. If your URLs are long, the codes have more modules and each module is smaller at the same width. A batch of 60-character URLs at 0.75 inches will fail across the board, and it'll fail consistently, which at least makes it easy to diagnose.
If your destinations are long, shorten them at the source before generating. It's the cheapest reliability improvement available.
Where bulk batches actually get used
Inventory and asset tags. Every machine, laptop, or fixture gets a code pointing at its record. Labels underneath so a human can read the tag without a phone.
Restaurant table numbers. Table 1 through 24, each pointing at an ordering page with the table baked into the URL. Print sheet with four copies each, cut, laminate.
Event badges and check-in. One code per attendee. ZIP export named by attendee so the badge design pulls the right file automatically in a merge.
Rental and property units. Each unit gets a code linking to maintenance requests or the manual for whatever's in the room.
Classroom and library items. Book carts, equipment bins, checkout stations.
Product labels for a small run. Each SKU pointing at its own page. If you're doing this on packaging you can't easily reprint, make them dynamic first.
Static or dynamic for a batch?
Static works when the destination is genuinely permanent and structured. An asset URL like /asset/1001 that your own system controls is safe, because if you migrate systems you can add a redirect on your own domain.
Dynamic is worth it when the codes are expensive to replace, when the destinations belong to a platform you don't control, or when you need to know which tags actually get scanned. That last one is more useful than it sounds for inventory: the tags nobody scans are usually in places nobody goes.
Before you print two hundred of anything
Print one sheet. Cut one code out. Scan it from the real distance, under the real lighting, on the phone the people using it will actually have.
The batch multiplies whatever mistake is in the design. A logo 3 percent too big is an annoyance on one code and a reprint on two hundred.
QR Studio decodes each finished image again before download, at a ladder of sizes with blur applied, so a fragile design gets flagged before it becomes a stack of paper. That catches most of it. A physical proof catches the rest, and the rest is usually about ink and paper rather than the file.
FAQ
How many codes can I generate at once? Enough for practical batches. Generation happens in your browser, so very large lists depend on your machine more than anything else. A few hundred is routine.
Can I upload a CSV?
Paste works with comma-separated label, value lines, which is what a CSV column pair copies as. Paste directly from your spreadsheet.
Do all the codes share the same design? Yes. Design once, apply to the batch. That's the point.
Is bulk generation free? Yes, for static codes. No account, no watermark, no cap.
Can I batch generate dynamic codes? Dynamic codes are created and managed per code in the dashboard, since each one needs its own short link and tracking record.
What file format should I use? SVG for print, PNG for screens and digital systems. The ZIP export can include both.
Paste your list at gmqr.dev and export the sheet.