I locked my tag by mistake: what now?

Stop the run first

Before investigating anything, stop writing. If a setting locked one tag it will lock the next, and every minute of continued work multiplies the loss.

Find the lock option in whatever wrote the tag and switch it off. It is usually a checkbox near the write button, labelled read only, permanent or write protect.

Then verify it is off by writing one tag and reading it back, confirming it is still writable.

Only then work out what happened. The instinct is to investigate first, and investigating while the run continues is how ten locked tags become two hundred.

Find out how many

Read every tag written in that session. The lock was almost certainly a setting rather than a slip, which means it applied from the moment it was enabled.

Sort them into two piles: locked and writable. That count is what you need before deciding anything else.

Check tags written in earlier sessions too if you cannot be sure when the option was switched on. Settings persist between sessions.

Label the locked pile immediately. Locked tags returned to general stock come back to bite months later.

What can be salvaged

Read what the locked tags actually hold. If the content is correct and will not need to change, those tags are usable exactly as they are.

This is worth emphasising because it applies more often than people expect. A tag holding a stable redirect address you control is not harmed by being locked: what it points at remains changeable on your server.

Tags locked with wrong content are finished. Set them aside rather than throwing them away yet, since a known locked tag is useful for testing that your process detects the state.

And if a large batch is affected, count the cost honestly before deciding. Tags are cents and the labour of sorting and rewriting is not, so replacing the batch is sometimes cheaper than salvaging it.

Change the process, not the tags

Write the whole batch first, verify it, and lock afterwards as a separate deliberate pass. Locking during the write makes every mistake permanent at the moment it is made.

Read one tag back at the start of every session and confirm it is still writable. That single check catches a lock setting before it costs anything.

Ask whether locking is needed at all. It suits a public tag holding stable content and it is not a default, and plenty of deployments are better off without it.

And write the setting into your procedure rather than relying on memory. This mistake is made by careful people using a tool that remembered a choice from last month.