ref.gs1.org

The Global Language of Business

Release 1.2.0, Ratfied Jan 2026

GS1-Conformant Resolver Standard

Resolving GS1 identification keys to one or more sources of related information and/or services

This section and its subsections are informative

GS1 defines a wide range of identifiers that underpin supply chains and many industries across the world. This document assumes the reader is familiar with these and the concept of GS1 Application Identifiers. If not, please see information on [GS1 Identification Keys] and the [GENSPECS] for further background.

This work has been motivated by a number of trends. For example: the desire among retailers to move to 2D barcodes that can carry more information than just the GTIN; the problems of multiple barcodes causing scanning errors through conflicts which suggests a need for a single but multipurpose barcode; the growing expectation among consumers and patients that more information is available online about the products they’re considering buying or using; the brand owner concept of the pack as a media channel linking to multimedia experiences and more.

A GS1 Digital Link URI identifies the entity (the product, the location, the asset etc.). When looked up online, best practice [DLBP] is to redirect from that entity identifier to a source of related information. A simple 1-to-1 redirect does not require any special software – it’s a basic function available on all Web servers. However, using a GS1-Conformant Resolver, it is possible to link that single entity to multiple sources of related information in a way that is machine-discoverable and machine-actionable.

The resolution functions defined in the current document are what brings that vision to life and allows easy communication between business partners and consumers in a manner that is scalable, interoperable and that does not require all related assets to be aggregated in one place. The GS1-Conformant Resolver standard is based entirely on existing standards and techniques defined by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C). The standard enables implementers to benefit from the network effect.

The existence of this standard does not mean that all GS1 Digital Link URIs must be connected to a GS1-Conformant Resolver. Neither is it a requirement that all GS1 Digital Link URIs must redirect, although this is strongly recommended. There are solid reasons for this recommendation.

A GS1 Digital Link URI identifies the entity itself. Management of that identity is a separate process from managing any digital information about the entity and will typically be carried out by different people. For example, a GTIN identifies a trade item, and that identifier is used in various business processes. Online information about the trade item will often be managed by a brand marketing team, or those responsible for product information leaflets or instructions for use in healthcare, who will introduce new content, delete or move old content, will run promotions, medical product information, etc. Redirecting from the trade item to online product information avoids any tension between multiple management processes. The redirect can be updated at any time without affecting or needing to reprint the GS1 Digital Link URI encoded on the product. This helps to ensure that the GS1 Digital Link URI continues to function as a persistent identifier for the trade item, even though the online information changes over time.

Whether redirection is implemented or not, there are many ways to make use of GS1 identifiers within a GS1 Digital Link URI that do not require the use of a GS1-Conformant Resolver. Any Web-based application can parse the GS1 Digital Link URI and make use of the available AIs and their values. To take a simple example, if the GS1 Digital Link URI includes an expiry date that has passed, a Web page presented to the user might include a warning that is absent for products that have not expired.

Developers are encouraged to make use of the GS1 Barcode Syntax Resource [BSR] when building applications that scan, parse or validate GS1 identifiers.

Even if presenting a simple Web page containing information about the identified entity, any links from that page to further information can be annotated with the machine-readable link types discussed in this document. This can help the automatic discoverability of all information related to the identified entity.

This document includes sample JSON objects and examples of GS1 Digital Link URIs such as:

https://example.com/01/{gtin} and

https://example.org/414/{gln}/254/{glnExtension}

https://example.org/01/{gtin}{?exp}

The use of the monospace font indicates that the text has meaning for computers.

Example URIs follow the convention used in Template URIs [RFC 6570]. The places where the values of variables should be inserted are written in braces, so, for example, {gtin} means "insert the 14 digit GTIN here". All other text in the URI is a literal string to be used as written.

As explained in [RFC 2606] and [RFC 6761], the domains example.com, example.org and example.net are second-level domain names reserved by the Internet Assigned Numbers Authority (IANA) for use in documentation, along with the .example top level domain name. These should be understood as a placeholder for any registered domain name.

In AIDC (Automatic Identification and Data Capture), the term 'qualifier' is used for the short string of characters that declare the type of identifier that follows. For example, '01' is the qualifier that precedes a string of 14 digits that makes it recognisable as a GTIN. GS1's Application Identifiers are one type of qualifier. ANSI MH10.8.2 Data Identifiers are another (both are conformant with ISO/IEC 15418). In AIDC, the actual identifier itself is called 'data'.

In common with the GS1 Digital Link URI syntax standard [DL-URI], this standard uses the term 'key qualifier' to mean an extension that provides more fine-grained identification that the primary key. For example, a GTIN is a primary key, and a batch/lot is a 'key qualifier'; a GLN is a primary key, a GLN extension is a key qualifier.

This section and all its subsections are normative, except where explicitly stated otherwise.

A GS1-Conformant Resolver connects a GS1-identified object or entity to one or more online resources that are directly related to it. The object or entity may be identified at any level of granularity, and the resources may be either human- or machine-readable. Examples include product information pages, instruction manuals, patient leaflets and clinical data, product data, service APIs, marketing experiences and more. By adhering to a common protocol based on existing GS1 identifiers and existing Web technologies, each GS1-Conformant Resolver is part of a coherent, yet distributed, network of links to information resources. The remainder of this document defines the minimum set of requirements of a GS1-Conformant Resolver that make this vision possible.

In common with GS1 Digital Link URI syntax [DL-URI] the GS1-Conformant resolver standard is itself conformant with Encoding and resolving identifiers over HTTP [ISO/IEC 18975]

A GS1-Conformant Resolver does not need to support all GS1 primary identification keys. It may support just a subset. For example, a GS1-Conformant Resolver may support just GTIN, or GTIN and GLN, etc. However, for each supported primary identification key, all its key qualifiers and data attributes SHALL be fully supported. See section 2.5.9 for more on this topic and section 3 for how to declare the primary identification keys a GS1-Conformant Resolver can support.

A GS1-Conformant Resolver SHALL operate according to the relevant standards that define HTTP 1.1 or higher for GET, HEAD and OPTIONS requests and SHALL support HTTP over TLS [RFC2818]. On top of HTTP, a resolver SHALL also implement Cross-Origin Resource Sharing [CORS] to allow client-side JavaScript Web applications to access the resolver across domains. The GS1 identification keys are expressed as a GS1 Digital Link URI [DL-URI] which is the input to the resolver.

