Reticle

Privacy Policy

Who we are

Reticle is a product of BlandCo, LLC, a Missouri limited liability company, which operates this site and is the data controller for the personal data this page describes. "Reticle", "we", "us", and "our" on this page all mean BlandCo, LLC. Contact details are at the bottom of this page.

The short version

QR code content

Everything needed to render a QR code (the URL, Wi-Fi details, contact info, calendar event, colors, logo, and so on) is processed locally in your browser. We do not receive, log, or store the content of the codes you generate. When you create a share link, the design is encoded into the link's URL fragment (the part after #); that fragment stays in the link itself and is not transmitted to our servers. The two exceptions are both dynamic links, where you explicitly ask us to store what the link points at: a destination URL, the contact details of a dynamic vCard, or the title, optional logo, and list of links a page shows, and, on a Pro account, the file you upload for a file link (see “Dynamic QR links” below).

Scanning QR codes

The QR code scanner decodes codes entirely in your browser. Any image you upload, drag, or paste is read locally and is never uploaded to us. If you choose to scan with your camera, frames are processed on your device and the camera stops as soon as a code is found, the tab is hidden, or you close it. We do not store the contents of codes you scan. When a decoded code contains a web address, the scanner sends that address, and nothing else, to Reticle to run the destination check shown with the result: we follow the address on our servers to find where it really goes, fetch the page's own title, description, and icons so that your device never contacts the site, and check the address against Google Safe Browsing, which involves sending the address to Google. The address is processed transiently to answer that one request; we do not log it, store it, or connect it to you. On a Pro account, the scanner's Preview this destination button additionally asks Reticle to render a screenshot of the destination page on our servers; the screenshot is generated on demand, held briefly in memory to serve repeat requests, and never written to disk or associated with you.

Information stored on your device

The site uses your browser's localStorage to remember, on your device only:

This never leaves your device and is not sent to us. You can clear it from the Recent panel (“Clear”) or by clearing your browser's site data.

Analytics and advertising

We use Google Analytics (via Firebase) and the Google Ads tag to measure how the site is used and how well our advertising performs. These services may set cookies and collect information such as your approximate location, device and browser, pages viewed, and interactions. This data is processed by Google. You can learn more in Google's Privacy Policy and control tracking with Google's opt-out tools.

Signing in (optional)

You can sign in two ways. If you sign in with Google, Google shares your name, email address, profile photo, and a Google account identifier with the app; you can revoke the app's access at any time from your Google Account permissions. If you create an account with an email address and password, we collect that email address, and Firebase Authentication stores your password in hashed form; we never see or store the password itself. We send a verification email to confirm the address is yours, and you need to click that link before you can sign in. Once your account is verified and ready to use, we send you one welcome email that explains how to get started. In both cases we use this information only to sign you in, to associate your saved codes with your account, to occasionally tell you about features of your account, to send you warning emails before a free link with no scans for 90 days is reclaimed, and, unless you turn off scan notifications for a dynamic link, to send you those notification emails. Those occasional feature emails are rare, are never a newsletter, and you can stop them by replying to one; turning them off does not affect your scan notifications.

A Pro account can invite others to a team. We store the invited email address on a pending invite for up to 7 days and, once accepted, the member's email address and display name on the team, where the owner can see them. A member can see the team's dynamic links, pages, scan analytics, style templates and brand kits, and any link a member creates is stored under the owner's account with a note of who created it. Leaving the team, being removed, or closing either account removes the membership. The invite email is sent through the same provider as every other Reticle email.

Saved codes

When you're signed in and choose to save a code, its details (content type, the data you entered, style settings, export size, an optional name, and any logo image) are stored in Google Firestore under your account so you can reload them across devices. Saved codes are private to your account. You can delete any of them at any time from the “My codes” panel; signing out stops new data from being saved.

Style templates

When you're signed in, you can save your current colors, gradient, shape, and logo as a named style template so you can apply it to any new code with one click. Its style settings and any logo image are stored in Google Firestore under your account so it syncs across devices. Style templates are private to your account, and you can delete any of them at any time from the Appearance panel. Signed out, style templates are saved only in your browser's local storage on this device (without the logo) and are never sent to us.

Dynamic QR links

