NFC Type 4 Tag Read/Write Workbench

Trace how a reader detects a Type 4 tag, selects the NDEF application, reads the CC file, and reads or writes an NDEF message.

animation
nfc
type-4-tag
ndef
apdu
reader-writer
Learner-ready NFC Type 4 tag workbench with scenario presets, animated APDU flow, CC/NDEF file model, read/write diagnostics, quick reference cards, source links, and desktop/mobile visual checks.
Reader/writer mode Type 4 tag NDEF over APDUs

NFC Type 4 Tag Read/Write Workbench

Follow a phone or reader as it powers a passive Type 4 tag, selects the NFC Forum NDEF application, reads the Capability Container, and then reads or updates the NDEF file. The goal is to see the file and APDU sequence, not just remember command names.

What is moving?

The packet card represents the APDU command or response currently crossing the NFC field. Reader commands go to the tag; tag responses return status words and data.

Where is the data?

A Type 4 tag exposes a small file model. The CC file tells the reader which NDEF file exists, how large it can be, and whether writes are allowed.

Why writes fail more often

Writes need stronger field power, access permission, chunking through MLc, and a safe length update so readers do not see a half-written NDEF message.

Interactive workbench

Trace the Type 4 NDEF access sequence

The reader activates a passive tag, selects the NDEF application, reads the CC file, selects the NDEF file, and reads the NDEF payload.

NFC reader Generates the 13.56 MHz field and sends APDUs after ISO-DEP activation.
RF field 13.56 MHz carrier energizes the passive tag.
Field quality78%
Passive Type 4 tag No battery. It harvests field power and exposes an NDEF file through command-response exchanges.
NDEF application AID D2760000850101
CC file E103 MLe 128, MLc 64
NDEF file E104 4096 B capacity
Access bytes Read free, write free
Status word 90 00 success
NLEN 00 48
NDEF payload URI, 72 B
Free file area 4022 B remaining
Outcome Pass
APDU plan 1 READ BINARY chunk
Estimated time 42 ms
File usage 2%
Command 13.56 MHz field on
Response or data Tag harvests power and becomes selectable.

Ready to read

The field is strong enough, the NDEF application and CC file are present, and the NDEF message fits inside the advertised file size.

Guided checks

  1. Step to "Read CC" and confirm that the CC file tells the reader the NDEF file ID, MLe, MLc, capacity, and write access.
  2. Switch to "Write service note" and watch the write use an empty NLEN, data updates, then a final NLEN commit.
  3. Try "Locked tag" and explain why read access can still work while UPDATE BINARY is rejected.
  4. Increase distance or field disturbance until APDUs time out, then reduce the payload to see that capacity and field quality are separate limits.
Scannable quick reference

Type 4 tag quick reference

Use these cards to read the animation without digging through the specification text first.

Mode boundary Reader/writer mode

The reader powers a passive tag and drives command-response traffic. This is not LLCP peer-to-peer and not phone-as-card emulation.

Files CC before NDEF

The CC file advertises mapping version, MLe, MLc, NDEF file ID, max NDEF size, read access, and write access.

Commands SELECT, READ, UPDATE

Readers select the NDEF application, select files, use READ BINARY for CC/NDEF reads, and UPDATE BINARY for writes.

Status 90 00 means success

Other status words indicate problems such as file/application not found, security/access failure, wrong length, or not enough space.

Deeper technical notes

These notes explain the implementation model used by the animation.

Read sequence used here
  • The simplified read path is field activation, tag selection, ISO-DEP activation, NDEF application selection, CC file selection/read, NDEF file selection, NLEN read, and NDEF payload read.
  • The APDU names are shown as teaching labels. Real devices also handle lower-layer timing, chaining, frame waiting, and implementation-specific limits.
  • MLe controls how much data the reader requests per READ BINARY command. Larger messages may need multiple reads.
Write safety model
  • The workbench models the common safe pattern: write NLEN as zero, update the NDEF data area, then write the final NLEN value.
  • This prevents a reader from treating a partially written payload as a complete NDEF message.
  • MLc controls chunk size for UPDATE BINARY. More chunks increase timing and field-stability risk.
What is simplified
  • The timings are teaching estimates, not conformance measurements.
  • The status words shown are representative of ISO 7816-4 style command-response behavior and the learning outcome, not a complete status-word table for every chip.
  • Type 4A and Type 4B lower-layer activation details are grouped into one ISO-DEP stage so learners can focus on NDEF access.