This specification adds additional functionalities that define a GS1-Conformant Resolver. In summary, these are:

  1. Decompression: Decompress the request URI if necessary (the request URI is the URI received and processed by the resolver).
  2. Basic validation: Like any software that accepts user input, the resolver will need to carry out basic checks on the request URI and extract the GS1 Application Identifiers and values from the path.
  3. Providing links:
    1. Provide links to resources related specifically to the entity identified by the GS1 identification keys (hereafter called the identified entity) up to and including links registered at the requested level of granularity.
    2. One of the links SHALL be recognised by the resolver as the default and the resolver SHALL redirect to that URL unless there is information supplied within the query to the contrary. Such information may be provided in the HTTP Request headers and/or by setting a linkType parameter in the query string of the request URI indicating the type of link desired. If a link to a resource of the requested type is known to the GS1-Conformant Resolver, it SHALL redirect to that resource immediately.
    3. If the value of linkType is set to linkset, or the HTTP Accept header is set to application/linkset+json, then the resolver SHALL NOT redirect but SHALL return a full list of links available to the client, following the Linkset standard [RFC 9264] (see section 2.9)
  4. Deep validation: A resolver MAY carry out detailed validation on the request URI and include the analysis when reporting an error.

Each of these is expanded upon with important detail in the following sections. The flowchart below provides a visual summary of the basic functionality of a GS1-Conformant Resolver.

One aspect of the flowchart to note is that at several of the decision points, the question arises of whether there is information at a less-granular level. This refers to primary keys that can be qualified by more granular identification. The most important example of this is the GTIN which can be extended by a Consumer Product Variant, batch/lot and serial number. Given a GS1 Digital Link URI that includes, for example, a GTIN and a serial number, a GS1-Conformant Resolver will often need to take note of links recorded at both the serial number and GTIN level. Sections 2.5.9 and 2.5.10 are particularly relevant for this discussion.

Basic resolver flow chart
Figure 2-1: Basic resolver flow chart

The original GS1 Digital Link URI standard [DL1.1] defined how such a URL can be compressed into a form that uses fewer bytes to encode the same data. As the algorithm is lossless, compressed GS1 Digital Link URIs can be decompressed. An important feature of the compression/decompression algorithm is that it does not affect the domain name used and that the compressed GS1 Digital Link URI is still a valid URL. This means that a compressed GS1 Digital Link URI can be looked up on exactly the same resolver with exactly the same result as its uncompressed equivalent.

EPC binary, as defined in the Tag Data Standard [TDS], is a very compact encoding of GS1 identifiers that can be decoded into a GS1 Digital Link URI as defined in the Tag Data Translation standard [TDT].

The original compression algorithm and EPC binary strings do not clash as EPC binary strings, when represented as compressed GS1 Digital Link URIs, are prefixed with ex or eh. Full details are provided in GS1 Digital Link URI: Compression Technical Standard for EPC binary strings [EPCB].

EPC binary is a recognised syntax for GS1 identifiers in open supply chains whereas the broader GS1 Digital Link compression method is not. This situation is not expected to change. Therefore a GS1-Conformant resolver SHALL decompress EPC binary strings [EPCB] and MAY implement the full GS1 Digital Link decompression algorithm [DL1.1].

Any linkset returned from a GS1-Conformant resolver SHALL use the decompressed form as the anchor for all links, not the compressed form. If redirecting to another resolver, the redirecting GS1-Conformant Resolver SHOULD redirect the uncompressed URI.

The system architecture that stores links used by the resolver is not defined by this standard, but it is very likely to be a database in which links are associated with the relevant GS1 identifiers. In order to maximise the performance of the outward-facing resolver service, it is assumed that data will be validated when ingested into the system. That is, it SHOULD be impossible to register a link against an invalid GS1 identifier or set of identifiers. This means that at run time the resolver can simply check whether it has one or more links for a given identifier without having to carry out detailed validation of those identifiers. If links are found, the GS1 identifiers will be known to be valid.

However, basic validation steps will need to be carried out by the resolver before looking up whether it has any associated links. This is necessary to make sense of the incoming request and to avoid, for example, passing control characters to a database. Basic validation should be based on rules codified in the GS1 General Specifications [GENSPECS] that change at a very slow pace over time, if at all. They can be carried out in such a way that they allow for new AIs that are not defined at the time the resolver was built. The following basic tests are recommended and should be carried out before looking for links associated with the GS1 keys included in the request URI.

  1. Overall plausible URI structure:
    1. <scheme>://<domain.name>/<stem>/<primary key AI>/<primary key>/possible-further AI+value-pairs> (the query string is ignored by resolvers).
    2. Percent encoded characters within the path are decoded prior to performing the AI and AI data checks outlined in the following points.
  2. AIs per AI definitions:
    1. Are numeric and between 2 to 4 digits long
    2. Overall AI length is consistent with other AIs, where there is a prefix match; the rule is that all AIs with same 2-digit prefix have identical length e.g., AI (24) is not valid because (240) exists.
  3. AI data per AI definitions:
    1. Overall AI data length meets specifications (after percent decoding)
    2. Belongs to character set 39, 82 or 64
    3. Raw AI data belongs to superset of character set 39 and 82 if AI unknown
    4. Overall check calculation - numeric or character pairs
    5. Data format checks with component level breakdown e.g., GCP structure
    6. If duplicate AI found, check values are the same (note, this can occur when multiple barcodes are scanned from a single entity and element strings are concatenated for processing as a GS1 Digital Link URI e.g., shipping labels)

If a request URI can be parsed into its component AIs and their values, and all the above tests are passed, then finding one or more links associated with those identifiers will be sufficient to show that it is valid.

The following tests are based on specifications that change at a medium pace. Implementations MAY include these as part of their basic validation steps and are encouraged to do so:

  1. GS1 Digital Link primary key validity (is the left-most AI in the request URI a primary key?)
  2. GS1 Digital Link key qualifier valid for primary key (are any qualifiers valid for the primary key?)

Further tests MAY be carried out but SHOULD only be done before reporting an error and not for all request URIs. These tests make use of specifications that can change at a relatively fast pace due to periodic standards maintenance activities. Therefore real time lookups and active management of the resolver's codebase MAY be required.

  1. AIs are known, as new AIs are introduced
  2. Test for mandatory AI pairings
  3. Test for invalid AI pairings
  4. Validation and lookup of externally managed codes or numbering systems (e.g., IBAN leading country code, ISO/IEC general country and currency code etc.)
  5. Media Type lookup (see section 2.5.5 for further information on content Media Type)
  6. Ad hoc component validation, e.g., winding rule components (8001)
  7. Consider inspecting and validating AIs and their values in the query string if present, especially if the resolver makes use of those AIs and their values in its decision-making process.

If the resolver cannot provide a response for the incoming request URI there are two primary reasons why this might be so:

  1. The resolver has no information about the identified entity.
  2. The tests enumerated above are not passed, meaning that the request URI is not a valid GS1 Digital Link URI both in terms of its overall syntax and the syntactic validity of the identifier keys [DL-URI].

It is important, from a developer perspective, that the resolver differentiates between these two error conditions. If the request URI fails any of the tests then the resolver SHALL respond with an HTTP response code of 400 (Bad Request) [RFC9110]. The error report may be enhanced with the diagnostic information gathered from the final set of tests.

