Hold a phone near a sticker and a web page opens, with no battery in the sticker and no app to install. The mechanism is well defined, and understanding it is the difference between a tap that works on every phone in a pilot and one that quietly fails on half of them. This explainer covers the physical link, the data format a phone actually reads, and the specific ways iPhone and Android differ, so you can specify a tag that behaves the same in every hand.
For the tags themselves, see our NTAG213 NFC labels; if you need to hand encoding to a supplier, our RFID encoding service page sets out what to agree first.
Table of Contents
The physical link, in plain terms
Near Field Communication runs at 13.56 MHz. The phone is the active device: its coil generates an alternating magnetic field, and when a tag comes within a few centimetres, that field induces a current in the tag’s antenna. The current powers the chip, which replies by switching a small load across its own antenna, a technique called load modulation that the phone decodes as data. The tag has no power source of its own; the phone lends it one for the length of the tap.
A few consequences follow directly:
- Range is short by design, from contact to a few centimetres, and depends on both antennas rather than on the chip alone.
- Standard NFC Forum Type 2 tags such as NTAG213 communicate at 106 kbit/s, which is ample for a URL but not for large files.
- The tag draws only enough power to run the chip, so it cannot light an LED or drive a sensor without a separate energy source.
Why an unformatted tag does nothing
A blank chip has memory but no message. When a phone reads it and finds no valid NDEF structure, there is nothing to act on, so nothing happens. NDEF, the NFC Data Exchange Format defined by the NFC Forum, is the agreed way to arrange bytes so that a phone the tag has never met still knows what the content is and what to do with it.
An NDEF message holds one or more records, each with a short header and a payload. The common types are a URI record for a web address, a Text record with a language code, and MIME records for data such as a contact card. A URI record is compact because a single prefix byte stands in for a common scheme, so https:// costs one byte rather than eight. The practical rule for cross-platform work is simple: write a well-formed NDEF message, and prefer an https URL, which launches most reliably on both platforms. A tag carrying raw bytes rather than NDEF may read fine in a diagnostic app yet trigger nothing on a consumer phone. The companion post on RFID data encoding and memory covers how that message is laid out inside the chip.
Background reading on iPhone
This is where most surprises live. From iPhone XS (2018) onward, running iOS 12 or later, the phone reads a well-formed NDEF tag in the background through its System Tag Reader, with no app open. A banner appears and tapping it opens the record; on those models it works even with the screen locked. Older NFC iPhones behave differently: the iPhone 7, 8 and X can read tags only through a foreground app built on Apple’s Core NFC framework, not in the background. Writing to tags from an iPhone arrived with iOS 13, again through an app.
Two details matter when you specify a project for iPhone users. First, an https URL is the record type that opens most dependably; a plain http link or a non-URL record may not trigger the background reader. Second, Safari itself cannot read or write tags, so any bespoke reading or writing flow on iPhone needs a native app.
What Android does with the same tag
An NFC-capable Android phone reads NFC Forum Type 2 tags such as NTAG213 broadly, and has done so across the fleet for many years. Android routes a read through its intent system: an app can register to handle a given record type, and if none claims it, the default browser opens a URL record. Android also supports the Android Application Record, a payload that forces a specific app to handle the tag, but iOS ignores it. Encoding an AAR is therefore a common reason a tag behaves on Android and does nothing on iPhone. For a design that must serve both, use one https URL that your own domain resolves, and let each platform route it.
Antenna position, metal and other physical realities
Whether a tag reads is as much about placement as about the chip.
- Antenna position. Every NFC iPhone reads from the top edge, behind the front camera; hold the tag to the top of the phone for a second or two. Android positions vary by model and are usually in the upper half of the back. Marketing that says “tap the back of your phone” fails for iPhone users and for many foldables.
- Metal surfaces. A label placed directly on metal is detuned and may stop reading. Specify an on-metal (ferrite-backed) construction for a metal surface and test it in place rather than on the bench.
- Cases and accessories. Ordinary plastic, silicone and leather cases pass the signal; hidden metal plates, ring holders and some magnetic accessories can reduce range. Test with the case your users actually carry.
What a tap can and cannot trigger
A tag can open a web address, present text, or hand a phone a Wi-Fi or contact record where the platform supports it, and it can launch an app through a link that app has registered. It cannot run arbitrary code on the phone, cannot force an action when the record type is unsupported, and cannot by itself prove that a product is genuine: a static NDEF record can be copied byte-for-byte onto another tag, which then reads identically. Where each tap must be cryptographically verifiable, evaluate an NTAG424 DNA label, which signs every read so a server can tell an original from a clone.
| Question | iPhone (XS and later, iOS 12+) | NFC-capable Android |
|---|---|---|
| Background read, no app | Yes, well-formed NDEF | Yes, through intent dispatch |
| Reads Type 2 (NTAG213) | Yes | Yes |
| Honours Android Application Record | No | Yes |
| Preferred URL scheme | https |
https |
| Writing tags | App only, iOS 13+ | Built-in and via free apps |
Specifying a tag that works everywhere
Choose a widely readable chip such as NTAG213 for a simple link, encode one well-formed https record on a domain you control, and keep the destination content on that page so it can change without re-encoding. Then test the encoded sample on the actual phone models and cases your audience uses, in the tag’s final position on the finished product, before you approve artwork or a batch. For the label range, browse RFID labels, and send your requirement with the target phones and mounting surface so a sample matches the real conditions.