A dynamic link (optional, signed-in only) is a short open-qr.link/… address you put inside a QR code so its destination can be changed later. (open-qr.link is our redirect domain, operated by Reticle with the same data handling described here; links created before we introduced it also keep answering at their original reticle.cloud/r/… address.) To make that work, we store on our servers (in Google Firestore, and, for the file of a file link, in Google Cloud Storage): the destination URL you set (plus any optional per-platform destinations and a go-live date, expiry date, or scan limit you choose), an optional name, whether the link is active, the code's style settings (colors, shapes, any logo image), and aggregate scan counts: a total, a per-day tally, a coarse device breakdown (mobile, tablet, or desktop), an hour-of-day tally, and a per-country tally, all counted in UTC and kept only as running totals. A link that serves a hosted contact page, an uploaded file, or a page stores those in place of a destination URL, as described in the next three paragraphs.

A dynamic vCard is a dynamic link that serves a hosted contact page instead of a redirect. For those links we store the contact details you enter (name, organization, title, phone, email, website, address) in place of a destination URL. That contact page is public by design: anyone who opens the link's address sees those details and can download them as a contact file, which is the point of a contact QR code. Enter only what you want to hand out, edit it any time from “My codes”, and delete the link to remove the page and its details.

A file link (Pro accounts only) is a dynamic link that serves a file you upload, in place of a destination or a contact page. We store the file itself on our servers, in Google Cloud Storage, along with its file name, size, and type, and we serve it to scanners ourselves rather than handing it to another company. That file is public by design: anyone who scans the code, or who has its address, can open and download it, which is the point of a file QR code. If it isn't meant for everyone, set a password on the link. We ask search engines not to index the files we serve, but that is not a substitute for a password, and a custom domain does not limit access either: a file link stays reachable at its open-qr.link address as well. We keep the file until you replace it, delete the link, or close your account; there is no automatic expiry. Replacing a file deletes the one it replaced, and deleting the link, or your account, deletes the file with it.

A page (Pro accounts only) is a dynamic link that shows a small hosted page instead of redirecting: a title and the blocks you place on it (text, images, buttons, social links, a contact block) plus the page's colors and font, stored in Google Firestore and editable at any time. Anyone who scans the code or opens the short link sees that page, so only put things on it you intend to publish. Deleting the link deletes the page and its contents.

