GS1 Digital Link Explained for Engineers

The problem it solves

A traditional barcode encodes an identifier and nothing else. Scanning it gives you a number, and to do anything with that number you need to already know which system to ask and how to ask it. That works fine inside a retailer's own checkout and works badly everywhere else, which is why product information has historically been locked inside whoever printed the label.

GS1 Digital Link changes the encoding rather than the identifier. Instead of a bare number, the carrier holds a web URI that contains the identifier in a standardised structure. Anything that can resolve a URL can now reach the data, which means a consumer's phone camera, a recycler's scanner and a market surveillance authority's tooling all work without any prior agreement with you.

For Digital Product Passports this is the difference between an interoperable implementation and a proprietary one. A passport reachable only through your own application is not meaningfully accessible to a recycler in another country, which is precisely the actor the regulation intends to serve.

How the URI is structured

A Digital Link URI embeds GS1 identifier keys as path segments in a defined order. The primary key — most commonly a Global Trade Item Number — appears first, followed by optional qualifiers such as batch or lot, serial number, or expiry, each introduced by its own application identifier. The result is a URL that is simultaneously human-shareable and machine-parseable.

The important property is that the structure is standardised rather than invented per company. Any conforming parser can extract the identifiers from the URI without knowing anything about your domain, which is what makes cross-organisation resolution possible at all. Inventing your own URL structure gets you a QR code that works and a passport that does not interoperate.

Qualifiers matter more than they first appear. A URI carrying only a product-level identifier can never support batch-level traceability, regardless of what your backend stores, because the physical carrier does not encode which batch it came from. This ties directly back to the identifier granularity decision, which is why the two should be made together.

Implementing a resolver

A Digital Link resolver takes an incoming URI and redirects or responds according to who is asking and what they want. The mechanism is deliberately simple: link types describe what a given resource is, and the resolver maps requested link types to actual destinations. A consumer requesting product information and an authority requesting compliance documentation follow the same URI and reach different places.

Three implementation decisions cause most of the difficulty. First, whether you host the resolver yourself or use a third-party service, which is largely a question of how much you care about controlling the domain in the identifier. Second, how you handle unknown or retired identifiers, since products outlive product lines and a dead link on a physical object is permanent. Third, how you authenticate the actors who get privileged views.

That last point is where passport implementations most often cut corners. Serving everything publicly is simple and leaks commercial data. Serving everything behind authentication is safe and defeats the purpose for consumers. The correct answer is tiered, with the public tier genuinely public and the privileged tiers gated by something an authority or recycler can actually obtain.

Practical implementation checklist

• Choose the primary identifier key and confirm it matches your delegated act's granularity requirement
• Decide which qualifiers the physical carrier must encode, because this cannot change later
• Register or confirm the domain that will appear inside every printed identifier
• Define the link types you will serve and which actor tier each one belongs to
• Plan for retired identifiers, since a printed code outlives the product line it belonged to
• Test the carrier physically, at real print sizes, on the actual substrate and packaging
• Validate against an external conforming parser rather than only against your own resolver

Where teams get this wrong

The most common error is treating Digital Link as a URL shortener. Teams generate a short link per product, print it, and store the mapping in their own database. This works, produces a functioning QR code, and fails every interoperability requirement, because nothing outside your system can extract an identifier from an opaque short link.

The second is deferring the domain decision. The domain appears inside every printed identifier, and it becomes effectively permanent the moment products ship. Companies that use a marketing subdomain, or a third-party service domain they later want to leave, discover that changing it means reprinting everything already in circulation.

The third is skipping physical testing. A carrier that scans reliably on a screen may fail at production print size on a curved or textured surface, and this is discovered after the print run rather than before it. Testing on the real substrate at the real size is unglamorous and it prevents the most expensive category of mistake in the whole programme.

Part of the Circular Economy & Digital Product Passports cluster · Read the pillar page