Skip to content
Security Tool

QR Allowlist Builder

Build a domain allowlist for your QR codes: add and remove domains, test URLs against the list, and import or export the list as JSON. Everything runs in your browser and nothing is uploaded.

1. Manage the list

Example: example.com — enter the bare domain, without a scheme or path.

The list is empty. Add your first domain above.

2. Test a URL against the list

Example: https://shop.example.com/offer

3. Import / export JSON

Example: {"allowSubdomains": false, "domains": ["example.com"]}

{
  "allowSubdomains": false,
  "domains": []
}

This list lives only in this browser tab. Export it to keep a copy, and import it to restore one.

How a QR domain allowlist actually protects you

An allowlist is a simple promise: QR codes your organisation publishes may only point at domains you have approved. That sounds modest, but it closes a real failure mode. Campaigns accumulate redirect services, agency-owned domains, shortener links, and microsites that nobody remembers. When a domain lapses, an attacker can re-register it and inherit every printed code that points there. A reviewed list of approved domains turns that slow drift into a visible decision: if a domain is not on the list, the code does not ship.

The hard part is not the list; it is the ownership. Every entry needs a named owner and a reason, even if that record lives outside this tool in your own tracker. An entry nobody owns is an entry nobody will remove when the campaign ends. Review the list whenever a campaign closes, a domain is retired, or a vendor relationship changes, and on a fixed schedule as well. Quarterly suits most teams. At each review, confirm that every domain still resolves to the site you expect — a domain that now serves a parking page or someone else's content has already failed the test.

Subdomain matching is the decision most teams get wrong. Allowing subdomains of a domain you fully control is reasonable: your own team runs every subdomain. Allowing subdomains of a large shared platform is not, because other people can create subdomains there — your approval would extend to strangers. Keep subdomain matching off by default, and list each subdomain you actually use. The extra entries cost nothing; the blanket permission can cost a great deal.

An allowlist is also not a safety verdict. It says the domain is approved, not that the page is safe. An approved site can host a compromised page, a misleading form, or an open redirect that bounces visitors elsewhere. Pair the list with content review of the pages you link to, HTTPS everywhere, and monitoring that notices when a linked page changes. Treat the allowlist as one gate in a chain — the gate that stops the obvious mistakes, like a code pointing at a personal file-sharing link or a lookalike domain a tired campaign manager typed from memory.

Finally, make the workflow kind to the people who use it. If adding a legitimate domain takes a week of approvals, teams will route around the list with shorteners and personal domains, and you will have less control than before. Give campaigns a fast, reviewed path to add a domain with an expiry date, and an equally fast path to remove one. The goal is a list that reflects reality — every entry owned, current, and checked — not a longer list.

Frequently Asked Questions About QR Allowlists

Does an allowlist guarantee a QR code is safe?

No. An allowlist only guarantees the destination domain is one you approved. An approved site can still host a compromised page, a misleading form, or an open redirect. Use allowlists as one layer alongside content review, HTTPS, and monitoring of the pages you link to.

Should subdomains be allowed when a domain is listed?

Only when you mean it. Allowing subdomains of a large platform hands trust to every subdomain, including ones other people can create. Keep subdomain matching off by default, and list each subdomain you actually use. Turn it on only for domains you fully control.

What belongs on a QR allowlist?

The domains your organisation owns and operates, plus any redirect or shortener domains you run yourself. If a campaign needs a new domain, add it through a review step with an owner and an expiry date, rather than letting anyone add entries casually.

How often should an allowlist be reviewed?

Review it whenever a campaign ends, a domain is retired, or a vendor relationship changes, and on a fixed schedule — quarterly suits most teams. Remove entries nobody owns, and check that every remaining domain still resolves to the site you expect.