Can a phone read the tag inside a library book?

The same family a phone reads

Libraries settled on vicinity cards, ISO/IEC 15693, because a gate has to read a tag inside a cover as a person walks through, and the vicinity card page covers why that band suits the job. The NFC Forum adopted the same family as Type 5, which the tag types page lists.

So a phone meets a library tag as an ordinary tag it supports, not as something foreign. That is the opposite of a race timing chip, which lives in another band entirely and which no phone will ever read.

What a phone does not get is the distance. The standard was designed around a large fixed antenna, and a phone brings a small one, so the tap is a tap. The gate reads at a metre because the gate is a metre wide.

Blocks, not a catalogue record

A library tag is not written in NDEF, so nothing on it is a web address and nothing opens a page. It holds a unique identifier fixed at manufacture and a small block of memory written by the library system.

What that memory contains is set by a library data model rather than by the NFC specifications: an item number, the owning library, sometimes a part number for a multi volume set. A phone application that does not implement that model shows the raw bytes, which is what most people see when they try.

The item number is not the title of the book. Turning one into the other needs the library's catalogue, which is the library's, and that separation is deliberate.

The byte the gate reads

Vicinity cards carry a one byte application family identifier, and it is more useful than it sounds. The Android NFC stack and its command definitions show the whole mechanism: an inventory command can be sent with the application family identifier present, so that only tags carrying that value answer, and two separate commands write it and then lock it against further change.

A reader can therefore sort a population of tags by a single byte without reading any memory, and a gate can decide whether an item should be leaving the building without asking a database anything.

The same response also reports a data storage format identifier, which tells a reader how the memory is organised. Between the two bytes, a gate knows what it is looking at before it reads a block.

Which is why the security function of a library tag is not a separate strip or a second chip: it is a value in the tag, changed when the item is issued and changed back when it comes home.

What not to do with a library tag

Do not write to it. A phone can write to a Type 5 tag whose memory is not locked, and a borrowed book is not yours to reformat: rewriting a block, or the application family identifier, takes the item out of circulation until a librarian repairs it. The locking page explains why the damage is not always reversible from your side.

Reading is another matter, and it is where the profession's long standing privacy concern sits. A tag answers whoever brings a reader near it, so an item identifier in a bag can be read by someone standing beside you, and the tracking page sets out what that does and does not allow.

The defence is the one described above: the tag carries a number rather than a title, and the borrower is nowhere on it. What a stranger learns is that an item exists, not what it is or who has it.