Why HTMLRadar exists
HTML quietly won.
For two decades, the documents that mattered ended in .pdf. Investor decks. Briefs. Board updates. Research reports. One-pagers. The receipt for the work, in the format the work was filed under.
Founders started writing investor decks as one-page HTML files — styled documents typed into Claude or ChatGPT and dropped into a WhatsApp thread. Designers replaced static mocks with interactive prototypes. Researchers published reports that rendered on phones, scaled to a screenshot, and adapted to whichever browser opened them. Engineers wrote planning documents with embedded diffs and call-graphs no markdown table could carry.
PDFs were built to be printed. HTML was built to render — and a page that renders can be interactive, reflows to whatever screen opens it, and can be changed after it has been sent. That difference was ignored for years, because PDFs were "the document format." More of these documents are written with AI tools now, which is a fact about the typing rather than the reason the format is better.
DocSend, PandaDoc, Brevo. The tools that grew up around document analytics were built when PDFs were the answer, and stayed loyal to it. Every one of them is built around uploading a file and tracking that file, which is a different job from serving a live HTML page and reporting which section your investor read.
The piece that always sat missing was the one that tells you what happened after the link went out. Who opened it. From which city. On a phone or a laptop. Whether they stayed on the page you cared about, or skipped past it. Whether they came back the next morning.
HTMLRadar tracks who reads HTML at the section level. It emails you on the first real read — five seconds on the page, not a bounce.