In short
The App reads any NFC tag you hold to the phone and tells you what is on it — the records it carries, how much of its space is used, whether it can still be rewritten, and, when it is a Linxy tag, which Mark it opens. Reading changes nothing on the tag.
The line worth looking for is the one about the app record. A Linxy tag written without it still works, but an Android tap on it offers a list of browsers instead of opening Linxy. That defect is invisible to whoever wrote the tag and only shows itself as hesitation at the moment somebody taps it. Reading the tag is the way to catch it before the batch goes out.
On this page
What a reader can see
An NFC tag holds a short message made of one or more records. Each record has a type and a payload, and a phone decides what to do with the tag by looking at them. The App lists every record it finds, naming the ones it recognizes — a link, a Linxy code, an app record, a piece of text — and listing anything else by its raw type and size. Nothing is hidden and nothing is interpreted away.
When one of those records carries a Linxy code, the App takes the extra step the desktop encoder cannot: it asks the platform which Mark that code opens, and shows you the Mark by name. The lookup is the same public one a tap performs, so it will resolve a live tag whether or not the tag is yours. A code that has been revoked, or that the platform has never heard of, resolves to nothing — which is precisely what a dead tag ought to look like.
Where the tool is, and how to use it
The NFC tools live under More Tools → NFC Tags, not on a Mark. Reading a tag has nothing to do with any particular Mark, so it does not sit inside one. There are three tools on that screen: read a tag, write a Linxy tag, and write a standard tag.
- Open Read a tag. On an iPhone the system scan sheet appears; on Android there is no sheet.
- Hold the tag flat against the top back of the phone. That is where the aerial is on almost every handset.
- The phone gives a short buzz when it has the tag, and the result appears.
- Read another tag starts the next one. Done closes the screen.
The five verdicts
| What you see | What it means | What to do |
|---|---|---|
| This tag is blank | The tag is readable and holds no records | Nothing is wrong. It is ready to be written |
| Opens … and a Mark name | A Linxy tag whose code the platform resolved | Nothing. This is a working tag |
| Linxy tag — code not recognized | A Linxy code the platform will not resolve: revoked, or belonging to a record that no longer exists | Expected for a revoked tag. Write the tag again to bring it back into use |
| Standard NFC tag | A valid tag that is not a Linxy tag. The link it holds is shown underneath | Not an error, and not treated as one |
| Couldn’t read the tag | A genuine read failure — the tag left the field, or the scan session ended for a reason other than you cancelling | Try again, holding the tag still |
Only the third of these is shown in a warning tone. A tag that belongs to someone else, or that was written by a different tool entirely, is reported neutrally, because there is nothing wrong with it.
The app record, and why it is the one to check
Android decides which application handles a tapped tag by looking at what is on the tag. A plain web address is claimed by every browser installed, so the system offers a chooser. An app record names one application outright and outranks all of them, which is what makes a Linxy tap open the App directly, with no list and no second decision.
For every Linxy tag it reads, the App reports one of two lines: that a tap opens Linxy straight away, or that the tag has no app record and an Android tap will offer browsers instead. The second is not a fatal defect — the destination is still reached — but it costs a person a decision at exactly the moment you least want one, and it is why old tags and tags written by third-party utilities feel worse than they should.
Space, capacity and whether the tag is still rewritable
Two figures are shown under the records.
| Figure | What it tells you |
|---|---|
| Space used | Bytes in use against the tag’s total, when the tag reports one. Where it does not, only the bytes in use are shown |
| Tag | Rewritable or Locked. A locked tag was sealed read-only at some point and can never be changed or erased again, on any device, by any application |
Capacity is worth a glance when you are planning what to put on a tag rather than diagnosing one. A contact card or a Wi-Fi record is far larger than a link, and the difference between a small tag and a large one decides whether the content fits at all.
Erasing a tag
Erase this tag is offered only when the tag has something on it and is still rewritable. A locked tag is never offered the option, and a blank one has nothing to remove. The App asks for confirmation first, and the wording of that confirmation carries the important point: the tag goes blank and stops opening anything, but the code it held stays valid, so it can be written onto another tag.
Technically, a tag cannot be made to hold nothing at all, so erasing writes a single empty record instead. The practical result is the same: the tag holds no destination, opens nothing, and reads as blank. A locked tag refuses the operation outright and says so.
Why iPhone and Android feel different here
The two platforms hand tags to applications in fundamentally different ways, and the App works with each rather than pretending they are the same.
| iPhone | Android | |
|---|---|---|
| What appears | The system scan sheet, over the App | Nothing. The screen you are on stays visible |
| After each tag | The sheet closes with a success or failure message, and the result is revealed underneath | The result appears immediately; the session stays open |
| Reading several tags | A fresh session per tag, opened for you | One session for as long as the screen is up |
| Tapping a tag while the screen is open | Handled by the sheet | Deliberately does not open the tag’s destination |
That last row is the one that surprises people. On Android, holding the reader session open is what stops the operating system grabbing the tag and throwing you into the Mark viewer — out of the very screen you were using. It is a deliberate suppression, and it lasts only while a tag screen is on top.
On iPhone, a scan session takes a moment to release after it closes, and a new one opened too quickly simply never sees anything. The App waits that release out and quietly re-arms if it happens anyway, which is why there is a brief pause between asking for the next tag and the sheet appearing. That pause is the fix, not a delay.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Holding the tag does nothing | The tag is not over the aerial | Move it slowly across the top third of the back of the phone |
| NFC is off | NFC is disabled at the phone level | Turn it on in the phone’s settings and come back |
| A Linxy tag reads, but says the code is not recognized | The code was revoked, or the record behind it no longer exists | Expected for a revoked tag. Write the tag again to reuse it |
| The App jumps to the Mark instead of showing the result | You left the reader screen with the tag still against the phone | Lift the tag off before leaving the screen |
| Erase is offered on one tag and not another | The other tag is locked, or already blank | Locked tags can never be erased. Replace them |
| The erase seems to hang on Android | The tag never left the field, so it was not re-discovered | Take it off the phone, then touch it again |
| Records listed as unknown, with only a byte count | Written by another tool in a format the App does not name | Not an error. The tag is intact and other readers will still handle it |
| Reading works, then stops until the App is restarted | A previous scan session had not finished releasing | Largely handled now. If it persists, close the screen and open it again |
Things people commonly get wrong
Related reading: Writing an NFC tag, Secure NFC and standard NFC compared, Scanning with the App, My Linxy items, and When something is not working.