Why can a copied tag behave differently from the original?
Because copying carries the content across and leaves everything else behind. Five differences explain almost every case: a different identifier, a different chip, a different tag type, configuration that was never copied, and a lock state that did not follow the content.
The five differences
A copy is a fresh tag holding the same content. Everything that was not content stayed with the original.
The identifier differs, always. The chip may differ, and with it the free space and the write behaviour. The tag type may differ, which changes how platforms treat it. Configuration such as mirroring or a password was not copied. And the lock state did not follow, so a copy of a locked tag is unlocked.
The identifier, the usual culprit
Anything that keys on the identifier breaks silently on a copy.
A home automation routine triggered by a specific tag will not fire, because the routine is watching for an identifier the copy does not have. An access system checking a list will reject it. A server expecting a known identifier will not recognise it.
The content is identical, the behaviour is different, and nothing in a content comparison reveals why. This is the single most common confusion in this whole area.
The fix is to add the new identifier wherever the old one was registered, which requires knowing that the system uses identifiers at all.
A different tag type changes behaviour
Copying content from one tag type to another can change what a platform does with it, even with identical records.
Support differs by type, particularly on iOS and particularly for the less common families. A copy that lands on a Type 5 tag when the original was Type 2 may read on fewer devices, with no change to what it holds.
Free space differs too. A copy that fits on the source and not on the target either fails or, with a careless tool, truncates.
Diagnosing a copy that misbehaves
Compare the two tags side by side with a reading tool rather than testing the behaviour.
Look at the content first: same record count, same types, same payloads. If they match, the content is not the problem and you are looking at one of the other four differences.
Then look at the chip and the tag type. If those differ, that is the likely cause and the answer is to source a matching tag.
If content, chip and type all match and behaviour still differs, the identifier is the answer. Something in your system knows which tag it was expecting.
Frequently asked questions
Why does my copied tag not trigger my phone routine?
Because the routine is watching for the original identifier, which a copy cannot have. Add the new tag to the routine as a second trigger.
Can I make the copy have the same identifier?
Not on a standard tag. Tags with a writable identifier exist and are sold for testing, and they are a specific product rather than something an ordinary tag can be made to do.
Does copying preserve a password?
No. Passwords are chip configuration rather than content, so a copy is unprotected until you configure it separately.
Is a copy of a locked tag locked?
No. The copy is a normal writable tag holding the same content. If you want it locked, that is a separate action on the new tag.