How I use a CSV to make bulk QR codes

Bulk QR code generation is mostly a spreadsheet problem. If the CSV is clean, the QR codes are boring to create. If the CSV is messy, every downstream file name, destination, and print proof becomes suspect.

I use a small CSV with one row per QR code, then generate the batch from that file. Nothing fancy. The discipline is in the columns.

The CSV columns I use

Keep the batch readable before generating anything

• `name` for the campaign, location, asset, or person.
• `url` for the destination that goes into the QR code.
• `file_name` for the exported PNG or SVG.
• `notes` for internal context, if the generator supports it.

The minimum is a name and a URL. I still like a file name column because exported files need to be usable by designers, printers, and clients. `downtown-lunch-menu.png` beats `qr-17.png` every time.

I keep the columns boring on purpose. Extra columns feel helpful during planning, but they make imports easier to misunderstand. If the generator only needs a destination and a name, I do not add five optional columns unless those fields will be used immediately.

For agencies, I usually add client or location context to the name: Orchard menu, Orchard review card, Katong appointment QR. The extra words save time when someone asks for one code out of a batch months later.

For multi-location work, I sort the CSV by location before export. That makes the exported folder easier to compare against the print layout. If the designer is placing codes by branch, the file order should match how the job is reviewed.

CSV formatting details that matter

Commas and line breaks are where batches break

CSV looks simple until a field contains a comma, quote, or line break. RFC 4180 documents the common CSV format and registers the `text/csv` media type. Its rules cover headers, records, fields, and quoted fields.

My practical rule: export the CSV from a spreadsheet app and do not hand-edit complicated rows unless I have to. If a business name contains a comma, the field should be quoted. If a quote appears inside a quoted field, it needs to be escaped correctly.

I also avoid putting long notes, pasted email threads, or multi-line instructions into the upload file. The CSV should describe the QR batch, not become the project archive.

Character encoding is another quiet source of mistakes. I check names with accents, apostrophes, ampersands, and non-English characters before exporting a final batch. If those names only appear in file names, I simplify them. If they appear in campaign names, I keep them readable and verify the import result.

Validate before generating

Bad rows should fail early

• Every row needs a destination URL.
• Every URL should include `https://` unless there is a specific reason not to.
• File names should be unique after cleanup.
• Empty rows should be removed.
• Duplicate destinations should be intentional, not accidental.

I want the generator to show bad rows before it creates files. Fixing a CSV is cheaper than matching broken codes to print artwork after export.

For web uploads, I still treat the browser file picker as convenience, not validation. The W3C File API describes how web apps receive file objects from file inputs. The server or app still has to parse and validate the contents.

The error report should point back to row numbers. A message like `Row 14 has an invalid URL` is useful. A message like `Import failed` sends everyone back to manual inspection. For client work, I keep the corrected CSV next to the exported QR folder so the batch can be regenerated later.

I also check for rows that are technically valid but suspicious. A URL with a private staging domain, a file name that says `draft`, or a destination that opens a login screen may pass syntax validation and still be wrong for print.

Static or dynamic for bulk batches

The answer depends on who maintains the list

Static bulk generation is fine for stable URLs: branch homepages, permanent staff pages, one-off event links, or internal labels. The CSV URL goes into each QR code, and the exported files are ready for print.

Dynamic bulk generation is better when destinations change. A restaurant group may update menu PDFs. A property manager may swap listing videos. An agency may need to fix a client's landing page after the posters are already printed.

For dynamic batches, the CSV often describes the campaign name and first destination. The generated QR code points to a stable short link, then the destination can be edited later inside the campaign dashboard.

Dynamic batches need one more ownership check. If the agency creates 80 codes for a client, someone needs to know who can edit those destinations later. The answer should be clear before the posters, table cards, or stickers are printed.

Keep URLs short when possible

Dense codes are harder to print small

DENSO WAVE documents that QR code capacity depends on the symbol version, data type, and error correction level. More data means more modules. Long URLs with tracking parameters can make the QR code denser than it needs to be.

For bulk batches, I strip unnecessary tracking parameters before generating static codes. If analytics are needed, I use dynamic links instead of stuffing every tracking detail into the printed symbol.

This matters most on small labels, receipts, stickers, badges, and business cards. A code that scans on a large monitor can still fail when it is printed at 18 mm on textured stock.

I also avoid mixing URL styles in the same batch. If half the rows use full campaign URLs and half use short links, the printed QR codes may have noticeably different densities. That can look sloppy on a sheet of labels and it makes proofing harder.

Export files printers can use

Names and formats save the handoff

The export should match the next person in the workflow. Designers usually want clearly named files. Printers may ask for vector files or high-resolution PNGs. The business owner wants enough context to know which code belongs to which location.

I avoid clever naming. Lowercase words, hyphens, and a short location or campaign name are enough. If the QR code is tied to a physical asset, I include that asset in the name: `orchard-window-decal`, `downtown-receipt`, `katong-table-card`.

If the export includes a ZIP file, I open it before sending it on. I check that the expected count matches the CSV row count, that no files were overwritten by duplicate names, and that the file extensions match what the printer or designer asked for.

My batch proof

Spot-checking is not enough for small batches

For a batch of 10 or 20, I scan every code before print. For a larger batch, I scan representative samples and any row that looks unusual: long URL, special characters, non-English text, duplicate name, or custom file name.

I also open the exported folder and sort by file name. Missing numbers, duplicate names, and weird characters show up quickly there. That check catches boring mistakes before the designer places the wrong file.

For print proofs, I write the campaign name or file name next to the QR code in the proof sheet. Then I can scan a code and compare the opened destination to the label beside it. Without that label, a batch proof turns into guessing from thumbnails.

The workflow is simple: clean CSV, validate rows, generate codes, inspect file names, scan printed proofs. Bulk generation should save time without making mistakes harder to see.