Privacy

Last updated 27 August 2026

Using LoupeKit needs no account. The identifier the product runs on is a random UUID your browser generates on first run and keeps locally - nothing to sign up for, no email, no password. That covers every feature except one.

The exception is team sharing, and it is opt-in. Handing a palette to a colleague means the product has to know who the colleague is, so that feature asks for an email address - the only personal data in the whole system. If you never turn it on, none of it applies to you and no address is ever stored.

This page describes every byte that leaves your browser, field by field. It is written to be checked against the code, not taken on trust.

Who is responsible for this

LoupeKit is made and operated by the company below, which is the data controller for everything on this page. Write to that address about anything here - access, correction, deletion, a copy of your data, or an objection - and you will get a person rather than a form.

Company

Apptiary s.r.o.

Address

Tylova, 831 04 Bratislava, Slovakia

Company no.

57 466 408

Tax no.

2122 765 986

VAT no.

SK2122765986

Register

Commercial Register of the City Court Bratislava III, section Sro, insert 196639/B

Email

info@apptiary.com

Running an audit

A Vibe Audit is the only feature that sends anything to us, and it runs only when you press the button. It sends the payload below to https://api.loupekit.com and nothing else.

Headings and button labels are the only free text in the payload. Before they leave the page they are stripped of email addresses and of long identifier runs - 24 characters or more without a break, the shape of an API key or a session token - then truncated, in that order, because truncating first can leave a recognisable fragment that the pattern no longer matches. The server truncates everything a second time, on the principle that a script running inside someone else's page is not a trustworthy place to enforce a limit.

What is never sent

• - Body text, paragraphs or any content below the headings listed above
• - Values typed into any field, including passwords, emails and payment details
• - Cookies, localStorage, or session tokens
• - Full URLs. Only the hostname is transmitted - never a path, query string or fragment
• - Anything at all from a tab you did not run the audit on
• - Screenshots, markup, or a copy of the page in any form

What is stored afterwards

Two rows. One in a users table, keyed by your device id, holding your remaining free audits and - if you buy Pro - your plan and Stripe customer id. One in an aggregate table recording the hostname, the score and the verdict.

The aggregate row carries no device id. Not omitted by policy - the table has no column for one. Joining a device to the domains it audited would reconstruct browsing history, which is the one thing this extension exists to avoid doing.

The plans screen

Opening it asks our API what Stripe currently charges, so the amount you read is the amount you will be charged rather than a figure typed into a release. It is the one call the extension makes that carries no device id at all - the route asks for none, and requiring one would put an identifier on the wire for everybody who so much as looks at the prices. Nothing is sent, nothing is recorded, and if the call fails the screen shows the amounts built into the extension instead. Buying is a separate press, and the payment itself happens on Stripe’s own pages; card details never reach us.

A licence and the browsers on it

Buying Pro produces one licence key, held against the account that bought it, and it is what turns Pro on for up to three browsers. The row holds the key, the plan, the Stripe customer and subscription ids, and nothing else. The key can be handed to somebody else - whoever holds it activates a browser by signing in to an account of their own and entering the key there, and they cannot read the buyer’s address or change the plan. The account is only who is asking; the key alone decides which licence.

Each activated browser adds a row carrying its device id, a short label and browser name that that browser reported about itself (“Chrome on macOS”, “Chrome 141”), two timestamps - when it was activated and when it last asked the API what it is entitled to - and the hash of a secret handed to that browser at activation. The secret itself is never stored here and never leaves that browser; it is what stops a device id copied off a settings screen turning Pro on somewhere else. The rest exist so you can tell three rows apart on loupekit.com and remove one.

How often a licence takes on a browser it has not seen before is counted - the licence, the browser and the moment, kept for thirty days and then deleted. Ten in that window and the next one is refused, and the refusal is written to the owner’s activity trail. It is there so a key that has got out is something its owner can see rather than something they are billed for.

No address is stored against a device, and nothing derived from one. A list of your browsers with the addresses they were seen from is a location history, and it would tell you nothing you could act on. The last-seen time moves only when that browser asks about its own plan - there is no timer and nothing runs in the background to report a device is still there.

Replacing the key from the dashboard unlinks every browser on it at once, which is what makes an exposed key recoverable. Removing a device frees its slot; that browser is back on the free plan the next time it asks.

Abuse limits

The API counts requests per network address so a script cannot mint device ids in a loop and exhaust the service. The counter belongs to Cloudflare, resets within a minute, and holds a number - your address is never written to our database, never logged, and never joined to an audit, a domain or a device id. Your browser reveals its address to every server it contacts, including this one; the limit reads it and stores nothing.

Vulnerability dating

