How do you write a URL to an NFC tag?
Open a writing tool, choose the URL record type, enter the address including its scheme, and hold the phone against the tag until it confirms. The operation takes seconds. What deserves attention is choosing an address you can change later and reading the tag back to confirm what landed.
The operation itself
Open a writing tool. Choose the record type presented as URL or web address rather than text. Enter the address including its scheme, so https and not a bare domain. Hold the phone against the tag, over its antenna, until the tool confirms.
That is the whole procedure, and it is deliberately unremarkable. Everything that goes wrong with URL tags goes wrong before or after this step.
Choosing the address
Prefer an address you control and can redirect. A link to your own domain that forwards somewhere else can be repointed at any time; a link straight to a third party page cannot, and if that page moves the tag is dead.
Keep it short. Every character is a byte, and on a small tag the difference between a long address with parameters and a short one is the difference between a write succeeding and failing.
Use https. A plain http address will be upgraded or warned about by browsers, which turns a clean tap into an interstitial.
The tracking parameter trap
Appending campaign parameters to the address makes it longer and freezes them into the tag permanently. Put the parameters on the redirect at your server instead, where they can be changed for every tag at once.
Verifying, which is the step people skip
Read the tag back with the same tool. Confirm there is one record, that its type is URI rather than text, and that the address is complete.
This catches three failures at once: a write interrupted partway, a record written as the wrong type, and content truncated because it did not fit. All three produce a tag that looks written and is not, and all three are cheap to find now and expensive to find after a print run.
When nothing happens on tap
If the tag reads and the browser does not open, the record type is the first suspect. A URL stored as a text record displays correctly in a reading tool and asks the phone to do nothing.
If nothing at all happens, the problem is physical rather than content: aim, distance, a case, or the surface the tag is stuck to.
The dividing question is whether the phone reacts at all. A vibration with nothing after means the read worked and the content is at fault, while a banner on an iPhone, or an open link notification from Android 17, means the link is waiting to be tapped. Silence means the read never happened.
Frequently asked questions
Do I need to include https at the start?
Yes. A bare domain written as a URI record is ambiguous, and tools that accept it usually add a scheme for you. Checking what actually landed by reading the tag back removes the doubt.
Can I change the URL later?
On an unlocked tag, as many times as you like. On a locked tag, never, which is why locking should wait until the address is settled.
Will the URL open automatically or ask first?
It depends on the platform, its version and whether the screen is locked. An iPhone typically shows a banner the user taps, Android does the same from Android 17 with an open link notification, and earlier Android versions act directly. Design for the confirmation rather than assuming it away.
What is the longest URL that fits?
It depends on the tag, and the honest method is to read the free space with a tool rather than calculate. If an address is close to the limit, shorten it at the server rather than buying a bigger tag.