In short
The Linxy NFC Encoder is desktop software for Windows and macOS that writes NFC tags from a USB reader on your desk. It writes the same two kinds of tag as the phone — Linxy tags carrying revocable platform codes, and standard tags carrying ordinary NFC content — but it is built for the run of two hundred, not the run of two: place a tag, watch the confirmation, place the next.
The part that matters is that nothing about the tag changes with the tool. A tag written at the desk is byte-for-byte the tag the phone would have written, resolved by the platform the same way, revocable one code at a time from the same place.
The encoder is available on request for accounts whose plan includes it. If yours does, ask us and we will get it to you with the reader details below.
On this page
When the desk beats the phone
The phone writer in the App is the right tool for a handful of tags written where you stand. The encoder is the right tool when tags are a production step: a stack of blanks, a label printer beside them, and an afternoon of placing, confirming and removing. The reader holds the tag flat and still — the two things a hand-held phone is worst at during a write — and the activity log keeps a running record of every UID written, so the question “did tag forty-one actually take?” never depends on memory.
| Phone (Linxy App) | Desk (NFC Encoder) | |
|---|---|---|
| Best at | A few tags, anywhere | Runs of tags, at a bench |
| Hardware | The phone itself | USB reader (ACR1252U or any PC/SC-compatible) |
| Batching | Codes reserved in advance, written one by one | Same — pre-generate a batch, then place tag after tag |
| The tag it produces | Identical. Same records, same platform resolution, same revocation | |
What sits on the desk
The encoder runs on Windows and macOS and drives the ACR1252U USB reader/writer, or any PC/SC-compatible contactless reader. It writes the NTAG family: NTAG213 (144 bytes usable), NTAG215 (504 bytes, the recommended tag), and NTAG216 (888 bytes); a single write tops out at 504 bytes of content. Place a tag on the reader and it is read automatically — UID, tag type, memory size and every record it carries appear in the activity log before you decide anything.
Writing Linxy tags: connect once, then batch
Linxy tags need the platform, because that is where the codes come from. Setup happens once: the platform address, an API key from Linxy Designer, and the Mark ID from the mark’s edit page. A connect check confirms the credentials before any tag is touched.
From there, two speeds. Generate & Write mints one code and writes it to the tag on the reader. Batch pre-generates a run of codes, then walks the stack: place a tag, it takes the next code, confirm, remove, place the next. Every tag gets its own code, which is the whole point — any single tag can later be revoked from Linxy Designer without touching the rest of the run.
The order of operations is the same one the App uses: codes exist on the platform before a single tag is written. A batch interrupted halfway wastes nothing; the unwritten codes stay yours.
Standard tags, eleven kinds
The Standard Write side needs no account and no platform. It writes the ordinary NFC records any phone understands: a web address, plain text, a phone number, an email, an SMS, a Wi-Fi network, a contact card, a geolocation, a social profile (with ready-made patterns for X, Instagram, Facebook, LinkedIn, TikTok and YouTube), a custom URI for launching a particular app, and raw NDEF bytes for the cases nothing else covers.
Everything said about standard tags elsewhere still applies here: the content is on the tag, it is final once written, and changing it later means having the tag in your hand. See secure NFC tags and standard NFC tags for choosing between the two.
Erase and the one permanent act
Erase wipes a tag back to blank and it can be rewritten immediately — the normal way to recover a mis-write or repurpose old stock. Lock is the opposite kind of act: it sets the tag permanently read-only, it cannot be undone by anyone, and the encoder asks twice before doing it. Lock only final production tags, and only when you are certain the content will never need to change — which, for a Linxy tag, is a reason not to lock at all, since its value is precisely that the destination can move.
Symptoms, causes and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| No NFC readers found | USB connection, or missing driver on Mac | Reseat the cable, try another port; on macOS install the ACS driver, then re-detect |
| No tag detected | Tag placement, or an incompatible tag | Center the tag flat on the reader; try another tag from the batch |
| Write failed | Tag is locked, or too small for the content | A locked tag cannot be recovered; for size, erase first or use a larger NTAG |
| Tag reads as corrupt | A tag was removed mid-write | Erase the tag and write it again |
| Transmit error mid-run | Tag lifted during the operation | Re-detect the reader and rewrite that tag; the code is not lost |
Things people commonly get wrong
- Treating the desk tag as a different product. It is not. The encoder writes the same records the App writes; a scanner cannot tell them apart, and the platform does not care which tool wrote the code.
- Guessing the batch size low. Codes are reserved, not consumed. Generate the full run; unwritten codes wait.
- Locking Linxy tags. The revocable code is the valuable half of the arrangement. Locking protects the wrong thing.
- Skipping the read. The encoder reads every tag it touches. Look at the log before a batch ships — it is the last moment a defect is cheap.
- Removing a tag at the first sign of life. The confirmation is the finish line, not the first flicker in the log.