On the Stack tab, Pro users can press a button that checks the detected versions against published security advisories. It is the only part of that tab that leaves your browser, it only ever runs when you press it, and it is listed here on its own because it is a second request to us - the audit is not the only one any more.

• What is sent is a list of package names and version numbers, such as  jquery 3.4.0. That is the whole request body.
• No hostname, no URL, no page title, no headings, no page content. Unlike an audit, there is nothing in this request that identifies the site you are on.
• Nothing from it is written to our database. Audits are counted per domain; this is not counted at all, because there is no domain in it to count.
• Our API asks OSV.dev, Google's aggregator over the GitHub Advisory Database and the CVE list. Your browser never contacts them, and they never see your address.
• Answers are cached at our edge under a hash of the package list and under each advisory's own identifier. Neither key contains anything about you or your device.

A result says a version has a published advisory against it. It does not say the page can be attacked through it - that depends on how the library is used, which nothing outside the browser can see. Silence is equally narrow: versions we could not read, or could not resolve to a package, are reported as unchecked rather than counted as clean.

Everything else stays local

Stack detection, the colour palette, the font matrix, the asset inventory, the box model, live element edits, the class optimizer, the copy sanitizer and the responsive tester all run entirely inside your browser. None of them sends anything to us on its own. Results leave when you copy them or save the asset archive - both built on this device - and, if you have signed in, when you press Share on a palette or an environment. That third one is the only route by which anything extracted reaches a server, it needs an explicit press every time, and what it sends is described under "Accounts and team sharing" below.

Four of these keep something between sessions, and all four keep it here. Your audit history is the last twenty scores, with the domain, the verdict, the date and up to six earlier scores for the same site so the panel can say whether it got worse - it is stored in this browser and is never uploaded, because the same list held on our side would be a record of which sites you looked at, which is the thing our anonymous audit log is deliberately built not to contain. The stack comparison holds exactly one pinned report. The environment diff holds exactly one captured page - its stack, palette and fonts, plus the hostname and the path, never the query string. The colour picker keeps the last hundred colours you sampled alongside the site each came from, for the same reason and under the same rule. Each is replaced rather than accumulated, cleared from its own panel, and removed with the extension.

The colour picker takes a screenshot

There is no way to read a rendered pixel out of a page. The colour on screen at a point is the result of a background, an image, a gradient, an overlay, opacity and blend modes, and no single element reports it - so the loupe magnifies an image of the tab instead. That image is captured by the browser, handed straight to the page script that draws the lens, and discarded when the lens closes. It is never written to disk, never uploaded, and never taken of a tab you have not opened LoupeKit on: the capture runs on the same one-tab grant every other feature does. LoupeKit hides its own panel and overlays for the instant the picture is taken, so what you sample is the site rather than our own interface.

The full-page capture scrolls your page

A browser can only photograph the part of a page that is on screen, so a picture of a whole page is that same one-tab capture repeated with the document scrolled underneath it. While it runs, the page is scrolled from top to bottom, our own panel and toolbar are hidden, and any element the site renders as fixed or sticky is hidden after the first screen so a header appears once rather than a dozen times. Every one of those changes is undone when the capture finishes - including if it fails, and including if the panel is closed while it runs - and the page is returned to where you left it. The picture is assembled on this device and goes to your disk or your clipboard. It is never uploaded, and a capture of a page you are signed in to is the most sensitive thing this product can produce, which is why there is no third destination and there is not going to be one.

Some settings ride your browser’s own sync, and none of them reach us

A short list of panel settings - the accent and theme, the panel scale, your shortcuts, the grid, the QR style and which tools you pinned - is written to your browser’s sync storage rather than to this machine alone, so a second browser signed into the same profile starts where you left off instead of at the defaults. That is the browser’s sync, not ours: it travels between your own installations through a service you are already signed into, and no copy of it is sent to LoupeKit, stored on our side or attached to an account. If you are not signed into your browser, it simply stays on this machine.

What never travels is the interesting half, and it is a list rather than a promise: your AI keys, the account token, the device id, the audit and colour histories, saved stylesheets, pinned guides, the sites your page theme comes back on, any page capture, and every switch that only means something next to a permission you granted on one machine. Those stay in local storage on the browser they were made in.

Three things are remembered about a site you have used LoupeKit on

Almost nothing in this product survives a reload - overlays go off, live edits are undone, and closing the panel puts the page back. Three features are deliberate exceptions, because each of them records something you did on purpose and would otherwise have to do again every visit: guides you pin from the rulers, a stylesheet you write for a site under Site styles, and a site you asked the page theme to come back on. All three are stored on this device, against the site’s origin - https://example.com, never the individual page you were reading - and all three are capped, so each record holds a few dozen sites at most and the least recently written one is dropped to make room. Nothing is written for a site you have not drawn a guide on, written rules for or asked to remember, so the list is of places you did something rather than places you went. None of them ever leaves the device and none is attached to an account.

