Who Owns Your QR Code? The Case Against Rented Redirects

Every dynamic QR code you print is a promise that a redirect will still be working the next time someone scans it, made by a domain you don't control, run by a company you're trusting to stay in business, on terms that can change without your permission. That's not a criticism of any one platform. It's what "dynamic" means: the printed pattern holds a short link, and everything the short link depends on lives entirely on somebody else's side of the relationship.

What you're actually depending on

Print a dynamic code and the artwork itself is finished the moment it goes to press. What isn't finished is the chain of things that have to keep working for that artwork to mean anything: a domain name that has to stay registered and pointed correctly, a redirect service that has to stay online and fast, a company that has to stay in business and keep honouring the deal you signed up for, and a subscription that has to stay paid, on your side, indefinitely. None of that is visible on the printed code itself. A static code and a dynamic code look identical to the eye; only one of them has a company standing behind every future scan.

This is true of every dynamic QR platform, without exception. The question worth asking isn't whether this dependency exists, it does, by construction, it's how much of it is disclosed to you before you commit a print run to it.

Why this rarely gets asked

Most QR platform comparisons happen on the terms the platforms themselves set: how many code types, how much customisation, what the analytics dashboard looks like, what the plan costs per month. Those are real, comparable, screenshot-able differences, and they're also the questions a sales page is built to answer well. Dependency isn't, because there's no attractive way to answer "what happens if we shut down," so it simply doesn't come up in most evaluations at all.

Print buyers are especially exposed to this gap, more than a typical software buyer would be. Switching a subscription tool that turned out to be a poor fit costs you a migration. Switching a QR platform after the codes are already printed on a hundred thousand cartons costs you nothing, because the artwork itself never has to change, right up until the moment the platform behind it stops working and every one of those cartons is carrying a dead code with no way to fix it short of a full reprint. The dependency is invisible for as long as everything is going well, which is exactly when nobody thinks to check it.

Six ways that dependency breaks

None of these require a vendor to be dishonest. Most are simply what happens to any small company or any subscription product over a long enough timeline.

Vendor shutdown. A company closes, sells only part of its business, or discontinues a product line, and the redirect domain stops resolving. Every code printed against it fails simultaneously, with no warning visible on the artwork itself.

Acquisition. A platform gets bought, and the acquirer's roadmap doesn't include maintaining every legacy customer's redirects on the same terms, or at all.

Price change. A platform raises prices sharply, or restructures plans in a way that makes your existing usage suddenly uneconomical, and you're negotiating from a position where switching means every printed code already in the field breaks.

Lapsed billing. A card expires, an invoice gets missed internally, or a renewal email goes to the wrong inbox, and a redirect that a live campaign depends on goes dark for reasons that have nothing to do with the platform's health at all.

Expired domain. A redirect domain's registration lapses, deliberately or by oversight, and either the service goes down or, in the worse version of this failure, someone else registers it and now controls where your printed codes send people.

Hijacked destination. A compromised account, weak access controls, or a phished credential lets someone with no relationship to you point a live code somewhere malicious, and every printed copy of that code becomes an attack surface until it's caught. Quishing: what marketers must check covers this failure mode in more depth, and our security page covers what destination scanning and access controls are meant to catch before it gets that far.

The buyer's due-diligence checklist

None of these questions require legal expertise or a signed contract to answer. Most can be checked from a vendor's own public pages in a few minutes, and a vendor unwilling to make the answers easy to find is itself an answer worth noting. Before committing a print run, especially at packaging volume, to any dynamic QR platform, get a straight answer to each of these.

Each row maps directly onto one or more of the six failure modes above: the export question is your insurance against vendor shutdown and acquisition, the domain and entity questions are what let you judge how exposed you'd be to a hijacked destination or a dispute, and the billing question is the one that turns an ordinary lapsed renewal into a field-wide outage instead of a quiet fix. None of the six failure modes are hypothetical categories invented for this article; they're the concrete situations each checklist question exists to catch before it happens rather than after.

