How do you write hundreds of tags without doing it one by one?
A phone with a writing tool in repeat mode handles a few hundred tags comfortably: set the content once, then present tags in sequence. Beyond that scale, a dedicated encoder or factory encoding becomes worthwhile, and the bottleneck moves from writing to handling.
Repeat mode, the answer for most runs
A writing tool with a repeat or batch mode keeps the content loaded and writes it to each tag presented, without returning to the setup screen. Present a tag, wait for the confirmation, move on.
For a few hundred tags carrying identical content, this is genuinely adequate. It requires no hardware beyond a phone, no procurement, and no lead time.
The thing to verify before starting is that repeat mode is not also repeating a locking option. A checkbox left ticked applies to every tag in the run, and that is how whole batches are lost.
Laying out the work
Physical arrangement decides the speed far more than anything technical.
Two piles, not one: unwritten on the left, written on the right, and never the two mixed. A tag that goes back into the wrong pile will be written twice or shipped unwritten, and both are invisible afterwards.
Keep tags separated. Stacked tags detune each other, so a pile presented to a phone reads as nothing at all, and the operator concludes the tags are faulty.
Remove the phone case. Over several hundred taps, the extra millimetres cost real time in retries.
When a phone stops being enough
Three signals, and any one of them is sufficient.
Each tag needs different content, which turns a repeat run into an individual operation and multiplies the time and the error rate. Mirroring solves this on chips that support it and otherwise it does not scale.
The quantity reaches thousands, where the labour cost exceeds what an encoder or a factory service would charge.
Or the tags are already inside a product, laminated into cards or embedded, where they cannot be handled one at a time by hand.
The discipline that matters more than the method
Write one tag, read it back, confirm the content, and only then start the run. Every batch, not once ever, because suppliers substitute chips without saying so.
Verify at the end as well as the start. A run that drifts, because an operator got faster and started moving the phone too early, produces a tail of partially written tags that all look fine in the pile.
And never let a suspect tag rejoin the good pile. That single rule prevents most of what goes wrong in production.
Frequently asked questions
Can I write several tags at once by stacking them?
No. Stacked tags detune each other and generally none of them will respond. They have to be presented one at a time, physically separated.
Does repeat mode risk writing the same tag twice?
Yes, if a tag is presented again, and a second identical write is harmless. What is not harmless is losing track of which tags have been done, which is why the two pile method matters.
Is a dedicated encoder much faster than a phone?
Per tag, moderately. Its real advantages are handling many tags without an operator holding a phone, and driving unique content per tag from a list, which a phone does poorly.
Should I lock tags during the run or afterwards?
Afterwards, as a separate pass once the content has been verified. Locking during the run means any mistake is permanent before anyone has checked it.