Turning the page theme off for a site removes it from that record outright rather than storing it as off. A row saying you decided nothing would be a record of a visit, which is the thing the cap exists to prevent.

A saved stylesheet applies only while LoupeKit is running on the page, and it is switched off by removing it from the document rather than by emptying it. It cannot make a request of its own: an @import is removed before the sheet is saved, and any url() pointing off the site becomes none - a rule that quietly fetched a font from a third party on every visit would tell that third party where you are, and this product does not do that on your behalf. The editor says which of the two it removed and why, rather than silently differing from what you typed.

The form checker types into fields

It is the one tool that writes to the page rather than reading it, and it does so to ask the browser a question only a filled field can answer: whether a pattern, a minimum or a maximum rejects a value a person would reasonably type. Each field is written, checked and restored to its original value within the same synchronous pass, so nothing else on the page ever observes the value we wrote. Nothing is submitted. Password and payment-card fields are skipped entirely. Only the browser’s own validation message is returned to the panel - never anything that was in the field.

The Developer tab changes the page

That is what it is for, and every one of its switches is reversible: turning one off restores exactly what it changed - stylesheets re-enabled, inserted labels deleted, marker attributes removed, and any style attribute it stripped put back with the value it held. Reset page does all of them at once. The handful of one-shot actions that cannot be undone - removing form validation, releasing image sizes, re-requesting images past the cache - each say so on their own description, and a reload is what puts them back. Nothing the tab reads or writes is transmitted, and none of it survives the tab being closed.

Its cookie view reads document.cookie - the same cookies the page itself can read - and asks for no permission at all. HttpOnly cookies are therefore invisible to it, which is exactly what that flag is for. Nothing read there is stored, logged or sent anywhere.

The Cookie editor

A separate tool, and the only feature in LoupeKit that asks for a permission in order to read something. The view described above cannot show an HttpOnly cookie, and an HttpOnly cookie is nearly every session cookie there is - so the list somebody needs when a login will not stick is exactly the list that view is blind to. Seeing and editing those needs the browser’s cookies API, and that API needs access to the site being read.

It is asked for from the press that opens the editor, so your browser draws its own dialog naming the site, and it is asked for one site at a time - opening it on example.com asks for example.com and never a wildcard. The permission is optional: installing LoupeKit grants nothing here, and a button inside the tool hands the access back whenever you want it back.

Nothing read there is stored, logged or transmitted. Cookie values live in the panel for as long as it is open and are hidden behind a deliberate press before they are shown, because on a signed-in page most of them are the session itself.

The User-Agent switcher

When you switch it on, the browser asks for permission to rewrite request headers, and the extension installs one rule: it sets the User-Agent header and the two client hints that travel with it. It applies to every tab, not only the one you invoked LoupeKit on - there is no per-tab form of that rule - which is why there is a green dot on the toolbar icon and a strip inside the panel for as long as it is on. Nothing is read from any request; the rule only sets an outgoing header, and no record of it leaves your browser. Turning it off removes the rule and hands the permission back in the same action.

The WebRTC address control

A page can open a peer connection with no permission and no click from you, and the candidates it gathers carry addresses of your machine - the public one, and the private one it holds on your own network. This control changes what the browser is willing to offer. When you choose a policy, the browser asks for the privacy permission, which is broad in name: it covers read and write over every privacy setting the browser exposes, and Chrome offers no narrower form. LoupeKit writes exactly one,  network.webRTCIPHandlingPolicy, and reads that same setting to detect when another extension is holding it. It reads and writes no other privacy setting.

Like the switcher above, it applies to every tab - it is a browser setting rather than a page one - so the same green dot appears on the toolbar icon while it is on. Choosing Browser default clears the setting and removes the permission in the same action, in that order. Nothing about the choice, the setting or any address is transmitted anywhere: the whole feature is a call to the browser’s own settings API.

Settings kept for your account

Settings → Backups writes the panel’s configuration to a file on your machine, and that is the whole feature unless you switch on the second control beside it. That one keeps a copy against your account instead - one per browser, saved at most once an hour - so a machine that is gone can be restored onto a new one. It is off until you switch it on, per browser. A Pro browser is asked once, in that screen, and whichever way you answer is remembered - a card that came back after a no would not be asking. Switching it off and deleting the copy is one control in the same place.

What a copy carries is an allow list, not everything-except: how the panel is arranged, your shortcuts, the preview device list, the grid and typography fields, the thresholds the Checks view holds pages to, and the design-token source you pasted in. Never your AI provider key, your account token or this browser’s device id - a secret does not leave the machine it was typed on, and a copied device id would be two browsers claiming one free-audit allowance. Never the page snapshots, the recording or the usage counters either: the first belong to a page rather than to you, and the counters are a local reading that no code path is allowed to transmit.