If the request URI is a syntactically valid GS1 Digital Link URI, but the resolver has no information about the identified entity then it SHALL return a simple 404 Not Found response.

There are other scenarios where the GS1-Conformant Resolver is not able to provide any service for the identified entity. In these cases, other HTTP response codes are likely to be appropriate. What is essential is that a GS1-Conformant Resolver SHALL NOT use a 200 OK response code when processing a query that, for whatever reason, causes an error condition.

This subsection is informative

The GS1 Barcode Syntax Resource [BSR] is a set of tools for solution providers, that enables the consistent understanding of each GS1 barcode syntax, including the GS1 Digital Link URI, for the purpose of converting between each syntax. To facilitate the various syntax conversions, the BSR provides a means to validate GS1 keys, associated AIs as well as each GS1 barcode syntax. This includes a software library and routines which can be adapted as required, to implement the tests enumerated in the previous section.

This section defines how GS1-Conformant Resolvers should perform redirection and how GS1 key licensees and client applications can exercise control over the redirection process.

There are three ways in which a client can query a GS1-Conformant Resolver:

  1. A simple lookup that results in the default response. From a client perspective, this requires no special software or understanding of GS1-Conformant Resolvers or even that it is dealing with a resolver. It’s a simple web request.
  2. A request for a specific type of resource.
  3. A request for the set of links to all resources associated with a given GS1 identifier or set of identifiers.

The following sections discuss these in turn.

This section is informative

Some examples should help to clarify the previous discussion.

Example 1: Simple redirect

A manufacturer operates their own resolver that just handles GTINs. For all identified entities in the resolver’s database, there is exactly one link which is to the product’s information page. In this situation, all request URIs result in a redirection to the relevant product information page with the same link types of gs1:pip and gs1:defaultLink whether or not the URI includes CPV, batch/lot or serial number. Note that setting up a simple 1-1 redirection service like this does not necessarily need a GS1-Conformant Resolver. See section 1.1.

Example 2: Temporary change of default link

A GS1 Member Organisation operates a GS1-Conformant Resolver. A consumer electronics manufacturer sets up links for one of their products as shown in the table below.

Table 2-1: Initial data for example 2
Link type Resource description
gs1:pip, gs1:defaultLink Product information page
gs1:instructions The instruction manual
gs1:certificationInfo A document showing compliance with the relevant regulations

This is the usual situation so that the resolver will redirect the incoming GS1 Digital Link URI to the product information page but, for a limited period of time, the manufacturer wants to point potential consumers to a promotional campaign and adds another link so that their full set is:

Table 2-2: Temporary data for example 2
Link type Resource description
gs1:pip Product information page
gs1:instructions The instruction manual
gs1:certificationInfo A document showing compliance with the relevant regulations
gs1:promotion, gs1:defaultLink Entry point for a promotional campaign

Note that the default link is now the same as the (temporary) gs1:promotion. This means that for the duration of the promotion, by default, the resolver will redirect the GS1 Digital Link URI to the promotion.

Example 3: Multiple links in multiple languages

An independent organisation operates a repository of electronic patient information leaflets on behalf of a variety of pharmaceutical manufacturers. For each drug, they offer two types of information: one designed for patients (gs1:epil) and one for clinical staff (gs1:smpc). The leaflets are available in multiple languages and the repository chooses to make each language version available at a different URL (see section 2.5.4 for why, although this is a common choice, it is not necessary). This leads to multiple links for both supported link types. The manufacturer provides the list of available links as shown below.

Table 2-3: Data for patient information leaflet example
Link type Resource description
gs1:defaultLink Patient information (Dutch)
gs1:epil, gs1:defaultLinkMulti Patient information (Dutch)
gs1:epil, gs1:defaultLinkMulti Patient information (French)
gs1:epil, gs1:defaultLinkMulti Patient information (German)
gs1:smpc Summary product characteristics (Dutch)
gs1:smpc Summary product characteristics (French)
gs1:smpc Summary product characteristics (German)

In the absence of any information to the contrary, a resolver with these links available will redirect to the patient information leaflet (the ePIL) in Dutch (marked as the default). If there is no value for the linkType parameter, then:

  1. If the HTTP Accept-Language header sent by the client indicates a preference for ‘nl’, ‘fr’ or ‘de’ then the redirection would be to the patient information leaflet in the relevant language.
  2. If the Accept-Language header declared a preference for a language not listed, then, again, the resolver will redirect to the default version (Dutch).

Support for gs1:defaultLinkMulti is optional in any GS1-Conformant Resolver. If it were not supported in this case, then for anything other than the Dutch language patient information to be returned, the request URI would have to include the relevant linkType parameter and the HTTP Accept-Language header would need to match.

If an incoming request were received for the summary product characteristics (the term used to describe information for clinicians) by setting the linkType parameter to gs1:smpc, then:

  1. If the client’s language preferences can be matched, redirect to the SmPC in that language.
  2. If the client’s language cannot be matched, return a list of the available links with a 300 Multiple Choices response header.

The same reasoning applies if the linkType parameter were set to gs1:epil. In this case, the fact that the electronic information for patients is also the default is irrelevant.

If the linkType parameter were set to any value other than gs1:epil, gs1:smp or all, return a 404 Not Found message (optionally including the linkset)

Example 4; Leveraging link types in apps

A power tool manufacturer operates its own resolver and encourages its customers to register their purchase by including a GS1 Digital Link URI on the packaging, as follows:

https://tools.example.com/01/09520123456788/21/12345

The manufacturer sets the default to the link that is also labelled gs1:instructions which points to a video showing how the tool can be used. This is set at the GTIN level and so any consumer scanning the tool’s packaging in any store would see the same video. However, the same GS1 Digital Link URI can be scanned using the retailer’s app which asks for a link type of gs1:registerProduct. Combining information from both the retailer app, which includes information about the customer, with the manufacturer’s information about the serialised product makes the registration process easier for the consumer.

Table 2-4: Sample data for remaining examples
Link type Target URL Lang Context
gs1:defaultLink 1. https://example.com/en/defaultPage
gs1:defaultLinkMulti 2. https://example.com/en/defaultPage en
gs1:defaultLinkMulti 3. https://example.com/fr/defaultPage fr
gs1:pip 1. https://example.com/en/defaultPage en
gs1:pip 2. https://example.com/fr/defaultPage fr
gs1:whatsInTheBox 1. https://example.com/en/packContents/GB en GB
gs1:whatsInTheBox 2. https://example.com/fr/packContents/FR fr FR
gs1:whatsInTheBox 3. https://example.com/fr/packContents/CH fr CH
gs1:relatedVideo https://example.com/video/abcd

Example 5: Plain request

