What we collect
The sender decides who may open a page and which gates it has; HTMLRadar records readers’ data on the sender’s behalf.
When a recipient opens a tracked link, we record:
- The e-mail address they enter at the gate, if the share requires one.
- If the sender turns on e-mail verification, we send that address a six-digit code. We store only a keyed hash of the code, never the code itself. The code works for ten minutes, and we delete the record shortly after it expires. We keep it only so that nobody can use the gate to send somebody a hundred codes. Once an address has been verified we record that, and the sender sees a verified mark beside it in their report. The code is sent through our mail provider, Resend.
- A random fingerprint: a value we generate so that the same person opening the same document twice counts as one reader rather than two. On a document we serve, it lives in a cookie named
__Host-hr_rid. The browser sends that cookie only to the exact host that served the document, and marks it so that scripts on the page cannot read it. It expires after 90 days. Each document gets a different identifier derived from it, so the value one document is given does not match the value another document is given. The page the sender wrote is given that document’s value and can read it. - Reading: when the read started, total active time, how far they scrolled, and the time on each section.
- Rough location and device: country and city worked out from the network address (we never store the address itself; a scrambled form is kept only to stop abuse), the device, operating system and browser, and the page they came from.
We never record what a reader types or where they point; we only count whether the page is being read. We use no third-party trackers, and we collect nothing from outside the document and nothing that identifies the recipient beyond the e-mail address they gave.
Recipient documents are served from a separate domain, htmlradar.page, which shares no cookies or browser storage with htmlradar.com, and old htmlradar.com links redirect there automatically.
What we collect when you use the app yourself
Separately from the share-tracking above, the hosted app records a small amount of first-party usage data so we can fix bugs and understand which features get used:
- Product events — when you sign in, upload a document, create a link, switch a link off, reach the free-plan limit, view the upgrade page, press a button, or submit feedback. Stored in a table called
app_events. The monitor worker replays these first-party events to PostHog server-side for product analytics. Your account e-mail is added to your PostHog user profile after sign-in. Some of these events describe a reader opening one of your links, not only what you did in the app: the event carries the link’s address, the document, the reader’s country and device, which gates the link had, and whether that reader had been seen before. It does not carry the reader’s e-mail address or their fingerprint. Until 22 September 2026 it also carried the label you type on a link, which is often a person’s name — that has stopped, the label has been removed from the events already stored here, and what remains in its place is a yes-or-no that says whether the link had a label at all. Copies that had already been replayed to PostHog before that date are not reached by either change; those have to be deleted in PostHog itself, which we will do on request to privacy@htmlradar.com. The browser does not load a PostHog script. - Page views — when your browser loads a page on htmlradar.com. We store the path, referrer, and a random fingerprint (anonymous, generated client-side, never linked to your e-mail unless you’re signed in).
- Crash and error reports — when JavaScript on a page throws an error, we capture the message and stack to a
error_logtable so we can fix it. The same errors, and our servers’ own errors, also go to Sentry, an error-tracking service, with your account, cookies, request bodies, e-mail addresses and the query part of every address removed before they leave. We remove IP addresses before reports reach Sentry. A shared document reports its script errors to the same table, never to Sentry: the error type, a message with quoted text and long numbers blanked, the script’s address without its query, the line and column, and which link it was. No page text, no stack, no browser details, nothing that identifies the reader, and at most five per page load. No Sentry code is ever loaded on a shared document. - Feedback — anything you submit through /feedback is stored in a
feedbacktable and e-mailed directly to the founder. E-mail field is optional.
No session replay.
Why we use it
Reader data is recorded so the sender can see how a page was read. We also use it to count one person once and to stop abuse. We use app usage and error data to run the service, fix faults and see which features get used. We do not sell personal data.
Where data lives
- Document HTML you upload: Cloudflare R2, encrypted at rest.
- Primary application data: Supabase Postgres, in Mumbai, India, encrypted at rest.
- Product analytics events: PostHog, sent server-side from the monitor worker.
- Website analytics: Google.
- Error reports from htmlradar.com and our servers: Sentry, United States.
- Payments: Polar, our merchant of record, with Stripe as its payment processor.
- Sign-in e-mails and notifications: Resend.
- Google sign-in, if you use it: Google.
These infrastructure providers process and store the data for us, in data centres that may be outside your country. It is encrypted in transit and at rest.
Who can see your data
Analytics about a share are visible to the document owner and, if the owner has joined a company team on HTMLRadar, to that team’s administrators. Administrators see the same reports and can download the same records, including for documents the owner shared before joining, except any that belong to a team the owner was on before. The owner is told this before they join.
The team keeps access to documents an owner creates while on it, and the owner keeps their rights in the content: after the owner leaves the team, its administrators can still see those documents and switch their links off. Records the administrators have already downloaded cannot be recalled.
Checks in our server code enforce who can see what, alongside Postgres Row Level Security, which stops a signed-in user querying the database directly from seeing another user’s data.
Access to the production systems is restricted to authorised people at HTMLRadar, who use it only to run the service, answer support requests and investigate abuse.
AI and your documents
We do not use your documents or their reading records to train anything. If you connect an AI assistant to HTMLRadar, it acts as you: you sign in to your own account, choose whether it can only read or also publish, and it reaches only your own documents and links. Anything it reads or publishes for you passes through the assistant’s maker, under that maker’s own terms.
Data retention
Reading records — sessions and section events — are kept until you delete them or choose a retention period. Forever is the default, and it is what every account has unless it says otherwise.
Under Settings, Reading records, you can set how long your account keeps them: forever, 1 year, 90 days or 30 days. Once a day we work through everything older than that, across every link on your account, in batches until none is left. A backlog too large to clear in one night carries over to the next. The deletion is from the live database and it is not reversible there: the deleted reads disappear from the read report and from any CSV export you take afterwards, and we have no way to put them back.
On a team, reading records for team documents follow the retention period set by the person who pays for the team.
A sweep takes a read apart into the records it is made of, and each of those has its own age. The session and its section-by-section timings go together, along with the first-open notification we logged for that session. An attachment download is kept on its own clock, by the day it was downloaded. So is the record that a reader’s address passed e-mail verification on a link, because that is a fact about the address and the link rather than about any one visit. The reader row is deleted once it is both older than your period and has no read left pointing at it. That means a read can be gone while a verification or a reader row from around the same time is still there for a few days longer, until its own date passes your period too. Your documents, links and uploaded files are not touched at all.
Two things a retention period does not reach. Our nightly database backups, which are encrypted and kept for about two weeks: a deleted record can still exist in a backup until that backup ages out, and backups are not queryable as a live copy. And the product analytics we replay to PostHog, described above — they live in a separate system that this setting cannot delete from, and removing something there is a request we carry out by hand in PostHog.
A retention period is the automatic route, on a daily timetable. The 30-day promise below is the other route: a one-off request for specific data, which is handled by hand and therefore quoted in days rather than hours.
Permanently deleting a link removes it and its reading records, whatever retention period you have set. A link whose address you chose is switched off instead, and its records stay until your retention period reaches them. The in-app Delete document action archives the document: it removes access to the document and its links, but retains the database rows and uploaded HTML for recovery.
Your account and documents are kept for as long as your account is open. When you ask us to close it, we delete them as set out under Right to delete, within 30 days of a verified request.
Right to delete
Recipients and account holders can request permanent deletion by e-mailing privacy@htmlradar.com. Include the e-mail address tied to the data and, for account holders, the affected document. We complete verified requests within 30 days, including matching data in our database, file storage and analytics providers where applicable. The one exception is documents created while on a team: we delete those once that team’s administrators agree, and we tell you which documents they are. Closing a team deletes nothing: each document stays with the person who made it, and a link an administrator switched off stays off until the document’s owner switches it on again.
Opt out
A recipient can opt out of tracking by calling window.HTMLRadar.optOut() in the browser console of any tracked page, and confirming on the page that opens. On a document we serve, confirming records the choice in a cookie on the host that served the document, deletes the fingerprint cookie, and applies to every HTMLRadar link opened on that host afterwards. While it is in place we set no fingerprint and put no tracker on the page. On a directly embedded tracker the choice is stored in that site’s localStorage; the script still downloads with the page, then stops before recording anything.
The same page also carries a link to report it, which works the same way whether it opens on htmlradar.page or on a customer’s own connected domain.
If we e-mailed you first
Sometimes we write to a business we have not spoken to before, because its published work suggests it sends proposals, decks or reports as web pages. When we do, this is what happens with the address. We take it from the firm’s own website or a public professional profile, and the e-mail says which page. We store the address, the name if one was published, the firm, the page it came from and the dates we wrote, in a private spreadsheet that only the founder can read, for at most twelve months. We use it for at most two e-mails and for nothing else. We do not sell it, share it or add it to any list. Reply with the word stop, or any words that mean the same, and we delete the row the same day and never write again. The lawful basis in the UK is legitimate interest in telling a relevant business about a product for that business; the assessment behind that is available on request. Write to hello@htmlradar.com for a copy, to ask what we hold about you, or to have it deleted.
Grievance Officer
Our Grievance Officer is Abhinandan R, who takes complaints about how we handle personal data at privacy@htmlradar.com and answers within one month.
Contact
HTMLRadar is operated by Six Singularities Private Limited, which is responsible for the data described on this page.