Five things travel only if you tick the second box, and they are named because they are a record of where you have been: the colours you picked and the site each came from, your audit history and the domains in it, the ruler guides, the per-site stylesheets and the per-site page themes - the last three keyed by the site they apply to. A copy is stored as it is written, not encrypted: the three categories that would justify a key are the exact three it never carries, and an account that signed in with Google has no password to derive one from - a passphrase invented for a convenience feature is one people lose, and encryption that loses the data it protects is worse than saying plainly where the data is.

A copy is kept for 180 days after that browser last saved one, and an account keeps at most ten of them with the oldest dropped first. Both limits are applied by the statement that writes a copy rather than by a job that has to run. Deleting your account erases every copy with it.

A page baseline you keep

Four readings in the panel - the Requests diagnostic, the detected technology stack, the extracted palette and typefaces, and the load timings - happen entirely in your browser, free, transmitting nothing. On a paid plan a control beside each can keep a summary of that reading for your account so a later visit can say what changed. Nothing is saved until you press it, and each press saves exactly one summary.

What a saved summary carries is named, not everything-except. For requests: how many the page made, how many bytes travelled, how many failed, and the hostnames of the third parties involved with a count and a byte figure per hostname. For the stack: technology names and versions alone. For design tokens: bare hex values and font family names. For load timings: milestones in milliseconds. The page’s own address never travels. The summary is filed under a one-way hash your browser computes from the address with the query string removed - our server stores the hash, cannot turn it back into an address, and only the browser standing on that page can compute the same hash again. No path and no query string appears anywhere in a summary, because a path on somebody else’s site is a fact about them.

A summary is kept for 365 days, at most ten per page and fifty pages per account, with the oldest dropped first - all three limits applied by the statement that writes a save rather than by a job that has to run. The panel can delete one page’s baselines or all of them, the account export includes every kept summary, and deleting your account erases them all at once.

If you uninstall

The browser opens a feedback page on this site afterwards. It carries the version you had installed and nothing else - no device identifier, no plan, no install date, nothing that could connect a removal to any audit you ever ran. Everything the extension kept was kept in your browser, so it goes with it: the audit history, the picked colours, the pinned stack and any API key you had saved. There is nothing on our side to delete.

That page carries a survey, and it is the one thing on it that reaches us - only if you fill it in and press Send. What is stored is a row with four columns: which of the six reasons you picked, whatever you chose to type, an identifier for the row itself, and the time it arrived. The version in the page’s address is not sent with it, and there is no column for a device identifier, an address or anything derived from one - so the answer cannot be connected to you, to a purchase, or to anything you audited. The page prints that list back to you after it sends.

Requests made on your behalf

Four, and none of them goes to us. They are listed here because "everything stays local" would otherwise be a sentence with an exception hidden behind it.

Domain, DNS and certificate lookups

The Domain tab can look up who a domain is registered to, what its DNS records are, and which certificates have been issued for it. All three are buttons and none of them runs on its own, because each one tells somebody else which site you are looking at - which is the thing the rest of this page says LoupeKit does not do.

• Registration goes to rdap.org, which redirects to the registry that actually holds the record. It receives the domain name and nothing else.
• DNS goes to cloudflare-dns.com. It receives the domain name and the record type being asked about.
• Certificates go to api.certspotter.com, which reads the public Certificate Transparency logs. It receives the domain name. Nothing about the connection your browser made to the site is involved - no extension can read that, and this reader does not claim to.
• All three are sent with credentials: 'omit' and no referrer: no cookie, and nothing that says which page you were on.
• The full URL is never sent - only the registrable domain. A path, a query string and a fragment are all stripped before the request is built.
• No answer is stored. Closing the panel forgets all three.

The rest of that tab - the page's language, its favicons and the measurement ids it carries - is read from the document you already have open and is never transmitted at all.

Reading the page's own response headers

Stack detection makes a single HEAD request to the page you already have open, when you open the panel. It is how a CDN, a cache or a web server can be identified at all - those leave nothing in the page itself, only a header on its response.

• It goes to the same address as the page. No third party is contacted.
• It is sent with credentials: 'omit' - no cookie, no session, no Authorization header. The site cannot tie it to your logged-in account.
• Only the response headers are read. The body is never requested.
• Nothing from it is stored or transmitted anywhere.

Fetching the page again, for the rendering check

SEO → Rendering compares the HTML a server sends with the page your browser ended up with - the difference a search crawler sees. Answering that needs the served document, so this is the one reader that asks for a page rather than reading the one in front of it. It is a button and it never runs on its own.

