In short
Secure and URL Shielding (Shield, for short) are two separate controls that answer two different questions. Secure decides who is allowed in. Shield decides how the content is handed over to whoever got in.
They are independent, they can be used alone or together, and confusing one for the other is the most common reason a code turns out to be less protected than someone assumed.
On this page
Two controls, two questions
Almost everyone meeting these controls for the first time assumes they are two strengths of the same thing — that Shield is Secure with more of it. They are not on the same axis at all.
Securing a code
Securing moves a code from "open to whoever finds it" to "open only to people you have named". In the Linxy IQ records list, each record’s Protection section shows whether Secure is Enabled or Disabled, with a Make Secure or Make Public button.
Once secured, an interaction runs into an access check before anything else happens:
- Not signed in.The visitor sees an access-required page rather than your content. They cannot get past it anonymously, however they arrived.
- Signed in, no grant.They see an access-denied page. Being a Linxy account holder is not enough — access is per code, not per platform.
- Signed in, granted.The content opens. If you have notifications switched on for that code, you are told who opened it.
You grant access by inviting an email address. If that address already belongs to a Linxy account, the person is invited directly. If it does not, a pending account is created for them and the invitation email walks them through claiming it. Either way they accept or decline the invitation, and you can revoke a grant later without touching the code itself.
Shielding a code
Shielding changes the delivery mechanism rather than the guest list. Without it, resolving the code eventually hands the browser your real destination address, and from that moment the address exists on the visitor's device: in the address bar, in history, in anything they choose to paste into a message.
In the records list, the URL Shielding section has an Enable Shield or Disable Shield button. With Shield on, the platform substitutes an encrypted, time-limited view token. The content is served through that token and the token then stops working: about five minutes for a web page, a document or an image, and around six hours for video and audio, which need to survive a full playback session. The real destination is never given to the browser at all, so there is nothing durable to copy.
| Shield does | Shield does not |
|---|---|
| Keep your destination address out of the address bar, history and page source | Stop the person in front of the content from screenshotting or re-typing it |
| Make a forwarded address useless within minutes | Verify who the person is — that is Secure's job |
| Prevent the address being harvested and shared at scale | Encrypt the content itself, or protect it after download |
| Conceal a web page as well as a file — the page is fetched by Linxy and served to the visitor with every link, image and script inside it re-addressed, so nothing on it points back at the real site | Conceal a page that refuses to be served this way, or one too large to fetch — those open directly at their own address, and switching URL Shielding on in the Mark’s editor checks the destination and tells you straight away whether it will |
| Keep a shielded page working for reading, video and audio | Guarantee every interactive page behaves — sign-in forms and web apps served through Linxy may degrade; host that kind of destination yourself or leave it unshielded |
Shield works on any record that resolves through a Dynamic Link, which means Make it Linxy and Short URL Only records both support it. A Standard QR record has no link behind it, so there is nothing to shield and the console will tell you there is no short address associated with the record.
Choosing a combination
| Secure | Shield | What you have built | Fits |
|---|---|---|---|
| Off | Off | A public, tracked touchpoint | Marketing, packaging, signage, anything you want spread |
| Off | On | Open to all, but the address cannot be lifted and redistributed | Content that should be reached through the object, not linked to from elsewhere |
| On | Off | The right people get in, and get an ordinary address they can pass on | Low-sensitivity material where convenience matters more than containment |
| On | On | Named people only, and nothing durable handed out | Pricing, pre-release material, client deliverables, anything confidential |
Which side you are protecting
This is the most important paragraph on the page, and the one people skip. A Linxy IQ record has two sides with two destinations. Secure and Shield act on the Mark side — on the Dynamic Link that the marked image resolves through. The visible code resolves to its own Target URL, and protection you apply here does not travel to it.
| Side | Protected by Secure or Shield? |
|---|---|
| The invisible Mark, via its short URL | Yes. This is what the controls act on |
| The visible code, via the Target URL | No. It keeps resolving to whatever that address is |
The useful way to think about it: the code is the public face and the Mark is the private one. Put the open, shareable thing on the code side, and everything that needs to be earned on the Mark side. Then protection is doing its job on the side that needs it.
What this does not protect against
Being honest about the edges is more useful than overselling. Neither control is designed to stop any of the following, and no combination of them will:
- A person who legitimately has access, sharing what they saw. Screenshots, photographs of a screen, and re-typing all defeat every link-level protection there is.
- A photograph of the printed object. Anyone can point a camera at a picture of your artwork and follow the code. Securing the Mark is what keeps the Mark side out of reach; it does nothing about the code.
- Downstream handling. Once a file has been downloaded from your destination, it is governed by wherever it was downloaded from, not by Linxy.
- A compromised account. If an invited person's own account is taken over, the grant travels with it. Revoke access when someone leaves a project.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Secured the record, but scanning the code still opens the content | The code resolves to the Target URL, which these controls do not touch | Point the Target URL at a public page and keep the protected content on the Mark side |
| "Only Linxy marks can be made secure" | The record is Short URL Only or Standard QR | Regenerate in Make it Linxy mode; the mode cannot be changed in place |
| "No short URL associated with this record" | Shield attempted on a Standard QR record, which has no link behind it | Regenerate in one of the other two modes |
| Invited person sees access denied | They have not accepted the invitation, or they are signed in to a different account than the one invited | Have them accept from the invitation email, and check which address they signed in with |
| Invited person sees access required and no way forward | They are signed out — the page cannot know who they are yet | They sign in first, then reopen the code |
| Content opens for you but nobody else | You are the owner, so you never meet the access check | Test in a signed-out browser or on another account before publishing |
| A shared address stopped working after a few minutes | Shield is on, and view tokens are deliberately short-lived | Working as designed — share the object or the code, not the address |
| Revoked someone but they still got in | They had an unexpired view session already open | Revocation stops new access; existing sessions end shortly on their own |
| Shield is on but visitors land on the real address | The destination refuses to be served through Linxy, or could not be fetched, so it opens directly — switching URL Shielding on in the Mark’s editor checks for this | Point the record at a file or a page you host, which conceals reliably; a third-party site that blocks it cannot be shielded |
| A shielded web page looks broken or will not let people sign in | The page depends on scripts or forms that do not survive being served through Linxy | Leave that destination unshielded, or move the content to something static |
Things people commonly get wrong
Related reading: Linxy IQ: a code and a Mark on the same artwork, How protected content opens, Why it is asking for a password or Face ID, and Redirection controls.