Answering the checklist for MyQRx, honestly

Redirect domain. tilg.in is disclosed openly as MyQRx's redirect domain, not hidden behind a generic or unbranded shortener. You can see exactly which domain your printed codes depend on.

Legal entity. SafeKT Technologies Private Limited is the named company behind MyQRx and tilg.in. It isn't operated anonymously or through an undisclosed intermediary.

Grievance and abuse contact. MyQRx publishes a named Grievance Officer and a grievance contact, alongside a public path for reporting a suspicious or compromised code. This isn't a courtesy feature; appointing and publishing a Grievance Officer is a statutory obligation for intermediaries under India's IT Rules, tied to the liability protection those rules provide.

Exporting your codes and data. Not offered. If you needed to leave MyQRx for another platform, you would be rebuilding your code list rather than migrating it. This is a genuine limitation, not a hedge, and it belongs on the same checklist you'd run against any other vendor.

What happens if you stop paying. We haven't published a specific commitment on this yet, and we'd rather say so plainly than invent a reassuring answer. Treat a lapsed subscription as a real risk to live, printed codes on any platform, including this one, until a vendor states otherwise in writing.

What happens if MyQRx is acquired or shuts down. Also not something we've published a specific position on. Naming this gap is the point of this article: a platform that hasn't committed to something shouldn't be assumed to have it covered.

Two of those six answers are genuinely good, two are the same as almost every competitor's, and two are gaps we're naming rather than papering over. That mix, not a clean sweep, is what an honest answer to this checklist looks like from any real vendor. Treat a competitor's version of this same checklist, ours included, with the same scrutiny, and be more suspicious of a platform that claims a perfect score than one that names its gaps plainly.

What disclosure buys you, and what it doesn't

Naming a redirect domain, a legal entity, and a grievance contact doesn't remove any of the six failure modes above. A disclosed company can still be acquired. A named domain can still lapse. What disclosure changes is whether you can see the dependency clearly enough to make an informed decision, and whether there's an identifiable party to hold accountable if something goes wrong, rather than an anonymous shortener with nobody behind it to ask. That's a meaningfully better starting point than the alternative, but it's a starting point, not a guarantee, and treating it as one would be exactly the kind of overclaim this article is arguing against.

Why printed QR codes stop working walks through these failure modes from the diagnostic side, useful once you already suspect one has happened to a code you printed.

The zero-dependency escape hatch

A static code depends on none of this. There's no domain to lapse, no company that needs to stay in business, no subscription to miss a renewal on, because the destination is inside the printed pattern itself rather than behind a redirect. Every failure mode in the section above requires a redirect step to exist in the first place; remove that step and the entire list of risks becomes irrelevant to that particular code, permanently.

That's why when a static QR code is the right choice leads with permanence: a WiFi network, a vCard, an offline payload, anything that genuinely needs to outlive any vendor relationship, including this one, belongs on a format with no vendor relationship to outlive in the first place. The trade-off is real too: no editing, no analytics, and no ability to disable the code if the destination itself ever goes bad, which is why this isn't a blanket recommendation, only the honest answer for placements where the dependency this article describes simply isn't a risk worth taking on. For everything else, dynamic remains the right tool; it just isn't a free one, and the cost isn't only the subscription fee.

What this means for your next campaign

Run the checklist above against any dynamic QR vendor before a volume print run, this one included, and take a vague or evasive answer as information in itself. Where a platform has published a clear answer, especially the uncomfortable ones, that's worth more than a polished feature list. Where it hasn't, editing a dynamic code after it ships at least limits how much damage a bad destination can do while you're deciding whether the dependency is one you're willing to keep carrying, and choosing a QR platform in India turns this same checklist into a full procurement comparison across the specific things an Indian buyer needs to verify.

Ask the question before the print run, not after the redirect stops resolving. By then the artwork is already on the shelf, and the checklist becomes a post-mortem instead of the due diligence it was meant to be.

Read our trust and disclosure page