We never keep a scanner's IP address or the raw user-agent string their browser sent, and the closest location we ever keep is coordinates rounded to about a kilometer (Pro links only; see “Per-scan analytics” below). On a Free account we keep no per-scan record at all, and nothing that identifies who scanned. To build the device breakdown we read the browser's user-agent string at scan time, sort it into one coarse bucket (mobile, tablet, or desktop), then discard it; only the per-bucket running count is kept. The country breakdown works the same way: our content-delivery network resolves an approximate country from the request as it passes through, we add one to that country's running count, and the IP address it was resolved from is never seen or stored by us. For a Free account that country tally is the only location signal we keep, and it is a country tally only, never a city, coordinates, or a route back to any individual scan. If the link's owner has set smart routing rules, so that one code sends different people to different pages, the language preference your browser sends with the request is read as well, to decide which destination to serve you. It is used for that one decision, on that one request, and is never stored. Google, as our infrastructure provider, transiently processes standard request data (such as the scanner's IP address) to serve the redirect, per Google's Privacy Policy. Only you can manage your dynamic links; deleting one from the “My codes” panel deletes its destination, any file it serves, and all of its scan statistics. Links owned by a Pro account additionally record each scan individually. That recording is automatic on every dynamic link the account owns, and it sends the scanner's IP address to a third-party geolocation provider to resolve an approximate city; we do not retain that address ourselves. See “Per-scan analytics” below for exactly what those records keep and for how long.

Scan notifications are on by default for dynamic links. While they're on, we email you once when that link gets its first scan and a weekly summary of its scan counts; the bell button in “My codes” turns them off for any link. Those emails are triggered by scan events, but they contain nothing about the people scanning: only the aggregate counts described above, plus your link's name and destination. We store your on/off preference and a one-time marker that the first-scan email was sent; your email address itself is read from your account's sign-in record when a notification is sent and is not stored with the link. For accounts created with an email address and password, notification emails are only sent once the address has been verified.

If a link's owner turns on password protection, scanning that link shows a password prompt before it redirects, or, on a file link, before the file is served. Reticle stores only a salted hash of that password, never the password itself, and there is no way for Reticle or anyone else to look up the original password from what is stored.

AI builder and AI auto design (optional)

The AI builder (the “Reticle AI” button, on the homepage and in “My codes”) is optional and signed-in only. What you type into the describe box, plus your device's time zone (so a request like “evenings” can become an actual schedule), is sent through our servers to Google's Vertex AI Gemini API, which returns a suggested dynamic-link setup: a destination, smart routing rules, a schedule, labels, a name, a plain-words walkthrough of what applying it would build, and, when relevant, a page design (a title, an optional tagline, button labels, and any button web addresses you already gave it), a suggested look for the code (colors, dot and corner shapes, and a logo icon choice from Reticle's built-in icon set), a contact card layout (the contact fields you described, with blanks for details you did not give it), or a password protection flag. AI auto design, in the Design Studio, is the same optional, signed-in-only mechanism applied to styling: a short style brief you type describing the look you want, plus up to three brand colors you choose to hand it and the code's content type, is sent through our servers to the same Gemini API, which returns style settings for you to review, a pattern, colors, and caption text, before you apply anything. When you ask it to redesign a look you already have, a summary of that look's current style settings is also sent, so it can plan the change. When the AI builder edits a link you already created, a summary of that link's current setup (its destination or contact fields, its page title and buttons, its labels, routing rules, schedule, and look, and whether a password is set but never the password itself) is sent to Gemini along with your description, so it can plan the change. Reticle never sends Gemini a password, and Gemini never produces one: that flag is only ever yes or no, and the password itself is one you type yourself when you apply the plan. We do not store the description you type or the suggestion Gemini returns. Nothing from that exchange becomes a saved code, a saved link, or any other record on your account until you choose to apply it, and applying writes only the fields you approved, the same as building a link by hand. The web addresses you fill into the suggested setup afterward, including one Gemini left blank for you to supply, and any password you set when applying it, are never sent to Gemini. What you type is also never sent to our analytics tools, which record only that the feature was used, not what was asked of it. How often you can use the AI builder and AI auto design is limited per account, and free accounts share one small monthly allowance across both. Google processes what we send it to generate that response, under the Google Cloud terms that govern its Vertex AI service, and does not use that content to train or improve its models; see Google Cloud's Vertex AI data governance documentation for the current terms.

We do keep a record of how much the AI builder and AI auto design are used, so we can watch what it costs us, whether it is working, and whether anyone is abusing it. That record is attached to your account and holds only numbers and labels: how many times you used it, how many requests to Gemini those uses took, how many tokens those requests consumed, how many of them did not succeed, which plan your account was on, and when you last used it. It never includes what you typed, what Gemini suggested, or the reason a request could not be answered. The day by day detail is kept for about 35 days and then deleted automatically; the running totals stay for as long as the account does, and the whole record is deleted when you delete your account.

Per-scan analytics (Pro)

While an account is on Pro, every dynamic link it owns keeps a detailed record of each scan. This is automatic: there is no setting to turn it on, and no way to turn it off, for one link or for the whole account. Upgrading to Pro starts this recording on the links that account already has; removing Pro stops it on all of them. If you are weighing an upgrade, this is part of what upgrading does: your dynamic links begin recording the people who scan them, in the detail described below. Those records are also what a webhook you configure sends, one event per scan.

Free accounts are not affected by any of this. Their dynamic links keep only the aggregate scan counts described above: no per-scan records, nothing about who scanned, and the scanner's IP address is never seen or stored by us and is never sent to a geolocation provider.

Each of those per-scan records contains: the time of the scan, an approximate city and region when one could be resolved, the country, approximate coordinates rounded to two decimal places (about a kilometer), a coarse device class (mobile, tablet, or desktop), the scanning device's operating system including its major version when available (for example, “iOS 18” or “Android 15”), the browser family (Safari, Chrome, Firefox, Edge, Samsung Internet, or the in-app browser of Instagram, Facebook, TikTok, Snapchat, LinkedIn, or WeChat), which destination was served (the link's default destination, an iOS or Android override, or a smart routing rule; which rule matched is deliberately not recorded), the domain of the referring site if the scan arrived by following a link somewhere else, and a visitor key: an identifier we set in a cookie on the short-link domain the first time a device scans any link served from it, or, when the browser does not keep cookies, a one-way hash derived from the request. The key is stored in a form specific to each account, so it lets a link's owner see whether a device has scanned that code before, and it cannot be matched across accounts. That cookie is named __session, lasts one year, and is set only on scans of Pro links; scanning a Free account's link never sets it. To resolve the city, region, and coordinates, the scanner's IP address is sent to a third-party geolocation provider; we do not retain that address ourselves, and it is not written to our database. A city is often unavailable, and many records carry a country with no city or coordinates. That's expected, not an error, and it happens for two reasons: that lookup is rate-limited, and we keep a city, region, and coordinates only when the provider's answer for the country agrees with the country our own network determined separately. Scans arriving over a VPN, a proxy, or some corporate networks routinely fail that agreement check, so we record no city or coordinates for them.

These records are kept for about 90 days and then deleted automatically. The link's owner can delete all of them at any time from the “My codes” panel, and export whichever records are currently loaded there to a file. Even with these records being kept, we still never store the scanner's IP address or the raw user-agent string their device sent, and the only location we keep is the approximate one listed above: a city and region when resolvable, a country, and coordinates rounded to about a kilometer.

Payments (Reticle Pro)

If you subscribe to Reticle Pro, payment is handled by Stripe. Your card number and billing address go directly to Stripe and never touch our servers; we never see or store them. Stripe shares with us your subscription's status (for example, active or canceled), its billing period dates, whether the latest payment succeeded, and identifiers for you as a Stripe customer, and we store those under your account so the site can show your plan and unlock Pro features. Stripe processes your payment data as described in Stripe's Privacy Policy. Billing records are kept for as long as your account exists, and as required for tax and accounting.

Service providers

Reticle is built on Google services: Firebase Hosting (serving this site), Firebase Authentication (Google and email/password sign-in), Cloud Firestore (saved codes, style templates, and dynamic links), Cloud Storage (the files that file links serve), Cloud Functions (the dynamic-link redirect, and serving those files), and Google Analytics / Google Ads (measurement). Web fonts are served directly from reticle.cloud; font requests do not go to any third party. Your use of these is also subject to Google's Privacy Policy. If you use the AI builder or AI auto design, your typed description or style brief, your device's time zone, up to three brand colors, the code's content type, and, when redesigning an existing look, its current style settings, are sent to Google's Vertex AI Gemini API to generate a suggested link setup or style, under the terms described in the “AI builder and AI auto design” section above. Unless you turn off scan notifications for a dynamic link, those emails are delivered by Resend, which receives your email address and the email's contents (your link's name, short URL, destination, and scan counts), subject to Resend's Privacy Policy. For links owned by a Pro account, a third-party geolocation provider receives the IP address of that link's scanners, to resolve an approximate city, and receives nothing else. A Free account's links never reach it. If you configure a webhook on a Pro account, each scan's details (the same fields your analytics show: device, browser, approximate location, and which link was scanned; never the scanner's IP address) are sent to the endpoint you chose, which may be operated by a third party such as Zapier or Make. If you subscribe to Reticle Pro, Stripe processes your payment, as described in the Payments section above.

Your choices and rights

Depending on where you live (for example, under the GDPR or CCPA), you may have rights to access, correct, or delete your personal data, and to opt out of certain processing. You can exercise the core of these directly: delete saved codes in “My codes”, style templates in the Appearance panel, and dynamic links in “My codes” (deleting a file link deletes the file it serves, and you can replace or remove that file on its own from the link's panel), revoke Google access from your Google Account (for Google sign-in), opt out of analytics with the tools above, and clear on-device data from your browser. On a Pro account you can also delete a dynamic link's per-scan records at any time, without deleting the link, from that link's panel in “My codes”. For other requests, contact us using the details below.

Children

Reticle is a general-purpose tool and is not directed to children under 13 (or the equivalent minimum age in your country). We do not knowingly collect personal information from children.

Changes to this policy

We may update this policy from time to time. When we do, we'll revise the “Last updated” date above. Significant changes may be highlighted on the site.

Contact

Questions about this policy or your data? Contact us at privacy@mail.reticle.cloud. The data controller is BlandCo, LLC.