Hardware
TesterNFC Tester
Test NFC tags in your browser using Web NFC API. Read and write NDEF records (text, URI), lock tags to read-only mode. Works on Chrome Android with HTTPS only.
Have feedback? Report bugs, suggest features, or share your thoughts — we read them allAbout NFC Tester
Test and interact with NFC tags directly in your browser using the Web NFC API (NDEFReader). Read NDEF records including text and URI data, write new NDEF records to tags, and lock tags to make them permanently read-only. Perfect for NFC developers, IoT projects, and testing contactless tags on Android devices.
How to use:
- Ensure you're using Chrome 89+ on Android with HTTPS enabled.
- Tap 'Read tag' and bring your Android device close to an NFC tag to read its NDEF records.
- View tag information including type, ID, serial number, and all NDEF records (text, URI, MIME).
- To write data, select the record type (text or URI), enter your content, and tap 'Write to tag'.
- Bring your device close to a writable NFC tag to write the new NDEF record.
- Use 'Lock tag' to make a tag permanently read-only (warning: this cannot be undone).
- Monitor all operations in the activity log at the bottom.
Browser Compatibility
- Chrome for Android 89+: Full support
- Edge for Android: Supported (Chromium-based)
- Desktop browsers (all): Not supported
- Safari/Firefox: Not supported
- HTTPS required for security (top-level frames only)
- User gesture required to initiate NFC operations
Technical References
- MDN Web NFC API: https://developer.mozilla.org/en-US/docs/Web/API/Web_NFC_API
- Chrome for Developers - Web NFC: https://developer.chrome.com/docs/capabilities/web-apis/nfc
- Web NFC Specification: https://w3c.github.io/web-nfc/
- NDEF Format Specification: https://nfc-forum.org/our-work/specification-releases/specifications/nfc-forum-assigned-numbers-register/
Frequently Asked Questions
The tool uses the Web NFC API to read and write NDEF (NFC Data Exchange Format) records on passive NFC tags such as NTAG213, NTAG215, NTAG216, MIFARE Ultralight, and many ISO 14443A tags. When you tap a tag against the back of your phone, the browser exposes the records inside it — typically text, URI, or MIME payloads. You can also write your own records and optionally lock the tag to read-only permanently. The tool does not perform card emulation (it cannot pretend to be a credit card or transit pass) and it does not support reader/writer operations on more advanced cryptographic tags like MIFARE DESFire or ISO 14443B contactless smart cards, because Web NFC is intentionally scoped to NDEF.
NFC tags are inexpensive (about 10–50 cents each) and increasingly used in retail tags, business cards, smart posters, home automation triggers, museum exhibits, and product authentication. Testing matters because tags ship from many vendors with varying memory sizes, write protection states, and pre-loaded data. Before deploying tags in production you want to verify capacity (NTAG213 has 144 bytes of user memory, NTAG216 has 888 bytes), confirm the tag accepts your NDEF payload, and check that the device you want to support actually triggers on tap. Testing also helps debug failures: a tag that "stops working" may simply have been locked accidentally, run out of memory, or have a physically damaged antenna.
Three properties dominate: memory capacity, scan reliability, and form factor. NTAG216 with 888 bytes of user memory holds long URLs, vCards, or several records; NTAG213 with 144 bytes is fine for short URLs but will reject larger payloads with a write error. Scan reliability comes from antenna size — bigger circular antennas (≥25 mm) read at a longer distance and tolerate tag misalignment, which matters for posters and product packaging where users will not perfectly align their phone. Form factor (sticker, key fob, plastic card, wristband) affects durability and price. For everyday testing and prototyping, NTAG215 (504 bytes) is a sweet spot — it stores roughly one vCard or a long URL and is widely supported by Amiibo-style applications.
Three common causes. First, the URL may be too long for the tag — anything over your tag's user memory minus NDEF overhead (typically 10–20 bytes) will be truncated or rejected. Second, the tag may have been written but not locked, and a subsequent failed write attempt corrupted the records — re-write a clean URI record and try again. Third, your phone may have NFC disabled, may be in airplane mode, or the tap may not align with the NFC coil. iPhones (XS and newer) read NDEF tags in the background only when the screen is on and unlocked; older iPhones require the Shortcuts app. Android phones generally read tags whenever the screen is on, but battery savers can disable NFC in some power profiles.
NDEF defines a small set of "well-known" record types. Text (TNF=1, type "T") contains a language code and a UTF-8 string — best for short human-readable notes that should not auto-trigger any app. URI (TNF=1, type "U") contains a single URL or other URI and is what triggers most automatic actions: tapping a URL tag on a modern phone usually opens the browser without prompting. MIME-media (TNF=2) lets you embed any MIME-typed payload, such as application/json or image/png, useful when a specific app is registered to handle that MIME. Smart posters (TNF=1, type "Sp") wrap a URI with a title and an action hint. For most consumer use cases, the URI record is what you want — text records are largely silent on iOS.
Locking writes a one-way fuse bit in the tag's configuration memory that permanently prevents further writes. After locking, the tag becomes read-only and no NFC reader can ever modify its content — not yours, not anyone else's, not even the manufacturer. You should lock tags that you ship to end users or place in the wild (museum exhibits, product authentication, lost-and-found stickers) so that a malicious passerby cannot overwrite your URL with a phishing link. You should not lock tags during prototyping because mistakes are unrecoverable. Some tags also support "password protection" via a 4-byte PWD plus 2-byte PACK on NTAG21x, which gives reversible read or write protection without burning the lock bit — useful for tags that must be updatable in the field but resistant to casual tampering.
Support is uneven. Android Chrome 89+ on phones with NFC hardware supports full Web NFC for read and write — this is the primary target platform. iOS Safari does not implement Web NFC at all; iPhones read NDEF tags only through native iOS apps or the built-in background reader, which opens URLs but cannot expose them to a website. Desktop browsers have no Web NFC support because PCs lack NFC hardware. The Web NFC spec also requires HTTPS context (or localhost during development), and the user must grant permission per origin on first use. If your testing target is iOS users, plan to also publish an iOS app or rely on the built-in tag handling for plain URLs.
NFC is a subset of HF (high-frequency) RFID operating at 13.56 MHz, governed primarily by ISO/IEC 14443 (proximity cards) and ISO/IEC 15693 (vicinity cards), plus the NFC Forum tag types 1–5. NFC adds peer-to-peer mode and card emulation on top of plain RFID reader/writer functionality, although Web NFC only exposes the reader/writer mode against NDEF. Common consumer tags are NFC Forum Type 2 (NTAG21x family from NXP, ISO 14443A); Type 4 (DESFire, used in transit) supports stronger crypto; Type 5 (ISO 15693, ICODE SLIX) reads at greater distance and is used in libraries and inventory. UHF RFID (860–960 MHz, EPC Gen2) is a completely different protocol used in supply chain and is not addressable from phones.
CONNECTIVITY5
WUTOOLS