How to generate QR codes in bulk: unique, trackable codes at agency scale

One campaign can need a different QR code for every store, every flyer variant, every product line, or every sales rep. Make them one at a time and you will spend an afternoon copying URLs into a generator and downloading files with names like qr (37).png. Worse, you will have no idea later which code went where. Generating QR codes in bulk fixes the volume problem, but only a deliberate setup fixes the part that actually matters to an agency: keeping every code unique, trackable, and fixable after it has gone to print.

This is a guide to doing bulk QR codes properly. We will cover how bulk generation actually works, what serialisation means and when you need it, the handoff to a print shop that quietly breaks most large jobs, and why dynamic codes are close to non-negotiable once you are printing thousands of physical pieces you cannot recall.

The whole job runs in four stages, and the numbered diagram above maps them:

1. Data source. One clean spreadsheet, one row per code, with a destination and a name in every row.
2. Bulk generation. The platform turns that file into a batch of codes in a single pass and hands them back as a set of images.
3. Dynamic redirect. Each code points at a short redirect you control, so any destination can be changed after print.
4. Per-code analytics. Every code reports its own scans, which is the whole reason to give each placement its own code.

What "bulk QR codes" really means

There are two different jobs hiding under the same phrase, and confusing them is where campaigns go wrong.

The first is one design, many copies. You want the same code, the same destination, printed a thousand times. That is not really a bulk-generation problem at all. You make one code and the print run duplicates it. Every scan looks identical in your analytics because every code is identical.

The second is many unique codes. Each printed piece carries a different code that points somewhere specific or is tracked separately: a unique URL per store so you can see which location drives scans, a per-region landing page, a one-code-per-product link, or the same landing page reached through a distinct tracked code so each placement reports on its own. This is the job that needs bulk generation, and it is the one worth getting right.

For agencies, the second job is almost always the point. The reason you put a QR code on a client's campaign is attribution: proving that the bus-stop poster outperformed the in-store shelf talker, or that the Hamburg stores scanned twice as often as Munich. You only get that if each placement carries its own code. A single shared code tells you a campaign happened; a set of unique codes tells you what worked.

How bulk generation works

Almost every bulk tool follows the same shape, so once you have done it on one platform you have done it on all of them.

1. Download the platform's CSV or spreadsheet template.
2. Fill in one row per code: at minimum a destination URL and a name, plus optional columns for design, frame, or UTM parameters.
3. Upload the file.
4. The platform generates every code and hands you back a ZIP of image files, usually named from your "name" column so you can match each file to its row.

The detail that trips people up is that batch limits are not a property of QR codes, they are a property of your subscription. There is no universal ceiling. To give a sense of the spread from vendors' own documentation: Uniqode (formerly Beaconstac) tiers dynamic-code batches from 15 on its entry plan up to 10,000 on enterprise, and states a 10,000-code batch processes in about a minute. The Bitly-owned QR Code Generator PRO caps a batch at 5 on the trial, 100 on Advanced, and 500 on Professional, and only lets one code type into a batch at a time. QRCodeChimp sets no fixed per-batch number but bounds you by your plan's total code limit and recommends splitting jobs over a few thousand for performance.

The practical lesson: check the batch limit before you build the campaign, not after. If your client needs 4,000 unique codes and your plan caps batches at 500, you are either splitting the job into eight uploads or upgrading. Both are fine; discovering it at deadline is not.

The spreadsheet shortcut, and where it stops

You do not strictly need a paid platform to turn a column of URLs into a column of codes. A spreadsheet formula will do it. In Google Sheets, this renders a QR image straight into the cell from the URL in A2:

=IMAGE("https://quickchart.io/qr?text="&ENCODEURL(A2))

The QuickChart QR endpoint is keyless and free for low volume, and accepts useful parameters: size, margin, ecLevel (L, M, Q or H, defaulting to M), dark and light colours, and format (PNG, SVG or base64). It is a genuinely handy way to eyeball a batch or build a quick proof of concept.

It also stops being free quietly. QuickChart's community tier allows 1,000 codes per month and 60 per minute, which a real campaign of several thousand codes will blow through. And the deeper limit is structural: codes made this way are static. The URL is baked into the image. There is no tracking, and no way to change a destination after print. For a throwaway internal sheet, fine. For a client campaign you are reporting on, it is a dead end. That distinction, static versus dynamic, is the hinge of this whole topic, and we will come back to it.

