How does a server read the identifier a tag mirrors into its URL?
As part of the requested address. A chip with mirroring writes its identifier, and on some chips its read counter, into the URL as hexadecimal characters, at a position chosen when the tag was configured. The server extracts them, checks their length and characters, and treats them as a claim about which tag was read, not as proof.
What reaches the server
The chip inserts the characters as the tag is read, so the phone receives a URL that already contains them, and the unique URL page explains why that makes identically written tags distinguishable. The server receives an ordinary request for that URL.
It receives it only if the phone opens the link. An iPhone that reads a tag in the background shows a notification that has to be tapped, and from Android 17 an Android phone shows one too, according to the Android behaviour page. A user who ignores it has read the tag without the server hearing of it.
The counter keeps its own account. On an NTAG213 it increments on the first read after the tag enters the field, according to its fiche on wakdev.com, whether or not a request follows, so gaps between the values a server receives are normal: the rolling codes page calls it drift.
Extracting the values
Where the characters land is decided when the tag is configured, by the mirror settings the chip's fiche describes. Place them in a named query parameter or a fixed path segment of the URL written to the tag, and parse the request by that name, not by counting characters from the start of the address.
The identifier of an NTAG213 is seven bytes, according to the same fiche, so it arrives as fourteen hexadecimal characters; its counter is 24 bits, six characters. A chip of another family has other lengths, and code takes them from that chip's fiche rather than from the first tag it met.
Validating before use
Anyone can type the URL, so the values are input like any other. Check the length and that every character is hexadecimal, compare without regard to case, and reject anything else before it reaches a database query or a log that someone will read.
A valid format says nothing about existence. Look the identifier up in the register of deployed tags, the record of which tag holds what, and treat an unknown identifier as unknown, not as a new tag to create.
Where the identifier belongs to an object a person carries, such as a badge, the record becomes data about that person, and the data protection page covers what follows.
Why it proves nothing
The mirrored identifier is readable by anyone who taps the tag, and the URL that carries it can be copied and replayed without the tag. The unique URL page says so plainly: it identifies rather than authenticates.
A plain counter adds little. A server that remembers the highest value seen for each identifier can reject an old URL replayed as is, but anyone can type a higher number, and someone holding the tag reads a fresh one, the limit the rolling codes page describes.
Proof needs a value the server can verify cryptographically. The NTAG 424 DNA inserts an AES CMAC derived from its identifier and a 24 bit counter, verifiable on the server side, according to its fiche on wakdev.com. How to verify it belongs to that chip's documentation, and what the verifier must hold to the verification page.
Frequently asked questions
Why do two requests carry the same counter value?
The same URL was opened twice without a new read, by a reload or a copy of the link. A new read of the tag would have produced a new value.
Why does the counter jump between requests?
The tag was read without the link being opened, and the counter increments on every read. The rolling codes page calls this drift.
Is the mirrored identifier unique?
It is the factory identifier, meant to be unique within the manufacturer's allocation, and readable by anyone. It identifies a tag, it does not authenticate one.
Can a server tell a genuine tag from a copied URL?
Not with a plain mirror. It takes a chip that inserts a cryptographic value, such as the CMAC of the NTAG 424 DNA, and a server that holds the key.