• It requests the same address as the page you are on, from that page. No third party is contacted and no permission for other sites is involved.
• It is sent with credentials: 'omit' and no referrer, so the server sees a signed-out visitor. The panel says so on the result - a page that differs for a logged-in visitor differs here for that reason.
• The HTML that comes back is parsed without a browsing context: its scripts never run, and nothing it links to - images, stylesheets, trackers - is fetched.
• Neither document is stored or transmitted. The comparison happens in the tab and is forgotten when the panel closes.

Asking the site for robots.txt and its sitemaps

SEO → Crawler answers whether a search engine or an AI crawler may fetch the page you are on. That is decided in a file the page never loads, so this reader asks the site for it. Two buttons, two different amounts of asking, and neither happens until you press one - the panel names the exact files above them.

• The first press requests two things from the site you already have open: /robots.txt, and a HEAD on the page itself to read one header. No third party is contacted.
• Both are sent with credentials: 'omit' - no cookie, no session - because a crawler is signed out and that is the reading being taken.
• The second press follows the sitemaps the file declares. Only sitemaps on the same address as the page are fetched: one declared on another host is listed and marked, never requested. The extension holds no permission for other sites and this does not ask for one.
• The walk stops at a fixed number of files and says how many it left unread, so a partial count is never presented as a total.
• Nothing from any of it is stored or transmitted. No address, no rule and no sitemap reaches our server or anybody else's.

Reading the site’s llms.txt

SEO → AI answers asks whether a model can fetch, read and cite the page you are on. Three of those answers live outside the document, so this reader asks the site for them. It is a button, it names all three above itself, and nothing happens until you press it.

• It requests /llms.txt and /llms-full.txt from the site you already have open, and the page itself once more to see the HTML the server sends before any JavaScript runs. No third party is contacted.
• All three are sent with credentials: 'omit' - no cookie, no session - because that is the position every one of these agents is in.
• The verdict for GPTBot, ClaudeBot and the rest is the robots.txt reading described above, not a second request for the same file.
• Nothing from any of it is stored or transmitted. No address, no file and no part of the page reaches our server or anybody else’s.

Reading a sample of the site’s own pages

SEO → Sweep answers what the other SEO readings cannot: whether two pages share a title, whether a canonical points somewhere else, whether a description is missing from one page or from eleven. That needs more than the page you are on, so this reader fetches other pages of the same site. It is the heaviest request this extension makes, it waits for a press, it names what it will ask for above the button, and it can be stopped while it runs.

• It reads the sitemaps this site declares, takes up to forty of the URLs in them, and requests each one from the site you already have open. Only addresses on that same site are fetched - a URL on another host is skipped, not requested. No third party is contacted and no permission for other sites is involved.
• Every request is sent with credentials: 'omit' - no cookie, no session - because the reading being taken is the signed-out page a crawler receives.
• Each page that comes back is parsed without a browsing context: its scripts never run, and nothing it links to - images, stylesheets, trackers - is fetched.
• A site with more pages than the cap is sampled, and the panel prints both numbers, so a sweep never implies it read a site it only sampled.
• Nothing is stored on our servers and nothing is transmitted. The titles, descriptions and addresses are compared in your browser and are forgotten when the panel closes.

Checking whether a build ships its source maps

Tools → Source maps answers a question nothing in a browser shows: whether the scripts on this page serve a map, and what that map exposes. It is a button and it never runs on its own.

• It asks the site you are on for the last few kilobytes of each of its own scripts, using a Range request, and then for any map those point at. Same address as the page, signed out, no third party.
• Scripts hosted somewhere else are counted and never requested. The extension holds no permission for other sites.
• When a map embeds the original source, the extension records only that it does. The source text itself is discarded where it is read and never reaches the panel, a report or anywhere else.

Drawing the site’s own icon

The bar at the top of several tabs shows the favicon of the page you have open, beside its address. Drawing it is one image request, and it is worth saying exactly what that is and is not.

• The address of the icon comes from the browser, for the tab you invoked LoupeKit on. Nothing is looked up, no service is asked, and no domain is sent anywhere.
• The request goes to the site you are already looking at, and the panel sends  no referrer with it - so the site is not told which extension asked, or that one did.
• If the icon does not load, the bar shows a dot instead. Nothing is retried and nothing is stored.

Looking up field data (Pro)

Tools → Load timing can look up what real visitors to the page got over the last 28 days. That data lives in Google’s Chrome UX Report and is keyed on the address, so  this is the one feature where the address of a page you are looking at leaves your machine. It is a button, it never runs on its own, and the panel says so above it.

