Why are URL prefixes abbreviated on a tag?
The URI record format replaces a common prefix such as https or a mail scheme with a single identifier byte, and stores only the rest of the address. It saves several bytes on every tag, it is entirely invisible in normal use, and it explains why a raw dump of a tag shows a truncated address.
What the format actually stores
A URI record begins with one byte identifying a prefix from a fixed list, then holds the remainder of the address as plain characters.
So an address beginning with a common scheme does not store those characters at all. The reader looks up the prefix from the byte and reassembles the full address before handing it to the system.
The list covers the schemes that actually appear on tags: web addresses with and without the www convention, mail, telephone, and a handful of others.
Why a few bytes are worth it
Because on the smallest tags a few bytes is a meaningful share of what you have.
Saving the characters of a scheme on a tag with room for a couple of hundred bytes of content is a small percentage. On a tag where a URL barely fits, it can be the difference between a successful write and a failure, which is why the format bothers.
It costs nothing in exchange. There is no compatibility trade, no loss of information, and no configuration.
What you see in a raw view
This is where the mechanism becomes visible, and where it confuses people.
A tool showing the decoded record displays the complete address, as it should. A tool showing raw bytes shows the address without its scheme, preceded by a byte that looks like noise.
Seeing a domain with no https in a hex dump is therefore normal and not a sign that the tag was written incorrectly. The scheme is there, encoded as one byte rather than eight characters.
The limits of the trick
Only prefixes on the list are abbreviated. An unusual scheme, a custom application scheme, or an address that does not start with anything on the list is stored in full, with the identifier byte set to indicate no abbreviation.
This matters when you are fighting for space with a custom scheme, because the saving you were counting on does not apply. It also means two addresses of the same visible length can occupy different amounts of memory depending on how they start.
None of this changes what you do when writing a tag. A tool handles it, and the practical takeaway is simply to stop worrying when a raw view looks wrong.
Frequently asked questions
Do I have to do anything to use the abbreviation?
No. Any tool writing a URI record applies it automatically when the address starts with a recognised prefix, and readers reverse it just as automatically.
Why does my tag show a URL without https in a hex dump?
Because the scheme is stored as a single identifier byte rather than as characters. Decode the record rather than reading raw bytes and the full address appears.
Does this work for custom application schemes?
Only if the scheme is on the fixed list, which custom ones are not. They are stored in full, so a custom scheme costs more space than a standard one of the same visible length.
Can this cause a tag to behave differently across phones?
No. The mechanism is part of the record format and every compliant reader implements it identically. Differences between platforms come from record types, not from prefix encoding.