What actually happens when somebody scans the code
Four things happen, in a fixed order. A carrier is read, an address comes out of it, a service matches the identifier inside that address and a redirect is issued to a target somebody chose in advance. Only the last step is governed by a standard, and it is a resolver standard rather than a passport standard. The five things that standard does not specify are the more useful half of this page.
On this page
The short answer
Four things happen, in that order, every time. A device reads the carrier. The carrier yields an address. A service matches the identifier inside that address against something it holds and answers with a redirect to a target address that somebody chose in advance.
Only the last of those is governed by a standard, and it is a resolver standard rather than a passport standard. Most people arguing about what the code does have not read it. It says what the service must do when it is asked, what it must say when it holds nothing and what it must never do. It says very little about what sits at the target address, and nothing whatever about whether the party answering is entitled to.
The rest of this page works that out layer by layer, then spends its second half on what the standard leaves open. If you are here because a supplier has described a resolver as the intelligent part of a passport programme, the section on the three context axes is the one to read. A worked example of what a scan actually lands on, row by row, is on the annotated passport.
Four layers, routinely collapsed into one
Almost every argument about this subject is conducted with a single noun. Somebody says the QR code and means four separable things at once, and a decision about one of them then gets made on the strength of a point about another. The four are an identifier, an address, a carrier and a resolver. They fail in different ways, cost different amounts and belong to different people.
Keeping the four apart matters because three of them cannot be revised. Ink, geometry and a printed number are fixed at the moment the label is made, and the garment carrying them is in somebody's wardrobe years later. Only the resolver can be changed afterwards, which is exactly why it ends up absorbing every problem the other three created.
What an identifier has to do before any of this works, and how many of them a catalogue needs, is set out on identifiers. This page does not repeat it.
One question about that first layer stays open here, and it is worth flagging because a good deal of planning rests on the answer. Whether an identifier that has already been printed onto goods in circulation may ever be reused, and if so after what period and on what conditions, is governed by the numbering scheme's general specifications. We have not read those against their current release. Statements in absolute terms appear elsewhere on this site and were never confirmed, so the honest position today is that this is not established rather than settled either way, and we record it as an open check. How the estate handles a question in that state is set out in how we know.
What the framework asks, and what it does not name
The framework requires identifiers issued in accordance with internationally recognised standards. It names no scheme in the identifier provisions we read, and it names none in the definitions either. That is a smaller statement than it sounds and a considerably more useful one.
A numbering scheme in wide commercial use is a strong candidate for satisfying a requirement written that way. Being a strong candidate is not the same as being named. Anybody telling you that the law requires a particular family of number is describing a market position as though it were a provision, and the correction is available in the text itself.
There is a second thing the framework does not do. It does not specify the resolver at all. The obligation to keep the passport reachable falls on an economic operator, and how that reachability is engineered is left to standards and to whoever operates the service. What a claim of conformance to a published standard is actually worth, and what it is not, is set out on standards and conformity.
The route that is not a scheme
Because the framework names no scheme, there is a route to a compliant identifier that does not begin with joining one. It is written about far less than it deserves.
An international standard already covers the encoding and resolution of identifiers over HTTP. Its published scope describes a structure that is simultaneously an address and a composition of identification properties, support for identifiers that do not depend on the domain name they happen to be served from, and a common interface for querying online services about identified items. That is the same architectural pattern, lifted out of one organisation's governance and placed under a standards body.
We have confirmed that the standard exists and read its catalogue scope. We have not read the document. Nothing on this page describes a requirement inside it, and nothing here should be used to argue that it is equivalent to anything else until somebody has read both.
A correction the estate owed its readers
That international standard is a resolver and identifier encoding standard. It is not a product passport standard, and it has been described as one on surfaces including our own. What is actually being claimed when somebody invokes it is resolver conformance, which is real, narrower and a perfectly good thing to claim. It is simply a different claim, and the difference is the sort a procurement conversation ought to be able to survive.
What a conformant resolver must do
The resolver standard sets out a short list of required behaviours. None of them is exotic. All of them are checkable from outside the service by somebody with a browser and ten minutes, which is what makes this list useful in a procurement conversation rather than merely interesting.
- Secure transport. Requests are served over HTTPS.
- Cross origin support, so that a client running in a browser can call the service rather than only a server being able to.
- A defined set of HTTP methods, rather than whatever the implementation happened to expose.
- Two different errors for two different failures. One response for an address that is malformed, and a different response for an address that is well formed but names an entity the resolver does not hold. A service that gives the same answer to both cannot be told apart from a template.
- Never a success response for an error. A page reading nothing found, served with a success status code, is a failure wearing the costume of an answer, and it defeats every automated check downstream of it.
- A published description of itself at a well known location, so that a client can discover what the service supports without asking anybody at the vendor.
Two smaller findings sit alongside those. The convenience path forms that once shortened an address have been deprecated and then removed, so an address that depends on one is depending on something the standard no longer carries. And compression is a separate standard whose own text confines it to closed systems, which makes a compressed address a poor choice for a code that a stranger has to be able to read.
What this page is not doing
Everything above describes what the resolver standard requires of any conformant service. It is not a description of how this business resolves anything. We make no claim on this page or anywhere else on this site that our own resolver conforms to that standard, because we have not established it.
There is one thing about these standards we cannot tell you, and it comes up often enough to be worth stating plainly. What changed between recent releases of either the address grammar or the resolver standard is not established by us: the served pages truncate before the change logs, so we have read the current requirements and not the history behind them. Anybody describing a recent release as a major architectural change should be asked to produce that change table. It either exists or it does not, and finding out takes about a minute.
What a conformant resolver cannot do
This is the half of the page worth keeping. Five things the resolver standard does not specify, each of them established by reading the standard rather than inferred from a summary that stayed quiet about them. They are stated here as absences, not as complaints.
| The absence | What is not in the standard | What follows from it |
|---|---|---|
| No trust model | Nothing verifies that the party operating a resolver is the legitimate holder of the identifier it answers for. | A resolution is a redirect. It is not an assertion that the record at the far end is correct, and not an assertion that whoever serves it was entitled to. |
| No continuity or retirement protocol | There is no specified procedure for handing a resolver over, winding one down or retiring the addresses it used to answer. | What happens when the operator stops is a contractual question rather than a standards question. When the link dies takes that apart. |
| No caching guidance at all | The standard offers none. Not a recommended lifetime, not a rule for intermediaries, not a statement that the question is out of scope. | A mechanism widely expected to convey something time sensitive, a recall state being the obvious case, has no specified answer to how long anything in the path may keep serving a previous redirect. |
| Query strings largely out of scope | The query string sits largely outside the standard's scope, and the whole string is transmitted onward by default. | Convenient where the string carries harmless context. Poor where the address carries a batch number or a serial, because that value then travels to the target and to anything sitting in between. |
| A dead end rather than a fallback | Where a client asks for a link type the resolver holds nothing for, the specified outcome is a dead end rather than a graceful fallback. | A recycler asking for end of life handling receives nothing rather than something irrelevant. That is the honest behaviour, and it means any fallback has to be designed by the operator rather than inherited from the standard. |
None of that is a criticism. A resolver standard that also tried to settle trust, continuity and caching would be a far larger document and probably an unusable one, and the drafters were plainly deciding where the boundary sat rather than overlooking five things.
What follows is only this: these questions are open at the standard layer. They get answered by a contract, by an operator's published policy or not at all. A buyer who assumes a conformance claim has covered them is buying an assumption, and the five rows above are the cheapest way to find out which of the three applies.
Three context axes, and everything sold beyond them
A conformant resolver is required to understand exactly three things about what a client is asking for: the link type, meaning which kind of target the client wants; the requested language; and the requested format. That is the whole set.
3
context axes a conformant resolver is required to understand
Link type, requested language and requested format. The parameter that would carry anything else has an explicitly undefined value space, and no resolver is obliged to support it. Read at the reference site, not the marketing site.
SourceGS1 conformant resolver standard, at the reference siteChecked 28 August 2026
Anything beyond those three axes is a private convention between one resolver and one client. That is not a prohibition and it is not a defect. It is a description of what conformance covers, and it means two equally conformant resolvers can behave completely differently the moment a request carries anything else.
This is the cleanest finding on the page, and it is the one that does the most work in a sales meeting. A pitch built on resolution that varies by shopper, by store, by campaign or by time of day is a pitch about something the standard does not reach. It may still be a good product. It is not conformance, and it should not be sold as though the standard had blessed it.
We publish no claim that context varying resolution is happening in production anywhere. We have not identified any named and verified deployment doing it. The one live example we looked at is a demonstration rather than a shipped consumer path. That is a statement about what we found and where we looked, not a statement that none exists.
Where dynamism actually belongs
The design intent is visible in the vocabulary itself. The thing the standard makes stable is the link type. The thing it leaves free is what sits behind the link type.
So the architecture that survives contact with a printed label pushes the changing part to the target rather than into the resolution. A resolver holds a small and stable map from an identifier and a link type to a target address. The target address then serves whatever the moment requires, and it can be rebuilt, relocated or rewritten without anybody touching the map.
That arrangement has two properties worth paying for. The redirect stays cacheable and testable, which is what you want from the one part of the chain that has been printed and cannot be changed. And every change of behaviour then happens inside a system you can deploy on a Tuesday, rather than inside a mapping that was fixed onto a garment years earlier.
The inverse arrangement, where the resolver itself decides what the shopper sees, moves the volatile logic into the layer with the longest life and the least tooling. It also makes the service harder to hand to anybody else, which is a problem that only becomes visible at exactly the wrong moment.
A resolver does produce a record of what was asked for, and that record is a good deal less informative than it looks in a proposal. What a scan does and does not evidence is taken apart on what a scan tells you.
Five questions to ask a vendor
Each of these has a checkable answer. Not a persuasive answer, a checkable one: you can verify four of the five yourself, from outside, before the second meeting.
- Which release of the resolver standard do you implement, and where is your published description of the service? The description belongs at a well known location. Go and fetch it. If there is nothing there, the answer to the first half of the question stops mattering.
- What do you return for a well formed address naming an identifier you do not hold? Ask them to demonstrate it live. You are looking for a not found, carried by a not found status code. A branded page served with a success code is a specific answer, and it is the wrong one.
- What happens when a client asks for a link type you hold nothing for? Checkable the same way, using a link type they do not carry. A redirect to whatever page exists is the failure mode that quietly hands a recycler a marketing page.
- Which context axes do you act on beyond link type, language and format? Any answer naming a fourth is describing behaviour outside the standard. That may be a fine product decision. It is not conformance, and the proposal should not present it as though it were.
- Who operates the resolver and who owns the domain, and what happens to both if you stop trading? The standard specifies nothing here, so the answer lives in a contract or nowhere. Get it in writing and keep it beside your exit clause.
A vendor who answers all five without reaching for a slide is worth taking seriously, whatever scheme they have chosen. A vendor whose answers arrive as adjectives is telling you something useful too.
You might want to read next
Sources
Two of the standards below are published by the organisation that runs a numbering scheme, and a publication guard governs whether such a specification may be cited here. They appear because they are registered with a read depth, which is the accepted alternative to that guard: the page states how far each was read rather than leaning on the fact of citation. Both were read at the organisation's reference site and never at its marketing site, because on the day of reading the marketing site was two ratifications behind the reference site on the same standard.
-
StandardRelevant provisions reviewed
The load bearing source on this page. Read at the reference site for the behaviours a conformant resolver must exhibit, for the three standardised context axes, and as an absence for the five things it does not contain. What changed between recent releases is not established, because the served pages truncate before the change logs.
-
StandardOfficial source confirmed, detailed review pending
The address grammar that carries an identifier. Named here so that the address layer can be distinguished from the resolver layer. The address resolves and release 1.7.0 was ratified in August 2026; the document itself has not been read, so nothing on this page describes a requirement inside it.
-
ISO/IEC 18975, encoding and resolving identifiers over HTTPInternational StandardOfficial source confirmed, detailed review pending
The international standard on encoding and resolving identifiers over HTTP. Cited for its existence and its published scope only, which is all its read depth supports. It is on this page because it is a resolver standard rather than a passport standard, and that distinction is a correction the estate owed its own readers.
-
Arts. 9, 10, 11, 12CELEX 02024R1781-20240628In forceRelevant provisions reviewed
Read at the consolidated text for the identifier and data carrier provisions. Used here for one proposition only: that identifiers are to be issued in accordance with internationally recognised standards, and that no scheme is named in the provisions read. Annex III, which those provisions cross refer to, was not readable.
Help someone else make sense of product passports.