• The address goes to our API, which forwards it to the Chrome UX Report. Nothing else about the page travels - no content, no headers, no measurements.
• The query string and the fragment are removed before it goes anywhere, along with any username or password in the address. A session token, a promo code or a document id in a query string never leaves.
• Our server writes none of it down. There is no row in our database, no analytics event and no log line containing the address or the site - the lookup is a pass-through and the answer is discarded once it reaches your panel.
• Google receives the address as part of the lookup, as they would for anyone querying that API. What they do with it is governed by their own terms; we send them nothing that identifies you, your device or your account.
• Every other timing number in the extension - the whole load breakdown above this panel - is measured in your own browser and stays there. Only this one leaves.

Showing you an image, or copying one

In the asset list, hovering a row previews that image, and pressing PNG copies it to your clipboard. For an inline SVG nothing is fetched at all - the markup is already in the panel. For a linked image both point at the same URL the page itself loaded, so it is normally served from your browser's cache and no new request leaves at all. When one does, it is sent with no referrer and no credentials, only at the moment you hover or press the button, and never to us.

Copying a linked image needs the server to permit a cross-origin read. Many do not, and LoupeKit holds no permission for other sites that could work around it - in that case the button copies the image's URL instead and says so, rather than reporting a success it did not have.

The Server tab (Pro)

Seven readings ask our server to fetch the page you are on, from its own address, signed out: what each crawler is served, what the very first response already sets before any consent banner, what the site does when asked for in another language, how each asset is cached and compressed, which protocols the host advertises and which certificate authority signs for it, whether the hosts it links to still answer, and what link preview each platform would draw. None of these can be answered from your browser - a browser cannot become Googlebot, cannot un-see a banner that has already run, and cannot check a cross-origin link without announcing you to it.

They are grouped into one tab with one paragraph above them, because a promise that holds on one screen and not the next is not a promise. Nothing here runs on its own; every button says what it will request before you press it.

• The query string is removed before anything is fetched, along with any username or password in the address, and the report tells you it happened. Beyond the usual reason, this feature replays the address from our machine - a sign-in link or a password reset would be spent by it.
• The page itself never comes back to us or to you. Each reading returns counts, statuses and header values read out of the response; the document is read and discarded. Cookie names are kept and cookie values are not - the value is the identifier the reading is about.
• Our server writes none of it down. No row in our database, no analytics event, no log line containing the address. When something fails we log the shape of the failure and never the exception, which would name the resolved address.
• We refuse to fetch addresses that are not on the public internet - private and reserved ranges, localhost, names that only resolve on your own network - and we re-check that on every redirect the site sends us to, not only on the address you started with.
• The site you are reading about sees a request from our address, as it would from any crawler or link checker. It does not see anything about you: no cookies, no referrer, and nothing that identifies your device or your account.
• One of the seven asks three public directories as well as the site. Transport reads the host’s DNS HTTPS and CAA records from cloudflare-dns.com, and the public Certificate Transparency logs from api.certspotter.com. Each receives the host name and nothing else, and each is asked by our server rather than by your browser - so your address is not the one making the lookup. They are the same two services the Domain tab uses.
• Each report says where it was taken from. Our server runs in the Cloudflare location nearest you, so a behaviour that varies by country is being read from one region - and that is the only place your rough location appears. It is shown to you and stored nowhere.

Reports you publish at a link

The one feature that keeps anything about a page on our server, and it only runs when you press Publish. What is being sold is the hosting: an audit dies when the panel closes, and an extension cannot produce a link.

• Stored: the score, its verdict, what each area contributed, and each finding’s label, severity, sentence and suggested fix - plus a title and the site’s hostname.
• Also stored, per finding: up to six element names it was seen on - a tag with its id or its first few classes, as in div.hero__wrap.px-4. A name is what you would type into a find box; it is not a selector, holds no attribute value and no text, and cannot be replayed against your site. It is there because a finding that says “412 elements” and cannot say which ones is a document nobody can act on. Nothing inside a form that collects a password, a card or an email is sampled at all.
• Not stored: the page. No markup, no selectors, no screenshots, no attribute values, and nothing of the address beyond the hostname - a path like /invoices/4182  is a fact about your site that would otherwise travel with a document you forward.
• The link is unguessable and is the only credential, so the page is served noindex, with no caching by shared caches and no referrer. It contains no JavaScript and fetches nothing, so opening it tells nobody - including us - that you did.
• Every report carries an expiry you choose - up to ninety days, or up to a year for an accessibility evidence pack, whose point is being a dated record. After it, the link answers “no longer available” whether or not anything has deleted the row. You can withdraw one earlier from the panel.

Opening on page load

