# QR codes for serialised products

> Serialisation gives every unit its own QR code carrying an opaque serial that your server resolves. One investment powers authentication, recalls, warranty, and resale provenance simultaneously. Keep serials random and meaningless, put data server-side, and use GS1 SGTIN-style identifiers if codes must also serve retail scanning.

Source: https://useqr.app/docs/ecommerce/qr-code-for-serialized-products · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## From "this product" to "this unit"

A per-SKU code answers "what is this?"; a serialised code answers "which one is this?",
and that difference is what unlocks the interesting use-cases. Serialisation means every
unit leaving the line carries a unique code:

```
example.com/u/7f3k9q2m
```

The same physical label process, one variable field, and suddenly the code can speak
about *this* unit's batch, history and status rather than the product in general.

## The use-case stack

The economics of serialisation are that **one investment powers every unit-level
use-case at once**:

- **[Authentication](/docs/ecommerce/qr-code-for-product-authentication)**: a serial
  that exists in your database, with scan-anomaly detection for copied codes.
- **Recalls**: the scan page can say "your unit is affected" instead of making
  customers parse batch ranges; the highest-stakes payoff, covered for food on the
  [allergens page](/docs/ecommerce/qr-code-for-ingredients-and-allergens).
- **[Warranty registration](/docs/ecommerce/qr-code-for-warranty-registration)**, the
  serial arrives prefilled; support knows the unit's manufacture date and firmware.
- **Resale provenance**: second-hand buyers verify age and history, which supports
  resale value for premium goods.
- **The [EU Digital Product Passport](/docs/ecommerce/eu-digital-product-passport)**:
  unit-level identity is the prerequisite the coming rules assume; building it now is
  the future-proofing step.

Any one of these might not justify the operational change; the stack usually does.

## Data model: opaque serial, server-side everything

The design rule that saves you later: **the code carries an opaque pointer, the server
holds the facts.**

- **Random, sparse serials**, 8+ characters from a large alphabet, so valid serials
  cannot be guessed or enumerated. Sequential serials hand a counterfeiter your entire
  namespace and leak production volumes to anyone who buys two units.
- **No meaning in the serial**, no encoded dates, plants or SKUs. Meaning lives in the
  database row, where it can be corrected; a meaning-bearing serial printed wrong is
  wrong forever.
- **Short payloads**, an 8-character serial in a short URL yields a version 2–3 code
  with big modules that survives
  [small-label printing](/docs/ecommerce/qr-code-on-a-product-label); a JSON blob does
  not.
- **Your domain, forever**, the [packaging permanence rules](/docs/ecommerce/qr-codes-on-product-packaging)
  compound at unit level: millions of printed serials cannot be re-pointed if the
  domain dies.

## GS1 framing, when retail is in the picture

If the serialised code must *also* serve tills and supply chains, use the GS1 shape:
**SGTIN** (the GTIN plus a serial) expressed as a
[GS1 Digital Link](/docs/spec/gs1-digital-link-in-qr) URL:

```
https://id.example.com/01/09520123456788/21/7F3K9Q2M
```

`01` is the GTIN, `21` is the serial. POS and logistics scanners parse the identifiers;
phones resolve the URL; and the same code satisfies the direction
[retail 2D migration](/docs/ecommerce/gs1-digital-link-for-retail) and DPP planning are
both heading. A purely direct-to-consumer brand can skip GS1 and use bare short URLs
(simpler and fine), but changing artwork later costs more than adopting the shape early.

## Generating at production scale

Per-unit codes mean volume. The routes, in ascending order:

- **Batches**: `POST /api/v1/qr/batch` (**up to 1,000 codes per request**, keyless)
  fed from your serial export; loop requests for larger runs. Patterns in
  [bulk generation at scale](/docs/developers/bulk-qr-generation-at-scale).
- **On-line printing**: the label printer renders codes at line speed from your MES:
  generation happens locally, serials are committed to the database at print time.
- Either way, **[verify decode](/validate)** as a production check, not a one-off:
  sample units per shift, scan, confirm the serial resolves. A misconfigured printer
  producing undecodable codes for a day is a recall of its own.

## FAQ

### What is a serialised product QR code?
A unique code per unit, carrying an opaque serial your server resolves. Unlike a per-SKU code it identifies the individual item, enabling authentication, unit-level recalls, prefilled warranty registration and resale provenance from one label change.

### Should serial numbers be sequential?
No. Random, sparse serials of eight or more characters prevent guessing and enumeration, and avoid leaking production volumes. Sequential serials give counterfeiters your whole namespace and tell anyone with two units how many you make.

### What is an SGTIN and when do I need one?
SGTIN is GS1's serialised identifier (GTIN plus serial) expressed in a QR as a Digital Link URL. Adopt it when codes must also serve retail scanning or Digital Product Passport requirements; direct-to-consumer brands can use plain short URLs.

### How do I generate thousands of unique QR codes?
Export serials and call a batch endpoint (UseQR's takes up to 1,000 items per keyless request), or render codes at the label printer from your production system. Sample-scan printed output every shift as a quality check.

## Try it

- https://useqr.app/url
- https://useqr.app/bulk
- https://useqr.app/validate