Wiki · Concept · Last reviewed June 25, 2026

Web NFC API

The Web NFC API lets selected web pages read and write NDEF messages on nearby NFC tags, creating a browser boundary for agents and tap-based objects.

Category: Concept Updated: June 25, 2026 Tags: browser security, NFC, hardware, agents, permissions

Definition

The Web NFC API is a W3C Community Group draft for selected browser uses of Near Field Communication. Its current scope is the NFC Data Exchange Format, or NDEF. Low-level I/O such as ISO-DEP, NFC-A/B, and NFC-F is outside scope, Host-based Card Emulation is not supported, and peer-to-peer is not currently supported.

MDN marks Web NFC as limited availability and experimental. It describes the API as a way to exchange data through lightweight NDEF messages, and notes that tags must be formatted and recorded for NDEF to work with Web NFC. The core objects are NDEFReader, NDEFMessage, and NDEFRecord. The governance issue is what record exists when a browser agent can read, write, or make a nearby tag read-only.

Mechanism

The main entry point is NDEFReader. Chrome says feature detection checks whether NDEFReader exists on window, but that this does not prove NFC hardware is present. Calling scan() schedules a read, and reading and readingerror events report compatible and incompatible nearby tags. An NDEFReadingEvent can include a serialNumber and an NDEFMessage whose records carry type and payload data.

Writing uses write() with a string or an NDEF message dictionary. Chrome's guide describes supported record types including empty, text, URL, smart poster, MIME type, absolute URL, external type, unknown, and local type. It also documents makeReadOnly(), a method that can make a tag permanently read-only where supported.

The permission boundary is physical and browser-mediated. Chrome says Web NFC is available only to top-level frames and secure browsing contexts. Origins must request the nfc permission while handling a user gesture, and scan(), write(), and makeReadOnly() trigger a prompt if access was not previously granted. The page must be visible when the user taps a tag, access is blocked if the display is off or the device is locked, and non-visible pages have NFC receiving and pushing suspended.

Agent Context

For AI Browsers and Computer Use, Web NFC is a tap-to-record authority surface. A model could guide inventory work, badge check-in, museum labels, field support, device provisioning, or a repair flow where a user taps a phone to a tag. It could also write the wrong URL, encode a stale configuration, overwrite a field label, mis-handle a serial number, or make a tag read-only before the human understands the consequence.

The tag is not a trustworthy witness merely because it is physical. Chrome's documentation describes NDEF tags as readable by anyone and writable by anyone unless they are read-only. That makes tag content useful for workflows, but weak as standalone proof of identity, consent, ownership, or location. Agentic automation around Web NFC should keep the physical tag, the user gesture, and the generated NDEF payload visible in the same review record.

Governance Use

A governance review should treat Web NFC as nearby tag authority. Record the origin, top-level frame state, secure-context state, permission state, user gesture, page visibility, NFC operation, tag serial number when exposed, NDEF record types, payload category, overwrite setting, read-only action, abort path, and human confirmation. If a model is involved, record the prompt, generated message, tool call, and whether the user saw the final tag content before writing.

Organizations should keep NFC writing surfaces narrow. A provisioning page, badge tool, classroom lab, inventory station, or repair portal should not share tag authority with unrelated scripts, third-party embeds, or unreviewed plugins. Secrets written to tags should be minimized, because NDEF content may be tapped, moved, copied, or relabeled outside the original workflow.

Limits

Web NFC is intentionally not a general NFC stack. The draft excludes low-level I/O and Host-based Card Emulation, and the current specification says peer-to-peer is not supported. That reduces the surface, but it also means product teams should not assume Web NFC can inspect every card, payment instrument, transit pass, access badge, or vendor-specific tag.

The browser can enforce secure context, top-level frame, permission, visibility, and device-lock constraints. It usually cannot know whether a tag is attached to the right object, whether a printed label is honest, whether a URL is safe, or whether making a tag read-only will break a later process. The control layer still needs tag inventory, revocation, payload validation, rewrite policy, and incident logs.

Review Record

Source Discipline

Claims about API scope should cite the W3C Community Group draft. Claims about support, secure context, user gestures, and operational constraints should cite current browser documentation, because MDN marks Web NFC as limited availability and experimental. A permission prompt is evidence of user-mediated access, not evidence that the tapped tag is authentic or that the payload is safe.

Spiralist Reading

Spiralism reads Web NFC as the moment a small physical token becomes a web sentence. A sticker, card, badge, or box can carry a message that a browser agent may read, rewrite, or freeze. The humane boundary is visible tap, narrow permission, legible payload, reversible process where possible, and a user who can still distinguish the object from the authority claimed through it.

Sources

Return to Wiki