By default LoupeKit can only reach the tab you clicked the toolbar button on, and that access ends at the next navigation. There is one setting that changes this: Open on page load, which is off unless you turn it on. Switching it on asks your browser for access to every site - appearing before you click cannot be done any other way - and switching it off hands that access straight back.

What it does not change is what leaves your browser. An audit still runs only when you press the button, still sends only the fields listed above, and still sends nothing at all from a page you did not audit. The setting decides when the panel appears, not what is collected.

Your own AI keys

If you add an AI provider key, it is stored in your browser's extension storage and used directly from your browser. It never reaches our servers - not in a request, not in a log line, not in an error report. We never see it, so we cannot lose it.

Asking for a rewrite sends text to the provider you chose - that is the feature, and it is worth being exact about. What travels is the copy you asked to rewrite, cut at 600 characters so a stray selection cannot send an article on your own bill, and nothing else: no hostname, no device id, nothing from the rest of the page. It goes from your browser straight to that one provider, never through us, and only when you press the button. From the moment it arrives it is handled under the provider’s own terms rather than this page: they are a separate controller, and what they keep or train on is set by the agreement you hold with them - the same agreement your key came from.

The providers a key can be saved for are OpenAI, Anthropic, Google Gemini, xAI Grok, DeepSeek, Mistral, Moonshot Kimi, Perplexity, Groq, OpenRouter, Cohere, Together AI and Alibaba Qwen. Your text goes only to the one you configured, and with no key saved nothing can be sent at all.

Extension storage is not encrypted. Anything running in this extension can read a saved key, and so can anything with access to your browser profile on disk. That is a real limitation and the settings screen states it before you paste anything. Remove a key there and the browser permission for that provider is handed back with it.

Payments

Checkout is handled by Stripe on Stripe's own pages. Card details never touch our infrastructure. We receive a customer id, a plan, and the email you gave Stripe.

If you tell the panel you are buying for a business, two more things are collected before the payment page: the registered company name and the EU VAT number you type. Both are needed to issue the invoice - a sale to a VAT-registered business in another member state is a reverse charge, and that invoice is only correct if it names the buyer. They are stored against your account, sent to Stripe with the payment so the invoice can be raised from it, and shown back to you on /app. A personal purchase collects neither and is never asked to.

The VAT number is checked against the European Commission's VIES register at the moment of purchase. That lookup sends the number and its country code to the Commission and nothing else - no name, no address, no account of yours. What comes back is a yes or a no, and it is recorded with the date it was answered, because a number valid on the day of a sale can be deregistered afterwards and an invoice is a statement about the day. When the register does not answer, the purchase proceeds and the record says the check was not made.

Deleting your account deletes the company name, the VAT number and the check with it. The copy Stripe holds - against the payment and against the customer record the invoice is raised from - is a different record with a different reason: Slovak accounting law requires invoices to be kept, and that obligation outlives the account.

This website

No analytics, no cookies, no tag manager. Fonts are served from this domain. There would be something absurd about a privacy page that loaded a tracker to tell you it was measuring how many people read it.

Exactly one third-party origin is loaded anywhere on this site, on exactly two pages. Sign in and Create account embed a Cloudflare Turnstile challenge, which is a script and an iframe from challenges.cloudflare.com. It is there because those two pages send an email to whatever address is typed into them, and a challenge is the only limit that bounds that per visitor rather than per network address or per recipient - so without it this site is a way to mail strangers. It sets no cookie of ours, it runs on no other page, and the content-security policy this site ships names it on those two routes and blocks it on every other one.

Cookies, and what is stored in the browser instead

This site sets no cookie, and neither does anything on it. It does write five keys into browser storage, which is the same act under the same law and is disclosed here for that reason - a page that says no cookies and stops there has told you something true and left you with the wrong impression. One key is the theme you chose. One is the count that stops a small panel mentioning another of our products more than three times, and stops it for good once you close it. The other three exist only after you sign in and are gone when you close the tab.

There is no consent banner because there is nothing here to consent to. The rule that governs this - Article 5(3) of the ePrivacy Directive - asks for consent before storing anything that is not strictly necessary for what you asked the site to do, and exempts what is. A theme is the setting you pressed a control to choose; a session key is how a signed-in page stays signed in. Nothing above is analytics, advertising or profiling, so a dialogue asking your permission would be asking a question with one possible answer, and those are the dialogues that teach people to dismiss the ones that matter.

The table is generated from the code that does the writing, and the build fails if the two disagree in either direction - a key added with no row here, or a row describing a key nothing writes. It is not a statement that was true when somebody typed it.

Accounts and team sharing

Only if you sign in. Nothing below happens otherwise, and every other feature keeps working without it.

