Privacy Policy
Last updated 26 September 2026
This policy has two audiences. Customers have a KeeperQR account. Scanners point a phone at a QR code a customer printed, and have probably never heard of us. Scanners never agreed to anything, so we keep what we record about them deliberately small.
1.Who is responsible
KeeperQR is operated by KeeperQR, Oregon, United States. We are the controller of personal data about customers, visitors to our websites, and people who contact us or report abuse.
For scan analytics, the customer who published the code is the controller and we process that data on their behalf under our data processing addendum. We are a controller in our own right for the narrow processing we do on scan requests to keep the service safe: filtering bots, limiting abuse, and checking destinations. If you scanned a code and want a scan record removed, contact whoever published the code. If you can’t tell who that is, email us and we will pass your request on.
2.Customers
- Account details: your name, email address, and whether it is verified. If you sign in with Google, we also receive your Google profile image and store a copy of it, along with the sign-in tokens Google issues.
- Security details: passkey public keys, an encrypted two-factor secret and hashed backup codes if you enable them, and the hashed one-time code and link we email you to sign in, which expire after 15 minutes.
- What you create: workspaces, campaigns, QR codes, destinations and routing rules, uploaded logos, custom domains, and a change history for each code recording which teammate changed what.
- Settings: your time zone, notification preferences, and default code styles.
- Billing state: your plan, any legacy trial dates, and identifiers linking you to your record at Stripe. Card details go to Stripe and never reach us.
- Signup source: if you arrived from a campaign link or another website, the campaign parameters, referring site, and landing page, saved to your account when you sign up.
- Teammates you invite: their email address, and the invitation we send them.
3.People who scan a code
For each scan of a customer’s code, we store:
- The time of the scan and which code was scanned.
- Country and city, estimated from the network by our hosting provider. We do not use GPS and do not ask the device for its location.
- Device type, operating system, and browser, reduced to broad categories such as “mobile” or “iOS”. The full user-agent string is not stored.
- The website the scan came from, if the browser reports one, as a domain name only.
- A keyed one-way hash of the IP address, used to tell repeat scans from distinct ones and to cap unusually heavy scanning.
- A masked form of the IP address, such as 1.2.***.***.
We do not store the IP address with the scan record. It is hashed and masked the moment the scan arrives. The hash is keyed with a secret we hold, so it cannot be reversed by trying every possible address. It is still treated as personal data.
A normal scan goes straight to the customer’s destination: no cookie, no page in between, and no device fingerprinting. There are two exceptions:
- If a customer protects a code with a password, the scanner sees a password prompt. Unlocking it sets a cookie for 24 hours so they aren’t asked again. To stop password guessing, we record the IP address against the code for the length of the rate-limit window.
- If a code is inactive, paused, or unknown, the scanner sees a page from us saying so. These pages, and the password prompt, are served entirely by us: they load nothing from third parties.
Scans by bots, link previews, and scripted clients are redirected but not recorded. Our hosting provider’s network keeps its own short-lived request logs, which include IP addresses, to operate and secure the service.
4.Visitors, reporters, and people who email us
- Website analytics: our marketing site and our sign-in, sign-up, and report pages use Vercel Web Analytics. It counts page views without cookies and does not track anyone across websites. Pages inside the signed-in app are not tracked.
- Bot protection: the sign-in and sign-up pages, and the page where you enter an emailed sign-in code, run an invisible browser check from Vercel to stop automated sign-ups.
- Rate limiting: to stop abuse, sign-in and sign-up emails, sign-in code attempts, invitation, code creation, and report requests are counted per IP address or email address for a short window.
- Abuse reports: the report form collects the code, your reason, any details you give, and your email address if you choose to give it. It arrives with us as an email.
- Email: when you write to one of our addresses, we keep the message, its sender, recipients, and attachment details so we can deal with it.
5.Cookies
All our cookies are first-party. Most are needed to sign you in or to remember a choice you made. One, qw_first_touch, records which campaign or website brought you to us. We do not use advertising cookies or third-party tracking cookies. Our marketing site sets no cookies.
| Cookie | Purpose | Lasts |
|---|---|---|
| authjs.session-token | Keeps you signed in | Until you sign out, or 30 days |
| authjs.csrf-token, authjs.callback-url, and related sign-in cookies | Protect the sign-in flow, including Google sign-in and passkeys | The session or a few minutes |
| 2fa_challenge | Carries you through the two-factor step | 5 minutes |
| qw_first_touch | Remembers the campaign or website that brought you, so it can be saved to your account if you sign up | 30 days |
| keeperqr_qr_density | Remembers whether you view codes as a grid or a list | 1 year |
| qr_unlock_<code> | Set for a scanner who unlocks a password-protected code | 24 hours |
6.Why we use it
| Purpose | Legal basis (GDPR) |
|---|---|
| Providing your account, codes, redirects, and analytics | Contract |
| Billing and plan state | Contract, and legal obligation for records |
| Emails you asked for: verification, resets, invites, alerts, digests | Contract |
| Security, rate limiting, bot filtering, and destination safety checks | Legitimate interests in protecting the service, customers, and the public |
| Handling abuse reports and enforcing the acceptable use policy | Legitimate interests, and legal obligation where the law requires action |
| Signup source and cookieless website analytics | Legitimate interests in understanding which marketing works |
| Answering email and support requests | Legitimate interests, or contract where you are a customer |
| Scan analytics for customers | Processed for the customer, who determines the basis |
We do not sell personal data, and we do not share it for targeted advertising. We do not send marketing email, and we do not use personal data for automated decisions with legal or similarly significant effects. The automatic pause of a code flagged as unsafe is a decision about a URL, not about a person, and can be reviewed on request.
7.How long we keep it
| Data | How long |
|---|---|
| Account data and what you create | While your account exists. Deleting your account deletes it immediately. |
| Scan records | Until the customer deletes the code, clears their workspace’s scan history, or deletes their account. When a Free code sleeps after six months without a scan, its existing individual records are replaced with daily totals. Pro history is not condensed. |
| IP hash and masked IP on a scan | 13 months, after which the hash is erased and the masked address fully redacted. Records already condensed to daily totals no longer retain these fields. |
| Rate-limit records keyed by IP or email | Up to 30 days. |
| Email we receive, including abuse reports | Up to 3 years, or longer if needed for a legal claim or an ongoing abuse case. |
| Unlock cookie for a password-protected code | 24 hours. |
| Database backups | Database-provider backups expire on their rolling schedule. Separate encrypted recovery snapshots of account, workspace and code data are kept in GitHub for 30 days; they exclude scan history. |
| Operational logs | Application and request logs are sent to Better Stack for error monitoring and retained there for 3 days. |
| Payment and tax records | Held by Stripe under its own retention policy. |
8.Who else receives it
We use a small number of providers to run the service, listed with what each one receives on the subprocessors page. They process data only on our instructions.
Payments are sold through Link, by Stripe, acting as merchant of record. For your purchase, Stripe handles your payment details as an independent controller under its own privacy policy, and it shares with us only what we need to manage your plan. A data deletion request you make to Link will cancel your subscription with us.
Teammates in a workspace can see the workspace’s codes, analytics, and who changed what. Customers see the scan data for their own codes.
We may disclose data where the law requires it, to protect people from harm or fraud, or to enforce our terms. If the service is sold or transferred, data passes to the new operator, who must keep to this policy.
9.Where it is processed
We are based in the United States, and our database and application servers are there. Redirects are served from our hosting provider’s global network, so a scan is handled at a location near the scanner. When we transfer personal data out of the UK, the EEA, or Switzerland in our role as processor, we rely on the standard contractual clauses in our data processing addendum. Our providers use recognised transfer mechanisms, such as the EU–US Data Privacy Framework or standard contractual clauses.
10.Your rights
Depending on where you live, you can ask to access your data, correct it, delete it, receive it in a portable format, restrict or object to our processing, or withdraw consent you gave. You will not be treated differently for exercising these rights.
Much of this is self-serve. Settings lets you edit your profile and delete your account, and the Analytics page lets you export scan data as CSV.
For anything else, email support@keeperqr.com from the address on the account, so we can confirm it is you. We respond within 30 days, or sooner where your law requires. If we decline your request, you may ask us to reconsider by replying. If you are in the UK, the EEA, or Switzerland, you may complain to your data protection authority. Where a US state gives you the right to appeal, you may appeal to your state attorney general.
11.Children
Accounts are for people 18 and over, and we do not knowingly hold account data about children. Anyone can scan a customer’s code, and scan records do not tell us a scanner’s age. If you believe a child has created an account, tell us and we will delete it.
12.Security
Data is encrypted in transit and at rest. There are no account passwords: you sign in with Google, a passkey, or a one-time code we email you. One-time codes and the passwords you put on QR codes are stored only as hashes, two-factor secrets are encrypted, passkeys and two-factor authentication are available on every account, and every database query is scoped to a workspace. Access to production data is limited to the people who run the service. No system is perfect. If a breach affects you, we will tell you, and the relevant regulator, as the law requires.
13.Changes and contact
If we change this policy materially, we will email account holders before the change takes effect. The date at the top shows the current version.
Privacy questions and requests: support@keeperqr.com. Abuse reports: abuse@keeperqr.com. KeeperQR is based in Oregon, United States.