Last updated 17 October 2026 · Effective 17 October 2026 · Operated by Agam Sharma, sole proprietor, trading as Elite QR, Mehsana, Gujarat, India
The short version. If you create an account we store your profile basics and the QR codes you make. When someone scans one of your codes we record the scan, including the scanner's IP address, which we use to show an approximate city and a device count. Opening a restaurant menu records less: a city, a table number and a time, with no IP address, deleted after 90 days. Opening an ID card records nothing at all, but the card itself holds somebody's details, and whoever uploaded it decided what goes on it. We do not sell anything to anyone. You can delete it all yourself (codes from Settings, card batches from Bulk Studio) or by emailing us.
Elite QR ("we", "us") is a QR code platform operated by Agam Sharma, a sole proprietor based in India, at Mehsana, Gujarat 384002, India. Agam Sharma is the data fiduciary for the purposes of India's Digital Personal Data Protection Act, 2023.
For any privacy question, or to exercise the rights in section 9, contact customer@eliteqr.in.
The free QR generator collects nothing at all. The tool on our home page that makes a code without an account runs entirely inside your browser. The text you type is turned into a QR code by JavaScript already on the page, and the file you download is produced on your own device. Nothing you type there reaches us, we keep no record that you used it, and it sets no cookie. If you never sign in, this is the whole of it.
The rest of this section is about account holders. You sign in either with Google or with an email address and a password. If you use Google we never see or store your Google password. If you set a password with us it is held by Google Firebase Authentication and stored only in hashed form. We cannot read it, and neither can anyone here.
| Data | Why |
|---|---|
| Email address, display name, profile photo URL | To identify your account and show who is signed in. |
| The QR codes you create: title, destination, design, and any routing rules such as a geo-fence location or a time cutoff | They are the product. Without them there is nothing to route. |
| Files you upload (PDFs, images, 3D models) | So a hosted-file code has something to serve. |
| Your plan, its expiry, and how many codes you have made this month | To apply the free-tier allowance and to know whether you are a subscriber. |
| If you run restaurants: the colour, icon and order you give each venue in the restaurant dashboard | So every device you sign in on shows your venues the same way. Which venue a particular device opens automatically is stored on that device only, never by us. |
| Card batches: the rows of a spreadsheet you upload to make ID or member cards, which usually contain other people's names, ID numbers and photographs | To render the page each card opens. See section 3 for what a cardholder sees and section 10 if any of them are under 18. |
| Emergency card content: if you make an Emergency code, whatever you put in it. That may include a blood group, allergies, a medical condition or medication, and the name and number of someone to call | It is the content of the code, so it is stored alongside your other codes. See the paragraph below. This one is different from the rest, in both directions. |
| Fault records: when something breaks we record what broke, where, and how many times. Message text is stripped of email addresses, phone numbers and anything token-shaped before it is stored, and a report sent automatically by your browser carries no message at all. Only which page failed and in what way | So that a failure is noticed by us rather than discovered by you. Kept 90 days; see section 8. |
If you upload a card batch you are responsible for the people in it. You decide what goes on the card and you must have a lawful basis for putting it there: consent, employment, or whatever applies to your organisation. We do not check that you do, and we have no relationship with the people named. Only upload details you are entitled to publish to anyone holding the card.
An Emergency code is meant to be read by strangers, and that cuts both ways. Everything you put in one is encoded into the printed code itself, so anyone who scans it can read all of it. That is what makes it work when somebody is hurt, and it means it is not confidential. Do not put anything in there you would not hand to a passer-by. The other side of the same design is that these codes are never routed through our servers: the details are in the code, nothing is looked up, and we do not learn when, where or whether one is ever scanned. We hold the copy you saved so that you can reopen and reprint it, and nothing more. Delete the code and that copy goes with it.
If the card is for someone else, the same rule applies as for card batches. A school, a club or an employer making these for other people must have a lawful basis for recording their health details, and must have told them what is on the card. We do not check that you do. If any of them are under 18, read section 10.
Our lawful basis is the performance of our contract with you (these terms), except for the analytics described in section 4, which rests on consent you can withdraw by blocking those cookies.
Vault PINs are stored separately from the code they protect and are never returned to a browser. They are not hashed (we need the original value to check a PIN), so treat a Vault PIN as a convenience lock, not as encryption, and do not reuse a PIN from anywhere else.
This section is about visitors, who usually have no account and no relationship with us. When a dynamic QR code or a hub page is opened we record:
We do not use cookies to track scanners across sites, and we do not build advertising profiles.
What the code's owner sees: the city, country, device, browser, time, and a count of unique devices. They do not see IP addresses. The IP is used to compute that count on our server and is never sent to the owner's browser or included in any export.
If a code has a geo-fence, your browser will ask permission for your precise location. That check happens entirely in your browser; the result is not sent to us or stored. Declining means the code will not open.
Some venues use Elite QR to publish a menu, with a separate code printed for each table. Opening one of those records a menu view, which is a smaller record than a scan:
We do not store your IP address for a menu view. A menu view says that somebody was in a particular restaurant at a particular time, which is more revealing than a link being opened, so we keep less rather than more. It is used to tell the venue how many people looked at the menu.
Menu views are deleted automatically after 90 days.
The venue writes its own menu, prices and descriptions. Elite QR hosts that content and does not sell food, take payment for it, or check that it is accurate: ordering, where a venue has it switched on, is passed to the venue's own staff.
If you place an order we record the dishes and quantities, the table, the time, and any note you type, and we pass all of it to that restaurant, which is the entire point of sending it. We ask for no name, no phone number and no payment; you pay the restaurant however you normally would.
If a waiter takes your order on their phone, the same things are recorded (dishes, quantities, the table and any note), plus which of the restaurant's staff links sent it, so the restaurant knows who took it. Nothing about you is added.
If you order by speaking (where a restaurant has switched it on), your browser turns your speech into text using your phone's own speech service (Google on Android and Chrome, Apple on iPhone), and that text is sent to us and to Anthropic to match it against the menu. We do not record or keep your voice, and we do not keep the text after the dishes are put in your basket. Nothing is ordered until you press Send yourself.
If you ask for a table (where a restaurant takes bookings through its menu), we record the name, mobile number, party size, date and time and any note you give, and pass them to that restaurant so they can confirm. A walk-in added to a restaurant's waitlist by its staff is recorded the same way. These are kept until the restaurant deletes them.
If you join a restaurant's guest list. Some restaurants let you tick a box, after ordering, to hear from them. Only if you tick it do we store your mobile number (and a name if you give one) for that restaurant only, with the date you agreed and how many times you have ordered there since. If the restaurant runs a loyalty reward (for example, every fifth visit), that same visit count is what decides when you have earned it, and we also note how many rewards they have given you, so the same one is not offered twice. Only the restaurant's owner can see it; their waiters cannot, and no other restaurant can. You can leave at any time from the same place on the menu ("Stop hearing from them"), which deletes your number, or by asking the restaurant or us. Any message you then receive is sent by the restaurant from its own WhatsApp or phone, not by Elite QR, and we never use these numbers ourselves.
If you work at a restaurant that uses Elite QR. If the owner adds you to their team, we store your email address and your role against that venue, and the record of which venue you joined and when. Changes you make to a bill (a dish taken off, a discount) are recorded with your name or account, because a bill that changes needs to show who changed it. If you turn on Phone alerts, we store the push address your browser gives us for that device (a long random web address belonging to Google, Apple or Mozilla's push service, not your phone number) so we can wake it for new orders; turning alerts off, or removing you from the team, deletes it.
"Pay for what I ordered". Your phone keeps a random tag, made on the phone, that it sends with your orders so the bill can show which dishes came from it. It is not linked to your name or number and identifies nothing outside that one bill.
The note is free text and it goes to the kitchen. People use it for allergies and for how they want something cooked, which is exactly what it is for, but it reaches the venue's staff as you typed it, so do not put anything in it you would not hand across the counter on a slip of paper. Once an order is with a restaurant, what they do with it is governed by their own practices, not ours.
An organisation (a school, an employer, an event) can print a card for each person, where scanning the code opens a page showing that person's details. If your name is on one of those cards, this section is about you, and you have rights here even though you have no account with us.
The organisation decides what goes on the card, not us. They upload a spreadsheet and choose which columns to show. Typically that is a name, a class or department, an ID number, and sometimes a photograph. We do not choose those fields, we do not verify them, and we cannot correct them. The organisation can. In the language of the Digital Personal Data Protection Act, they are the data fiduciary for the contents of the card and we process it on their instructions.
What the link protects. Each card's address contains a long random code. It is not a number you can count up from, and holding one card tells you nothing about anybody else's. You cannot get from one person's card to another's by editing the address. The pages are excluded from search engines and produce no preview image in chat apps, so a card cannot be found by searching for somebody's name and does not display their face when the link is pasted into a group.
But a card link is a key, and anyone holding it can open the page. There is no password. If you photograph, forward or post the code, whoever receives it can see those details. That is the trade a printed card makes: it has to work for anyone the cardholder shows it to.
Opening a card records nothing. No IP address, no city, no device, no count, no timestamp. Unlike a scan or a menu view, we store nothing at all when a card page is opened. A record of when a named person's card was scanned, and by how many people, is not something we want to be holding.
Google Analytics runs on our website and sets its own cookies. Note that it also runs on the scan and hub pages, so it loads for people who merely scanned someone's code and never created an account. See Google's privacy policy. You can prevent it by blocking third-party scripts or cookies in your browser; the codes will still resolve normally.
Razorpay processes all payments. Card numbers, UPI IDs and bank details are entered on Razorpay's own checkout and never reach our servers. We store only the order id, the amount, the plan bought, and whether it succeeded. See Razorpay's privacy policy.
We do not sell personal data, and we do not share it for anyone else's advertising. We share it only with the services that make the product work:
We will also disclose data where the law requires it.
We send a small number of emails about your own account: that a free trial is ending or has ended, and that a paid plan or a venue's Business subscription is about to expire or has expired. They are sent from customer@eliteqr.in and you can reply to them; a person reads the replies.
These are service messages, not marketing, and they carry no unsubscribe link. That is deliberate and it is the line we hold: every one of them exists because of something your account did, and none of them advertises anything. If we ever want to send you news, offers or anything promotional, that is a different thing. It would need your consent, a working unsubscribe, and a change to this policy. We will not blur the two.
If you would rather not receive even the service messages, tell us at customer@eliteqr.in, though you may then not hear that a trial is about to end.
Our infrastructure providers operate globally and your data may be processed outside India, including in the United States and the European Union, under those providers' own safeguards.
Under India's Digital Personal Data Protection Act, 2023 (and comparable rights elsewhere), you may ask us to show you what we hold, correct it, delete it, or withdraw consent. Write to customer@eliteqr.in and we will respond within 30 days.
Most of it you can do yourself: your codes and their entire scan history are deleted from the Settings panel, immediately and permanently, and your card batches from Bulk Studio. Clearing everything covers both.
If you scanned someone's code and want the record removed, email us with roughly when and where it happened. We will find it and delete it; you do not need an account to ask.
If your details are on somebody's card (a student ID, a staff badge, an event pass), you can write to us at customer@eliteqr.in and we will take that card offline. Send the link or a photograph of the card so we can find it. You do not need an account and you do not need the organisation's permission to ask us. We will tell them the card was removed, because their cards will stop working and they need to know why, but we will not wait for their agreement first. To have the details corrected rather than removed, ask the organisation. They wrote them and only they can change them.
If you are not satisfied with our response, escalate to our Grievance Officer (section 13). If you are still not satisfied you may complain to the Data Protection Board of India.
Elite QR is not intended to be used by anyone under 18. We do not knowingly let a child create an account, and if you believe a child has given us data directly, tell us and we will remove it.
Card batches are the exception, and we would rather say so plainly than leave it implied. A school that makes student ID cards is uploading children's personal data to us. We do not collect it from the child and we have no relationship with them; the school does, and the school decides what goes on the card. But the data is here, on our servers, and pretending otherwise would be dishonest.
If you are a school, a coaching centre, or anyone else making cards for people under 18: India's Digital Personal Data Protection Act, 2023 requires verifiable parental consent before a child's personal data is processed, and forbids tracking or behavioural advertising directed at children. Obtaining that consent is your responsibility, not ours. We have no way to ask a parent and no way to check that you did. It also forbids processing that is likely to cause a detrimental effect on a child, which is worth weighing before you put a photograph and a full name on something a stranger can scan.
Emergency codes for children are the sharpest version of this. A bag tag carrying a child's name, blood group and a parent's mobile number is genuinely useful and is also, to anyone who scans it, a complete introduction to that child. It is your decision, not ours, and the consent rule above applies to it in full. Our own advice is the boring one: a first name and a number is usually enough for a stranger to do the right thing, and a full name plus a home address is more than they need.
A parent or guardian can ask us directly. Write to customer@eliteqr.in with the card link or a photograph of the card. You do not need an account, you do not need to go through the school, and we will remove the card without asking them first.
Payment details never touch our servers. Vault PINs and their destinations are held where no other visitor can read them, and PIN attempts are rate-limited. Access to your own codes requires you to be signed in, and passwords are never stored in a form we can read.
No system is perfectly secure, and we will not pretend otherwise. If we discover a breach affecting your data we will notify you and the Data Protection Board without undue delay.
If we change this policy we will update the date above. Material changes will be announced in the app before they take effect.
Agam Sharma (sole proprietor), trading as Elite QR
Mehsana, Gujarat 384002, India
Email customer@eliteqr.in
Grievance Officer: Agam Sharma, customer@eliteqr.in. Response within 30 days of receipt.