The request URI to be resolved does not include a query string and the Accept-language header is not set. There is no data in the request to match and so the response is simple: redirect to the default (https://example.com/en/defaultPage)

Example 6: Matching the language

The request URI to be resolved does not include a query string and the HTTP client’s Accept-language is set to fr (French). There is no query string (and therefore no linkType set). There is, however, a match between the requested language and an available default. The resolver redirects to the French language default (https://example.com/fr/defaultPage)

Example 7: Non-matching language

The request URI to be resolved does not include a query string, the HTTP client’s Accept-language is set to de (German), and there is no match between the requested language and an available default. The resolver redirects to the default (https://example.com/en/defaultPage)

Example 8: Matching the link type

The request URI to be resolved does include the linkType parameter which is set to gs1:relatedVideo. The resolver redirects to https://example.com/video/abcd

Example 9: Non-matching link type

The request URI to be resolved includes the linkType parameter which is set to gs1:instructions. There are no links of this type and so the resolver returns a 404 Not Found message.

Example 10: Matching link type and language

The request to be resolved does include the linkType parameter which is set to gs1:pip and the HTTP client’s Accept-language header is set to en. The resolver redirects to the English language page at https://example.com/en/defaultPage.

Example 11: Matching link type but not language

As in the previous example, the linkType parameter is set to gs1:pip but this time the HTTP client’s Accept-language is set to vi (Vietnamese). Here there is a match for the link type but not the language. In this case, there is no definite answer and so the resolver will return a 300 Multiple Choices response showing the two available links of type gs1:pip.

Example 12: Matching link type, language and context

The request URI to be resolved includes the linkType set to gs1:whatsInTheBox, the HTTP client’s Accept-language is set to fr and the context parameter is set to CH (Switzerland). This means that there is a link with a matching link type and two further matching attributes. The resolver redirects to https://example.com/fr/packContents/CH

Example 13: Prioritisation logic

Similar to the previous request but this time the requested language is en and the requested context is again CH. There are three links with the same gs1:whatsInTheBox link type. One matches the request by language, another by context. In this case, the resolver implementation chooses to prioritise language over context and redirects to the English language page at https://example.com/en/packContents/GB, even though the context doesn’t match. This is an implementation choice but the suggested order of priority is media type à language à context.

Resolvers MAY support redirection of all request URIs that match a given pattern to another resolver based on a template. In the GS1 context, this might be at the GS1 Member Organisation level or the GS1 Company Prefix level and amounts to a simple passing of the request on to another service without further processing. In addition to the Location header, the target URL MAY also be exposed in the Link header. In this case, the linkType (the rel value) SHALL be gs1:handledBy, indicating that the request URI is handled by the target resolver.

The concept and structure of a linkset is defined in Linkset: Media Types and a Link Relation Type for Link Sets [RFC9264]. It is a set of links from an identified entity to one or more sources of information that are directly related to it. A linkset includes all the attributes listed in section 2.5.

A client can request the entity’s linkset by either:

  1. setting the client’s HTTP Accept header to application/linkset+json;
  2. setting the value of the linkType parameter to linkset.

On receipt of such a request, the resolver SHALL NOT redirect the query and SHALL return the linkset. See section 2.10 for information on linkset formats.

If the request GS1 Digital Link URI includes one or more key qualifiers, any links associated with each level up to the primary key SHALL be included, that is, links are inherited from further up the hierarchy (see sections 2.5.9 and 2.5.10).

A resolver will return a linkset in a number of different situations:

  1. When explicitly asked for (section 2.9).
  2. When a resolver cannot determine which of several possible links it should redirect to (section 2.6.3).
  3. Optionally as part of the 404 Not Found error message when a requested link type is not available for the identified entity but others are (section 2.6.2).

GS1-Conformant Resolvers may format the linkset in any number of ways but for interoperability the following minimum rules apply. These are designed to ensure that the linkset is available consistently at least as machine-readable JSON/JSON-LD, and as a human-readable HTML page.

If the HTTP Accept header is application/linkset+json, the resolver SHALL return the linkset serialised as JSON as defined by RFC9264 [RFC9264]. It is RECOMMENDED that the identical response is returned if the HTTP Accept header is application/json. The linkset SHALL validate against https://ref.gs1.org/standards/resolver/linkset-schema.

The HTTP response headers SHOULD include a Link header pointing to a context file so that the JSON can be expanded to JSON-LD. In line with JSON-LD version 1.1 [JSON-LD], the link relation type SHALL be http://www.w3.org/ns/json-ld#context and the media type for the context file SHALL be application/ld+json. GS1-Conformant Resolvers MAY provide their own JSON-LD context file and could potentially link to different context files for different linksets. However, the RECOMMENDED approach is to use the context file published and maintained by GS1 at https://ref.gs1.org/standards/resolver/linkset-context. That URL always points to the latest version of the context file which may change with later versions of this document. To refer to an immutable context file, include the standard's version number in the URL. For example, https://ref.gs1.org/standards/resolver/1.2.0/linkset-context. The location of a resolver’s JSON-LD context file for linksets SHOULD be declared in its Resolver Description File (section 3).

Including the HTTP Link header to a JSON-LD context file when returning a linkset as JSON means that relevant applications can interpret the JSON as Linked Data [Linked Data] with no further effort required.

If the client explicitly requests JSON-LD by setting the HTTP Accept header to application/ld+json then the resolver SHOULD return the linkset as JSON-LD with the context definitions included in the data.

If the HTTP Accept header is text/html (or one of the legacy media types for HTML), or is unspecified, then the resolver SHOULD return an HTML page in which all the links are presented as hyperlinks. The linkset SHOULD be embedded within the HTML page as JSON-LD, complete with context definitions.

Note: that the value of the hreflang and context fields are arrays, even if there is only a single value.

If present, the query string in an uncompressed GS1 Digital Link URI carries attributes of the identified entity and does not form part of the entity’s identifier. Implementations MAY make use of query string parameters but this standard does not define a particular behaviour.

When redirecting, by default, a resolver SHALL transmit the entirety of the query string in the request URI to the target destination. This is because although the resolver is not required to process GS1 Application Identifiers or any custom or other extension name=value pairs in the query string, the target resource might be able to do so.

Where a GS1 Digital Link URI resolves to a directory on a server, it will typically be appended with a trailing slash automatically. Thus our example

https://example.com/01/09520123456788/22/2A

might be seen in the address bar of a browser as

https://example.com/01/09520123456788/22/2A /

This is not conformant to the GS1 Digital Link syntax, however, it is likely to be common and therefore resolvers SHOULD be tolerant of it.

Different GS1-Conformant Resolvers are likely to serve different needs and there is no requirement, nor any expectation, that every resolver will offer the same set of links or content for the same identified entity. Equally, it is not expected that every resolver will offer support for every combination of GS1 key or qualifier. Some may support extra name=value pairs in the query string, their own set of link types and so on. All these variations and more are possible while remaining as a GS1-Conformant Resolver.

Such flexibility is deliberate and allows different businesses to operate their resolver in the way that best suits them with the minimum of restriction. On the downside, the flexibility reduces interoperability between resolvers. To address this, we define the Resolver Description File.

The Resolver Description File performs a number of functions. It provides a machine-readable description of the resolver’s capabilities and thus allows applications to automatically detect a resolver’s capabilities and act accordingly. Furthermore, it explicitly asserts the sovereignty of URLs within its own domain name. See section 4 for why this is important and why a GS1-Conformant Resolver SHALL make a Resolver Description File available at /.well-known/gs1resolver. This is in line with Defining Well-Known Uniform Resource Identifiers (URIs) [RFC 8615]. The well-known location is recorded in the IANA Registry.

The terms that SHALL and MAY be included in a Resolver Description File are defined below. Resolver Description Files SHALL validate against the JSON schema published at https://ref.gs1.org/standards/resolver/description-file-schema. As with the linkset context file (section 2.9), this URL points to the latest version of the scheme. To point to an immutable schema, include the required version number in the URL. For example https://ref.gs1.org/standards/resolver/1.2.0/description-file-schema

  1. The resolver root (the customURIstem as defined in [DL-URI] (required).
    1. property: resolverRoot
    2. type: URI
  2. Enumerate which Primary Keys & related qualifiers are supported by the resolver (required).
    1. property: supportedPrimaryKeys
      1. type: array
      2. Allowed values: "all", "01", "8006", "8013", "8010", "414", “415”, "417", "8017", "8018", "255", "00", "253", "401", "402", "8003", "8004"
  3. A name for the GS1-Conformant Resolver.
    1. property: name
    2. type: string
  4. Additional namespace(s) of supported link type lists and associated prefixes (see section 2.14). Support for the GS1 Web vocabulary is assumed.
    1. property: supportedLinkType
    2. type: array of objects
      1. property: namespace
      2. type: URI
      3. property: prefix
      4. type: string
  5. Whether linkset is a supported default link type (section 2.11).
    1. property: linkTypeDefaultCanBeLinkset
    2. type: Boolean
    3. default: false
  6. The supported values (if any) for the context keyword. These can be provided through simple enumeration or by linking to an externally managed list.
    1. property: supportedContextValuesEnumerated
    2. type: array of strings
    3. property: supportedContextValuesExternal
    4. type: URI
  7. Contact details for the resolver operator.
    1. property: contact
    2. type: VCard
  8. A pointer to a document that describes any extensions the resolver supports, such as any extended key=value pairs
    1. property: extensionProfile
    2. type: URI
  9. If supported, the location of the JSON-LD context file referenced in the HTTP Link header when a linkset is served as a JSON object (section 2.9)
    1. property: jsonLdContextLocation
    2. type: URI

Example

As an example, the GS1 Global Office resolver’s description file (available from https://id.gs1.org/.well-known/gs1resolver) is reproduced below.


{
"name":" The GS1 AISBL Resolver",
"resolverRoot":"https://id.gs1.org",
"supportedPrimaryKeys": ["all"],
"supportedContextValuesEnumerated": ["dscsaSaleableReturn"],
"supportedContextValuesExternal": [{"nameOfList":"ISO-3166 Alpha-2",  "url":"https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes"}],
"linkTypeDefaultCanBeLinkset": true,
"contact": {"fn":"GS1 AISBL", "hasAddress":{"streetAddress":" Avenue Louise 523", "locality":"Brussels", "country-name":"Belgium", "postal-code":"1050"}, "hasTelepone":"tel:+32 2 788 78 00"}
},
"jsonLdContextLocation": https://ref.gs1.org/standards/resolver/linkset-context
}

The GS1 Digital Link URI syntax goes directly against W3C’s Web architecture principles [WebArch], namely URI Opacity, which states that:

Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.

GS1 is far from unique in going against this principle but recognises the conflict. There are two requirements that GS1 believes justifies overriding the principle:

GS1 further notes the definition of SHOULD NOT from [RFC2119]:

... there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Interoperability between different GS1 resolvers and other online services that make use of the GS1 Digital Link URI syntax is made possible by the use of GS1 identification keys. This means that the Internet domain name in the URI is not used for entity identification. This goes directly against URI Design and Ownership [BCP190], the abstract of which includes:

… the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership.

It is recognised that encoding GS1 identification keys and key values in a GS1 Digital Link URI goes against this by defining a substructure. However, resolvers are not required or expected to redirect to the same target resources or return the same linksets as each other. Furthermore, all GS1-Conformant Resolvers SHALL publish a Resolver Description File at /.well-known/gs1resolver that asserts its independent control of its URI space. The presence or absence of this file can be used to determine whether or not the URI points to a service conformant to this standard. The Resolver Description File includes information about whether the resolver handles all or only a subset of the GS1 identifier system, support for any extensions, the supported value space(s), if any, for the context keyword and more.

Therefore, each resolver/internet domain remains sovereign over its URI space and the Best Current Practice is not egregiously contravened.

Summarising the preceding discussion, a GS1-conformant resolver:

  1. For primary keys that are supported by the resolver and that have key qualifiers, all key qualifiers SHALL be supported (sections 2.1, 2.5.9).
  2. SHALL support HTTP 1.1 (or higher) GET, HEAD and OPTIONS requests (section 2.2).
  3. SHALL support HTTP Over TLS (HTTPS) (section 2.2)
  4. SHALL support CORS (section 2.2)
  5. SHALL be able to decompress an EPC binary string in accordance with GS1 Digital Link URI: Compression Technical Standard for EPC binary strings {EPCB] (section 2.3).
  6. If redirecting to another resolver, the redirecting GS1-Conformant Resolver SHOULD redirect the uncompressed URI (section 2.3).
  7. SHOULD extract and syntactically validate the GS1 identifiers in the request URI and SHALL report errors with an HTTP response code of 400 (section 0)
  8. If the request URI is a syntactically valid GS1 Digital Link URI, but the resolver has no information about the identified entity then it SHALL return a simple 404 Not Found response. (section 2.4.1)
  9. SHALL NOT use a 200 OK response code with a resource that indicates an error condition (section 0).
  10. SHALL respond to a query parameter of linkType set to linkset and/or a request with the HTTP Accept header set to application/linkset+json by returning a list of links available to the client application. The list SHALL be available as per Linkset: Media Types and a Link Relation Type for Link Sets [RFC9264]. The linkset SHALL validate against https://ref.gs1.org/standards/resolver/linkset-schema. If the request GS1 Digital Link URI includes one or more key qualifiers, any links associated with each level up to the primary key SHALL be included (sections 2.2, 2.9 and 2.5.10). The URI used as the subject of facts presented SHALL be the uncompressed version.
  11. All links in the linkset SHALL include the target URL (section 2.5.1), the link type (section 2.5.2) and a link title (section 2.5.3) and MAY include the human language(s) (section 2.5.4). If a media type is defined for a link, it SHALL be one defined by IANA (section 2.5.5).
  12. Links that are typed gs1:defaultLink or gs1:defaultLinkMulti SHALL also be described using a descriptive link type (section 2.5.8)
  13. When returning the linkset, the resolver SHOULD include an HTTP Link header pointing to a JSON-LD context file with a rel type of http://www.w3.org/ns/json-ld#context that itself should be served with a media type of application/ld+json. The context file SHOULD be declared in the resolver Description File (section 2.10).
  14. SHALL recognise one available link as the default for any given request URI (sections 2.2, 2.5.8). The default link SHALL NOT have any optional attributes (section 2.5.8).
  15. SHALL redirect to the default link unless there is information supplied in the request that can be used to make a better match.
  16. For any request URI, no matter how granular, there SHALL be a default link at the entry level or higher up the tree (section 2.5.9)
  17. SHALL redirect to the requested type of link if available (section 2.6.2).
  18. SHALL return a 404 Not Found message if a link of the requested type is not available (section 2.6.2).
  19. SHALL pass on all key=value pairs in the query string of the request URI (if present) when redirecting (section 2.12).
  20. SHOULD support use of the Accept-Language and MAY support Accept HTTP Request Headers (section 2.6.3), and the context keyword in the query string, to disambiguate between multiple links of the same linkType (section 2.5.6)
  21. SHALL provide a resolver description file at /.well-known/gs1resolver that SHALL validate against the schema at https://ref.gs1.org/standards/resolver/description-file-schema (section 3)
  22. The list of supported primary identifiers SHALL be provided in the Resolver Description File (section 2.5.9)
  23. Section 2.5.10 provides a series of closely related normative statements regarding permitted and prohibited combinations of key qualifiers for GTINs and ITIPs with which links can be associated, and how a resolver should process requests for those.
  24. SHALL recognise the GS1 Web vocabulary namespace and the prefix gs1: for link types. A resolver MAY recognise additional namespaces. If this is done, their preferred prefix(es) SHOULD be declared in the resolver Description File. Link types defined elsewhere SHALL NOT duplicate link types available from GS1 (section 2.14).
  25. SHOULD tolerate trailing slashes at the end of GS1 Digital Link URIs, i.e. the resolver SHOULD NOT fail if one is present (see section 2.13).

The glossary lists the terms and definitions that are applied in this document. Please refer to www.gs1.org/glossary for the online version.

Term Definition
Attribute The term 'attribute' has specific meaning in other GS1 standards. In this document, it refers to metadata about a link.
Content Negotiation Content negotiation is a mechanism for offering information in different data formats and different languages. When a user agent (such as a browser) makes an HTTP request, it sends along some HTTP headers to indicate what data formats and language it prefers. The server then selects the best match from its file system or generates the desired content on demand and sends it back to the client.
Dereferencing a URI The use of an appropriate access mechanism (e.g., Web request) to perform an action on the URI's resource (e.g., to retrieve an information representation via HTTP GET or to send data to a resource via an HTTP POST operation). Dereferencing a URI is often considered synonymous with making a Web request or 'looking up' a URI on the Web.
Domain name A domain name is an identification string that defines a realm of administrative autonomy, authority or control within the Internet. Domain names are formed by the rules and procedures of the Domain Name System (DNS). Any name registered in the DNS is a domain name. Domain names are used in various networking contexts and application-specific naming and addressing purposes. Domain names provide an abstraction layer that separates a registered name for an organisation or activity from the actual internet addresses (IP addresses) that provide its associated information services such as its Website, its e-mail server etc. The system that connects the domain names with the corresponding IP addresses is the Domain Name System (DNS).
GS1 Application identifier The field of two or more digits at the beginning of an element string that uniquely defines its format and meaning.
GS1 Application identifier data field The data used in a business application defined by one GS1 Application Identifier.
GS1 Element string A syntax for expressing GS1 identifier keys and attributes in a format using GS1 Application Identifiers and GS1 Application Identifier data fields.
GS1 Identification key A unique identifier for a class of objects (e.g., a trade item) or an instance of an object (e.g., a logistic unit).
GS1 Digital Link URI A Web URI conforming to the GS1 Digital Link URI syntax.
HTTP status codes The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
Identified entity The item, real or virtual, identified by the GS1 Digital Link URI
Key qualifier A granular identifier added to a primary key. See section 1.3
Linkset The complete list of links to resources related to the identified entity as defined by RFC 9246
Media Type (also known as MIME type or Content type) A two-part string identifier that indicates a data format as a pair of type and subtype, e.g., image/jpeg, image/gif, image/png, text/html, text/rtf Media types are sometimes also referred to as MIME types (MIME is an acronym of Multipurpose Internet Mail Extensions) or Content Types (after the HTTP header that indicates the Media type)
Resolver The term ‘resolver’ is not unique to GS1. It is the name for any service that accepts an identifier as input and responds in some way specific to that identifier.
Request URI The URI that is received and processed by the resolver. For a GS1-Conformant Resolver, the request URI follows the GS1 Digital Link URI syntax [DL-URI]
SGTIN (Serialised GTIN) A compound key formed from the combination of a GTIN [AI (01)] with Serial Number [AI (21)] which provides globally unique identification for every instance of a product. The term SGTIN appears in section 6.3.1 and 7.3 of the current GS1 Tag Data Standard, v2.0.0
Target resource The resource linked to from the resolver, identified by the target URL and described by the link metadata. Examples include web pages, APIs, files etc.
URI Uniform Resource Identifier. A string of characters used to identify a resource. The resource may be an information resource such as a Web page or a thing in the real world, such as a physical object, person or location. URIs refer to the superset of Uniform Resource Names (URNs), Uniform Resource Locators (URLs) and Web URIs (which can function both as globally unambiguous names, while also behaving like URLs by enabling intuitive retrieval of related information via the Web).
URI query string The query component contains non-hierarchical data that, along with data in the path component, serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.
URL Uniform Resource Locator (URL), a specific type of URI colloquially known as Web address. A URL is a URI starting with http or https .

References

[BCP47]
Tags for Identifying Languages. A Phillips, M Davis (Eds), IETF September 2006-2009, https://www.rfc-editor.org/info/bcp47
[BCP190]
URI Design and Ownership. M Nottingham, IETF June 2020 https://www.rfc-editor.org/info/bcp190
[BSR]
The GS1 Barcode Syntax Resource is a collection of assets that aims to help the GS1 user community to improve data quality and accurately convert between the different GS1 data syntaxes used with 1D and 2D barcodes in the GS1 system. https://ref.gs1.org/tools/gs1-barcode-syntax-resource/
[CORS]
Cross-Origin Resource Sharing. W3C Recommendation https://www.w3.org/TR/cors/ and WHATWG standard https://fetch.spec.whatwg.org/
[CURIE]
CURIE Syntax 1.0 A syntax for expressing Compact URIs. W3C Working Group Note 16 December 2010. Mark Birbeck, Shane McCarron https://www.w3.org/TR/curie/
[DL1.1]
GS1 Digital Link. Version 1.1.2 Mark Harrison, Phil Archer et al GS1 Ratified Standard, November 2022 https://ref.gs1.org/standards/digital-link/1.1.2/
[DLBP]
Best practices for creating your QR Code powered by GS1. Informal GS1 publication, 2023 https://ref.gs1.org/docs/2023/QR-Code_powered-by-GS1-best-practices
[DL-URI]
GS1 Digital Link: URI syntax. Version 1.4.0 Mark Harrison et al. GS1 ratified standard 15 June 2023 https://ref.gs1.org/standards/digital-link/uri-syntax/1.4.0/
[EPCB]
GS1 Digital Link URI: Compression Technical Standard for EPC binary strings Mark Harrison GS1 ratified standard July 2025 https://ref.gs1.org/standards/digital-link/compression/1.0.0/
[GS1 Identification Keys]
GS1 Identification Keys. https://www.gs1.org/standards/id-keys
[GENSPECS]
GS1 General Specifications Version 23.0.0 GS1 Ratified Standard January 2023 https://ref.gs1.org/standards/genspecs/23.0.0/
[GS1Voc]
The GS1 Web Vocabulary. https://gs1.org/voc/
[HTML LT]
HTML Living Standard. https://html.spec.whatwg.org/multipage/links.html
[IANA LR]
Link relations. https://www.iana.org/assignments/link-relations/link-relations.xhtml
[IANA MT]
Media Types. https://www.iana.org/assignments/media-types/media-types.xhtml
[ISO/IEC 15418]
ISO/IEC 15418:2016 Information technology — Automatic identification and data capture techniques — GS1 Application Identifiers and ASC MH10 Data Identifiers and maintenancehttps://www.iso.org/standard/67405.html
[ISO/IEC 18975]
ISO/IEC 18975:2024 Information technology — Automatic identification and data capture techniques — Encoding and resolving identifiers over HTTP https://www.iso.org/standard/85540.html
[JSON-LD]
JSON-LD 1.1 A JSON-based Serialization for Linked Data. Gregg Kellogg, Pierre-Antoine Chapman, Dave Longley. W3C Recommendation 16 July 2020 https://www.w3.org/TR/json-ld11/
[Linked Data]
Linked Data. Tim Berners-Lee 2006 https://www.w3.org/DesignIssues/LinkedData
[LMS]
GS1 Lightweight Messaging Standard for Verification of Product Identifiershttps://www.gs1.org/verification-messaging
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S Bradner. IETF March 1997 https://datatracker.ietf.org/doc/html/rfc2119
[RFC 2606]
Reserved Top Level Domain Names. D Eastlake, A Panitz. IETF June 1999 https://datatracker.ietf.org/doc/html/rfc2606
[RFC 2818]
HTTP Over TLS. M Rescorla. IETF May 2000 https://datatracker.ietf.org/doc/html/rfc2818
[RFC 6570]
URI Template. J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. IETF March 2012 https://datatracker.ietf.org/doc/html/rfc6570
[RFC 6761]
Special-Use Domain Names. S Cheshire, M Krochmal. IETF February 2013 https://datatracker.ietf.org/doc/html/rfc6761
[RFC 8288]
Web Linking. M Nottingham. IETF October 2017 https://datatracker.ietf.org/doc/html/rfc8288
[RFC 8615]
Well-Known Uniform Resource Identifiers (URIs). M Nottingham. IETF May 2019 https://datatracker.ietf.org/doc/html/rfc8615
[RFC9110]
HTTP Semantics, Section 15: Status Codes R. Fielding, M. Nottingham, J. Reschke. IETF June https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes
[RFC9264]
Linkset: Media Types and a Link Relation Type for Link Sets. Erik Wilde, Herbert Van de Sompel. IETF July 2022 https://datatracker.ietf.org/doc/html/rfc9264
[TDS]
EPC Tag Data Standard (TDS). Mark Harrison, Craig Alan Repec. GS1 ratified standard. February 2025 https://ref.gs1.org/standards/tds/
[TDT]
EPC Tag Data Translation Standard (TDT), Mark Harrison, Craig Alan Repec. GS1 ratified standard, February 2025 https://ref.gs1.org/standards/tdt/
[WebArch]
Architecture of the World Wide Web, Volume One. Ian Jacobs, Norman Walsh. W3C Recommendation 15 December 2004 https://www.w3.org/TR/webarch/

Acknowledgements

First Name Last Name Company
Shekhar Nambi (Chair) Johnson & Johnson PTE LTD
Eugen Sehorz (Chair) GS1 Austria
Phil Archer (Editor) GS1 Global Office
Adel Mounir Achir GS1 France
Matthew Andrews GS1 US
Albert Ang GS1 Global Office
Koji Asano GS1 Japan
Andrea Ausili GS1 Italy
Dieter Beitz CSB-System SE
Martin Beno GS1 Slovakia
Dana Benson GS1 US
Sven Böckelmann benelog GmbH & Co. KG
Emma-Michaela Brind GS1 UK
Scott Brown Syndigo
Terry Burton Terry Burton Consulting Ltd
Fabio Caldeira GS1 Brasil
Karolin Catela GS1 Sweden
Robert Celeste Center for Supply Chain Studies
Marjolein Christiaanse GS1 Netherlands
Luiz Felipe Coelho de Oliveira Lima GS1 Brasil
Brian Cook Polytag
Oscar Cruz GS1 Mexico
Karina Danielsson GS1 Sweden
Kevin Dean Dolphin Data Development Ltd.
Peta Ding GS1 Global Office
Deniss Dobrovolskis H&M group
Xiaowen Dong GS1 China
Jeanne Duckett Avery Dennison RFID
Hong Ngoc Duong GS1 Vietnam
Alexis Elloso GS1 Australia
Etinosa Emwanta GS1 Nigeria
Stefan Gathmann GS1 Ireland
Jean-Christophe Gilbert GS1 France
Nicole Golestani GS1 Canada
Robin Goossens GS1 Belgium & Luxembourg
Heinz Graf GS1 Switzerland
Dominique Guinard Digimarc
Haoyang Guo GS1 China
Dominik Halbeisen GS1 Switzerland
Jason Hale GS1 UK
Sara Halfmann Best Buy Co., Inc.
Mark Harrison Milecastle Media Limited
elio hbeich GS1 France
Andrew Hearn GS1 Global Office
Christopher-David Hudson DSM Austria GmbH
Tomi Ihalainen GS1 Finland
Yoshihiko Iwasaki GS1 Japan
Jia Jianhua GS1 China
Han Jie GS1 China
Kenneth Jørgensen GS1 Denmark
Steven Keddie GS1 Global Office
Kimmo Keravuori GS1 Finland
Alex Koerselman GS1 Netherlands
Thomas Kühne Goodstag GmbH (todo GmbH)
Ivo Ladenius GS1 Netherlands
Mehran Lamei GS1 Iran
Iker Larizgoitia Digimarc
Lorna Leaver GS1 UK
Piergiorgio Licciardello GS1 Global Office
Nicolas Liou GS1 Chinese Taipei
Sean Lockhead GS1 Global Office
Huiru Lou GS1 China
Marisa Lu GS1 Chinese Taipei
Wayne Luk GS1 Hong Kong, China
Yan Luo GS1 China
Ning Ma GS1 China
Natalia Macia Robert Bosch GmbH
Edward C Merrill GS1 Global Office
Joel Meyer Digimarc
Gena Morgan GS1 US
Mike Mowad Docuvera
Maju Nair GS1 New Zealand
steven nelson Tyson
Sophie Nicolas GS1 UK
Sergio Pastrana GS1 Mexico
Nicolas Pauvre GS1 France
Bijoy Peter GS1 India
Jiangfeng Qiu GS1 China
Matheus Qadros GS1 Brasil
Maximilian Rams GS1 Germany
Aruna Ravikumar GS1 Australia
Craig Alan Repec GS1 Global Office
Nicolas Resier GS1 Belgium & Luxembourg
Mohamed Riaz Solventum (previously 3M Healthcare)
Greg Rowe GS1 Global Office
John Ryu GS1 Global Office
Yuki Sato GS1 Japan
Sue Schmid GS1 Global Office
Karmik Shah Kevision
Xinyu Shi GS1 China
Daniel Skovgaard Larsen GS1 Denmark
Brandi Smith GS1 US
Tania Snioch GS1 Global Office
Jim Springer EM Microelectronic
Nathan Stonewall GS1 Sweden
Roman Strand GS1 Germany
Christa Suc GS1 UK
Xiaoyun Sun GS1 China
Claude Tetelin GS1 Global Office
Holger Thiemann atrify GmbH
Sonya Thomas Sam's Club
Angelina Tolbert GS1 US
Laurent Tonnelier mobiLead
Viet Tran GS1 Vietnam
Ralph Troeger GS1 Germany
Alec Tubridy GS1 Australia
Mark Van Eeghem GS1 Global Office
Jaco Voorspuij CONAS BV
Bob Vuppal GS1 Canada
Sten Walde GS1 Sweden
Chunguang Wang GS1 China
Lei Wang GS1 China
Di Wang GS1 China
Jiayi Wang GS1 China
Wenyu Wang GS1 China
Ethan Ward GS1 Australia
Dariusz Woaniak GS1 UAE
Huang Xin GS1 China
Ruoyun Yan GS1 China
Belle Yang GS1 Chinese Taipei
Xie Yi GS1 China
Ying Yu GS1 China
Yage Zhang GS1 China
Bo Zhou GS1 China

Log of Changes

Release Date of Change Changed By Summary of Change
1.0.0 Feb 2024 Phil Archer WR 23-186 Initial version
1.1.0 Feb 2025 Phil Archer WR-24-369 Relaxation of allowed methods to support template URLs in section 2.5.1. Normative reference to ISO/IEC 18975 added
1.2.0 Jan 2026 Phil Archer WR 25-207 Minor clarifications to address issues raised following development of the test suite. See the change log for details

This standard was originally part of GS1 Digital Link [DL1.1]. It is now a standard in its own right and its only connection to GS1 Digital Link is that the input to a GS1-Conformant Resolver is a GS1 Digital Link URI.

In terms of substance, the major change since GS1 Digital Link version 1.1 is the adherence to the work on Linksets at IETF that is now a full standard. The full list of available links is no longer required to be exposed in the HTTP Link header.

The preferred value to be used for the linkType parameter when requesting the linkset is now 'linkset'. The previous value, 'all', is deprecated but existing implementations are encouraged to continue to support 'all' until further notice.

If a specific type of link is requested that is not available, resolvers shall now respond with a 404 Not Found error message, rather than redirect to the default as specified previously.

Efforts have been made to clarify what metadata a resolver will require to describe each link and how a resolver should match that against information received as part of the incoming request. The link types of gs1:defaultLink and gs1:defaultLinkMulti have been introduced as part of this.

Rules around associating links with GTINs and GTIN qualifiers have been made significantly more comprehensive. See section 2.5.10.

The previous versions stated that, in addition to link types defined in the GS1 Web vocabulary, resolvers SHOULD also recognise relevant terms in schema.org. This has been removed although, of course, resolvers MAY use such terms.

Previous versions also allowed for resolvers to support alternative compression algorithms. This option has been removed.

The concept of a 'Class 2 Resolver' has been removed.

  • Section 2.5.1 relaxed to explicitly allow implementations to use any method to support template URLs.
  • Normative reference to ISO/IEC 18975 added to the introduction to Section 2
  • Section 2.3 decompression. Requirement to include an HTTP Link header pointing to uncompressed form with link type of owl:sameAs removed This change arises from the change made in version 1.0.0 to refer normatively to RFC 9264 (Linksets).
  • Sections 2.2 and 2.6. Need to include link to linkset, even when redirecting, removed (since there are well-defined methods for obtaining the linkset from any given input URI).
  • Section 2.3 Required support for decompression now limited to EPC binary strings. Support for other forms of compression is optional.
  • Section 2.5.4 Stating the human language of a target resource changed from SHOULD to MAY
  • Sections 2.5.4 and 2.5.6. Clarification that, if included in a link's description within a linkset, the values of the human language and context must be provided in an array, even if there is only a single value. Inclusion of the target resource's human language changed from SHOULD to MAY
  • Section 2.5.9. Clarification that resolvers SHOULD NOT use HTTP redirection to "walk up the tree, rather, the full linkset should be synthesised by the resolver and returned as a single dataset."
  • Section 2.8. When redirecting based on an MO or GCP prefix, the resolver MAY expose the target in the HTTP Link header (previously this was a SHALL).
  • Section 2.10. The linkset schema, published as an artefact at https://ref.gs1.org/standards/resolver/linkset-schema, is now normative. Likewise, in section 3, the schema for resolver description files is also now normative.
  • Section 2.12. The option to omit incoming query string parameters when redirecting to a target URL has been removed.
An upward facing chevron/arrow