Skip to content
Language: EN

In what order are multiple records acted on?

Records are stored in the order you write them, and platforms generally act on the first one they recognise. Everything after it is available to software that looks, and invisible to everyone else. Order is therefore a decision to make deliberately.

Stored in order, acted on selectively

An NDEF message is an ordered sequence, and a reader receives the records in the order they were written. Nothing reorders them and nothing sorts them by importance.

What varies is what the operating system does next. It walks the records looking for something it knows how to handle, and it stops at the first one it finds.

Why the first recognised record wins

Because tapping a tag is a single gesture with a single expected outcome. A platform that offered a menu of every record would turn a tap into a decision, which defeats the point.

Note the wording: the first record it recognises, not simply the first record. A leading record of a type the platform ignores is skipped rather than blocking the ones after it. This is what makes fallback design possible.

Designing a fallback

Put the record you most want acted on first, and the fallback after it.

A URL followed by a plain text record works well. Where the URL is recognised, it wins and the text is never surfaced. Where it is not, the text is at least readable by whatever does look.

Reversing that order breaks it on the platforms that do recognise text records, because the fallback wins and the real action never runs.

Test the order, do not reason about it

Platform behaviour with several records has varied between versions and differs between Android and iOS. Writing one tag and tapping it with both takes two minutes and settles the question for your actual audience.

The mistake this causes

A tag written by adding records one at a time, in the order they came to mind, then deployed without checking which one fires.

It usually works on the phone of the person who wrote it, because they wrote the important record first by accident. It fails elsewhere for reasons nobody connects to order, and the diagnosis is difficult precisely because the tag reads perfectly and contains everything it should.

The fix is to decide the order rather than to inherit it, and to verify with a read that shows every record rather than with a tap that shows one.

Frequently asked questions

Can I reorder records without rewriting the tag?

No. The order is the order they are stored in, so changing it means writing the message again. On an unlocked tag that is trivial, and on a locked tag it is impossible.

Does the same order behave identically on Android and iPhone?

Not necessarily, since the two platforms recognise different record types. A record ignored by one is skipped and acted on by the other, which can make the same tag behave differently.

Is there a way to force a specific record to be used?

Not from the tag side, beyond putting it first and choosing a type the target platform recognises. The decision belongs to the operating system and is not something a tag can override.

Do applications see records the system ignored?

An application reading the tag directly receives the whole message and can use any record it likes. The selection described here applies to the system deciding what to do on a tap.