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 share, we record:
- The email address they enter at the gate, if the share requires one.
- If the sender turns on email 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. - Session metrics: start time, total active time, max scroll depth, sections read with dwell.
- Coarse network metadata: IP-derived country and city (we never store the IP itself; a scrambled form is kept only to stop abuse), device / OS / browser from the user-agent, referrer URL.
We never record what a reader types or where they point; we only count whether the page is being read. We don’t collect third-party trackers, anything from outside the document, or anything that identifies the recipient beyond the email they provided.
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 or revoke a share, hit the free-tier cap, view the upgrade page, click a CTA, 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 email 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 email 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 email unless you’re signed in).
- Crash + error reports — when JavaScript on a page throws an error, we capture the message + 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, email 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 emailed directly to the founder. Email field is optional.
No third-party tracking scripts. No third-party cookies for analytics or advertising. No session replay.
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.
- 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.
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: 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 document and share access, but retains the database rows and uploaded HTML for recovery.
Right to delete
Recipients and account holders can request permanent deletion by emailing privacy@htmlradar.com. Include the email address tied to the data and, for account holders, the affected document. We complete verified requests within 30 days, including matching data in Supabase, R2, and PostHog 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.