• What is stored is your email address, and whatever you sign in with. That means a hash of your password if you set one, and Google’s identifier for the account if you signed in that way - never the password itself. No name, no profile, nothing beyond the address and the credential. Signing in by code sends an eight-character code to that address; the code is stored only as a SHA-256 hash, expires in fifteen minutes, and works once.
• The address is passed to Brevo, which sends that message. It is the only processor the address is handed to in order to send mail - the row it lives in sits in the database Cloudflare holds, and Stripe sees whatever address you give at checkout, both in the table further down - and there are exactly three messages it is ever used for: a sign-in code, the code that confirms an account is to be erased, and - if you buy Pro - the licence key. No newsletter, no product mail, nothing to unsubscribe from.
• Members of a team can see each other's addresses. That is what a team is; there is no way to share with someone anonymously.
• Nothing about your browsing is stored by signing in. Audits stay counted per domain with no user attached to them, and signing in does not change that.

What a shared item contains

A shared palette or environment snapshot is not the extraction the panel shows you. It is rebuilt from a small set of named fields before it is sent, and rebuilt again from those same fields on our side - so a client that sent more would not succeed in storing it.

• A palette carries colour values, the role LoupeKit guessed, and a rank. The element counts do not travel: 675 elements is a measurement of how large your application is.
• An environment carries the host, the technologies with their versions, the palette and the font families. The host is what an environment is. The path, query and fragment are dropped, not shortened.
• Detection evidence never travels - the script URL, header value or CSS variable that matched. Those name internal routes and internal hosts.
• Asset URLs, CSS selectors and page content are not part of a shared item in any form.

An account keeps a log of what happened to it

Signing in, activating or removing a browser, a plan starting or ending, a key being replaced, an export or a deletion being requested - each writes one dated entry against the account. It exists because “what is true now” cannot answer the questions an account actually raises: why a plan is gone, which browser took the third slot, and above all whether somebody else signed in - a sign-in nobody can see is a compromise nobody can date.

An entry is the kind of event, the time, and a few named facts that make the row readable - the plan that was applied, how many device slots were freed, the browser’s name, the sign-in method, a reason, when a scheduled cancellation takes effect, a count. That list of fields is fixed in the code, and anything beyond it is dropped rather than written. What may never go in is written down beside the table itself: nothing derived from your network address, no user agent, no credential or key, not the email address, and nothing read out of anybody’s browsing.

The log is yours to read: it is drawn under ACTIVITY on your reports and included in the data export described below. Entries are kept for 365 days, and the deletion of older ones runs in the same statement that reads the list - a retention period only a scheduled job was supposed to enforce would be a sentence on a privacy page rather than a fact about a database. Deleting the account deletes the whole log with it.

Removing your data

Uninstalling the extension deletes the device id, meaning nothing links you to the stored row any more. To have the row itself deleted, email  info@loupekit.com with your device id - Settings → About holds it, covered until you press to show it.

An account is different, because it holds an email address. Delete it yourself under DELETION on your reports: it asks you to prove it is you with whatever you sign in with - your password, an emailed code, or Google - and then erases the address, every report published from it, and any team space you own. There is no waiting period and nothing is kept. A subscription has to be cancelled first, because deleting the account would leave the charge running with nobody able to stop it.

Taking a copy of it

Under YOUR DATA on your reports, one press downloads everything held against your address as JSON: the account, the licence and the browsers activated on it, the browser rows that signed in, the activity log described above, and every report you have published with its reading in full. Nothing is sent anywhere to produce it and no copy is kept.

The file also names what is not in it. Your password is not - it is the credential guarding everything else, and it tells you nothing you do not already know. Neither is Google's identifier for the account, which is Google's rather than ours and means nothing outside this system. And two things described further up this page cannot be in it at all, because neither carries an account id by design: the audit log, which is a count per domain and nothing else, and uninstall feedback, which has no identity column. No row in either can be traced back to you, by us or by anybody.

The legal summary

Everything above says what happens. This says the same thing in the terms the GDPR asks for, so the two can be checked against each other. Nothing here is a new practice - a row with no section above it would be a claim about a system that does not exist.

Your rights, and where to complain

You can ask for a copy of what is held, ask for it corrected, ask for it deleted, ask us to stop processing it, object to processing based on legitimate interests, and withdraw any consent you gave - withdrawing it does not undo what was done while it stood. The first two of those are already buttons on your reports; the rest are an email to the address above, answered within one month.

If the answer is unsatisfactory you may complain to the Slovak supervisory authority, Úrad na ochranu osobných údajov Slovenskej republiky (Office for Personal Data Protection of the Slovak Republic), Hraničná 12, 820 07 Bratislava 27, Slovakia. You may also complain to the authority in the EU country where you live.

Nothing here makes an automated decision about you and nothing is profiled. Providing an address is not required to use the product - it is required only for an account, and everything except an account works without one.