Serialisation: when each code must be unique

Serialisation is the discipline of making sure every code in a batch carries a value that belongs to one and only one thing. One code per store. One per flyer variant. In retail and pharma, one per physical product unit.

The retail world has a formal version of this worth knowing about, because clients in food, drink, cosmetics or pharma will eventually raise it. Under the GS1 system, a serialised product identifier (an SGTIN) combines a product's GTIN with a unique serial number, and the modern carrier for that identity is increasingly a GS1 Digital Link QR code, a QR that encodes a web URL containing the product's identifiers. If your client is heading toward GS1-compliant packaging, that is its own project, and we cover the packaging angle in our piece on QR codes on product packaging and GS1 Digital Link.

Most agency campaigns do not need full GS1 compliance. What they need is the same underlying habit: a clean source of truth where every row maps to exactly one code, with no accidental duplicates. That usually means a unique slug or token per code rather than reusing one URL with a tweaked label. The spreadsheet that generates your batch is also the spreadsheet that documents your campaign, so treat it as a deliverable, not scratch paper. Name codes consistently (client-campaign-city-placement), keep the destination and any UTM values in their own columns, and that file becomes the map you use to read your analytics three months later.

On capacity, one honest constraint: a long URL with a stack of UTM parameters makes a denser, harder-to-scan code. QR codes hold a lot in principle (up to 4,296 alphanumeric characters at the largest version and lowest error correction), but you do not want to spend that budget on tracking cruft printed at small sizes. Short redirect URLs keep codes clean. We go deeper on this in how much data a QR code can hold.

The print handoff that breaks bulk jobs

Here is the step nobody warns you about. Generating 3,000 unique codes is the easy part. Getting 3,000 different codes onto 3,000 different printed pieces is where jobs fall apart, and the reason is how printing works.

Putting different content on each piece in a run is called variable data printing (VDP). It is a digital-printing technique: the press composes each piece on the fly from a data file. Crucially, you cannot do it on a traditional offset run. Offset prints from fixed plates, so every sheet is identical by definition. If your client's print partner quotes an offset price for a serialised job, something is wrong with the brief. Serialised codes need a digital or VDP-capable press.

On the design side, the common tool is Adobe InDesign's Data Merge, which can pull a different image into each record. It works, but it has sharp edges: Data Merge allows only one placeholder size per field, references images by file path, and will not merge records when fields sit across multiple parent pages. Getting a different pre-rendered QR PNG reliably into every record, correct path, correct frame, no scaling surprises, is the fragile step. For simple URL codes InDesign can even generate the QR per record itself, but that breaks down for branded or styled codes, which is why agencies running large or design-heavy jobs reach for dedicated VDP engines such as XMPie or FusionPro.

You do not need to run the press yourself. You need to brief it correctly. Hand the printer a clean data file, name your image files to match the rows exactly, confirm the press is VDP-capable, and ask for a proof of a few records before the full run. And mind the physical specs while you are at it: serialised codes are still QR codes, so the same quiet-zone, contrast and resolution rules apply. Our guide on preparing a QR code for print covers the vector, resolution and colour traps that turn a clean code into an unscannable one.

Why bulk almost always means dynamic

Everything above is harder, and more worth doing, when the codes are dynamic. This is the decision that protects a large campaign.

A static code encodes the destination directly in its pattern. It cannot be edited and it carries no tracking. A dynamic code encodes a short redirect URL instead; the real destination lives in a dashboard, the redirect is editable, and that redirect is exactly what lets you count scans per code, with timing, location and device. The difference between static and dynamic is the difference between a printed dead end and a code you can manage, and we lay out the full trade-off in dynamic versus static QR codes.

At one or two codes the choice is academic. At a thousand it is not, for two reasons.

The first is recovery. A wrong destination in a batch of thousands is, with static codes, a reprint. Physical collateral that is already in the field cannot be recalled; you reprint and redistribute, and you explain the cost to your client. With dynamic codes the same mistake is a dashboard edit. You change where the redirect points and every printed code, everywhere, now resolves correctly. The full mechanics of that fix are in changing a QR code's destination without reprinting. On a serialised job, where a single bad row could mean thousands of wrong pieces, this is not a nice-to-have. It is insurance.

