GS1 Digital Link vs proprietary QR codes: the identifier decision you only get to make once

Every Digital Product Passport project reaches the same fork in the road, usually in week three: what exactly do we encode in the QR code?

It sounds like a detail. It is actually the least reversible decision in the whole programme. Once a QR code is printed, engraved or woven into a physical product, it is out of your control forever. Change your mind later and the cost is measured in re-labelling entire inventories — or worse, in passports that stop resolving.

There are two real options: a proprietary URL you invent yourself, or a GS1 Digital Link. This post is the comparison we walk clients through, with the trade-offs made explicit.

What a GS1 Digital Link actually is

A GS1 Digital Link is an ordinary HTTPS URL with a standardised structure. It packs GS1 identifiers — the same GTINs that already sit behind every retail barcode — into the URL path:

https://id.eudigipassport.eu/01/09506000117843/21/A8F3-2K91-77QD
                             │  │              │  │
                             │  └─ GTIN        │  └─ serial number
                             └─ AI (01)        └─ AI (21)

The /01/ and /21/ segments are Application Identifiers — 01 means "GTIN", 21 means "serial number". Together, GTIN + serial identify one specific physical unit, globally and unambiguously, under ISO/IEC 15459 rules. Encode that URL in a QR code (ISO/IEC 18004) and you have a data carrier that satisfies the ESPR's identifier requirements out of the box.

The domain at the front is called the resolver. It can be yours (id.yourbrand.com), your platform provider's, or GS1's own — and this is where the strategic flexibility lives.

The proprietary alternative

The do-it-yourself version looks harmless:

https://passport.yourbrand.com/p/8f3a2c91

An opaque ID, a bespoke path scheme, resolved by an application only you operate. Faster to ship in week one. Then the costs arrive on a delay:

1. It fails the checkout test

Under GS1's Sunrise 2027 initiative, retail point-of-sale systems worldwide are being upgraded to scan 2D codes in place of the traditional EAN/UPC barcode. A GS1 Digital Link QR scans as the product's barcode at checkout — because the GTIN is right there in the URL — while also opening the passport when a consumer scans it. A proprietary URL does neither. Products that need both end up carrying two codes, which packaging teams despise and label space rarely permits.

2. It welds you to one vendor

A proprietary scheme is only resolvable by the system that invented it. If that vendor raises prices, gets acquired or shuts down, the URLs on your products point at a dead end. With GS1 Digital Link, the identifier layer (GTIN + serial) is yours independent of any platform — switch providers and the same printed codes simply resolve somewhere new.

3. It fails the regulator's openness requirement

ESPR requires passport data to be based on open, interoperable standards. A bespoke URL scheme with undocumented semantics invites exactly the kind of scrutiny you do not want during market surveillance. GS1 Digital Link is an ISO-recognised, publicly specified standard with multi-industry governance — the safe answer to "justify your data carrier".

One code, many destinations

The under-appreciated superpower of Digital Link is contextual resolution. Because the URL structure is standardised, a resolver can route the same physical code to different destinations depending on who asks:

• A consumer's phone camera → the public passport view
• A market surveillance authority → the full compliance record
• A recycler's handheld → disassembly and material-recovery data
• A retail POS scanner → doesn't follow the URL at all; it just reads the GTIN

This is precisely the persona-based access model the ESPR and Battery Regulation demand — and it falls out of the architecture for free, instead of being bolted on.

const passport = await dpp.passports.resolve(
  "01/09506000117843/21/A8F3-2K91-77QD",
  { persona: "recycler" }
);
 
console.log(passport.view.disassembly.steps); // recycler-only data

"But we don't have GTINs"

Smaller manufacturers sometimes stall here. Three practical notes:

1. GTIN allocation is a solved problem. A GS1 membership provides a company prefix and as many GTINs as your catalogue needs; the cost is a rounding error next to any compliance budget.
2. Serialisation is where the real design work lives — batch-level (/10/) versus unit-level (/21/) identification. Batteries require unit-level. Textiles will likely accept batch-level for most items. Decide per category, not globally.
3. You can start before your GTINs are perfect. Passports minted at batch level can coexist with unit-level passports minted later; the Digital Link grammar handles both.

The cost comparison, honestly

A proprietary scheme is genuinely cheaper for the first ninety days: no GS1 membership, no identifier governance, no resolver standards to read. Every cost after that favours the open standard:

Already printed proprietary codes? A migration path exists

If you ran an early pilot with bespoke URLs, the situation is recoverable — the key is to stop the bleeding before scaling:

1. Freeze the proprietary scheme now. Every additional unit printed deepens the migration debt. New production runs switch to Digital Link immediately; the two schemes can coexist during the transition.
2. Keep the old resolver alive as a translator. Your legacy endpoint doesn't need to render passports forever — it needs to 301-redirect old URLs to the Digital Link equivalents. A lookup table from opaque ID to GTIN + serial is usually already implicit in the pilot database.
3. Sunset by attrition, not by recall. Products with legacy codes age out of the market naturally. As long as the redirect layer stays up (cheap — it is a static mapping), those units remain compliant and scannable for their lifetime.

The cost of this migration is real but bounded. The cost of not migrating compounds: every year of proprietary printing adds another cohort of products welded to an architecture you have already decided to leave.

Resolver governance: the part to write down

Whoever operates the resolver holds real power over your products, so put the governance in writing regardless of provider:

• Domain ownership — the resolver domain should be registered to you, even if a provider operates the infrastructure behind it. DNS control is exit power.
• Link-registry export — the mapping from identifiers to destinations must be exportable on demand, in a documented format. This is your migration insurance.
• Uptime and persistence commitments — passports must resolve for the product's lifetime, which is longer than any SaaS contract. Ask what happens after termination, and get the answer into the agreement. (Our answer: contractual lifetime persistence, independent of the commercial relationship — because the regulation demands it and the registry architecture assumes it.)

We build exclusively on GS1 Digital Link — not out of ideology, but because we have watched the alternative age badly. Your products will outlive your software choices. The identifier printed on them should too.

Deciding between batch and unit-level serialisation for your catalogue? Talk to us — we'll model both against your delegated act and your label real estate.