The second is the entire reason you serialised in the first place: per-code tracking. Dynamic codes report on each unique code independently, which is what turns a batch into data. Per store, per region, per placement, you see what actually drove scans. That is the input to the scan metrics that matter, and if your client lives in Google Analytics, it is what feeds a clean GA4 and UTM setup so scans stop showing up as direct traffic.

The honest trade-off: dynamic codes mean an ongoing subscription and a dependency on a redirect service staying up, where static codes are free and depend on nothing. For a disposable code that is a real cost. For a serialised campaign across hundreds of placements that you are reporting on and cannot reprint, the editability and the analytics are the whole job, and the subscription is the cheapest line in the budget.

Running bulk codes across multiple clients

One more layer that only bites at agency scale: you are not running one bulk campaign, you are running several at once for different clients. Thousands of codes in a single undifferentiated list is its own failure mode. The Hamburg retail codes and the SaaS launch codes and last quarter's expired event codes all blur together, and onboarding a new team member becomes a tour of tribal knowledge.

The fix is structural separation: one workspace per client, with each campaign's codes grouped and tagged inside it, so a code's owner, campaign and status are obvious at a glance. That is a whole discipline in itself, and we walk through it in organising QR codes one workspace per client. Bulk generation creates the volume; workspace structure is what keeps that volume legible six months on.

Frequently asked questions

How do I generate QR codes in bulk?

Download your QR platform's CSV or spreadsheet template, add one row per code with at least a destination URL and a name, upload it, and the platform returns a ZIP of generated codes named from your spreadsheet. Check your plan's per-batch limit first: these range from single digits on trials to 10,000 per run on enterprise tiers, and they are set by your subscription, not by QR codes themselves.

Can I create a unique QR code for every product or store?

Yes. This is called serialisation: each row in your source file maps to one unique code, so each store, region or product unit gets its own. The key is a clean source spreadsheet with no duplicate values, ideally a unique slug per code. Use dynamic codes if you want each one tracked separately, which is usually the reason to serialise in the first place.

How many QR codes can I generate at once?

There is no universal limit; it depends entirely on the platform and plan. As examples from vendors' own documentation: QR Code Generator PRO caps batches at 5, 100 or 500 by tier; Uniqode ranges from 15 to 10,000 and processes a 10,000-code batch in about a minute; QRCodeChimp sets no fixed batch number but bounds you by your plan's total and suggests splitting very large jobs. Always confirm the ceiling before building the campaign.

Can I make bulk QR codes from a Google Sheet or Excel file?

Yes, two ways. Most platforms accept a CSV or spreadsheet export as the bulk-upload template. Or, for a quick static batch, a spreadsheet formula like =IMAGE("https://quickchart.io/qr?text="&ENCODEURL(A2)) renders a code per row directly in Google Sheets. The formula method is free only at low volume and produces static, untrackable codes, so it suits proofs of concept, not client campaigns.

What is variable data printing and why does it matter for QR codes?

Variable data printing (VDP) is digital printing that changes content from one piece to the next within a single run, driven by a data file. It matters because serialised QR codes (a different code on every piece) can only be printed this way. Traditional offset printing uses fixed plates and produces identical copies, so it cannot do serialised codes. Confirm your print partner uses a VDP-capable digital press.

Should bulk QR codes be static or dynamic?

Dynamic, in almost every case where the codes are printed and tracked. Dynamic codes let you fix a wrong destination after print with a dashboard edit instead of a reprint, and they track each code independently so you get per-store or per-region data. Static codes are free and dependency-free, which suits disposable, single-use codes, but they cannot be edited or tracked, which makes them risky at scale.

How do I avoid duplicate QR codes in a batch?

Treat your source spreadsheet as the single source of truth: one row per code, each with a unique destination or tracking slug, and a consistent naming convention so duplicates are visible. Generating from one clean file (rather than making codes ad hoc) is the simplest guard against two pieces accidentally sharing a code.

The short version

Bulk QR codes are only worth doing when each code is unique, and uniqueness is only worth it when each code is tracked. Build from one clean source spreadsheet where every row maps to a single code with a clear name; check your platform's batch limit before you start; brief the print shop for variable data printing on a digital press, not offset; and make the codes dynamic so a wrong destination is a dashboard edit instead of a five-figure reprint, and every code reports on its own. Then keep the whole batch inside a structured client workspace so it still makes sense next quarter. Set it up that way once and a thousand-code campaign becomes a spreadsheet and an upload, with attribution built in. Start your next batch in a dedicated workspace and let the structure do the remembering for you.