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 exported from Pitch, or as styled documents typed into Claude 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. That difference, ignored for years because PDFs were "the document format," compounded into something obvious in retrospect. Anything you would send to someone you care about reads better as HTML on every modern surface.
DocSend, PandaDoc, Brevo. The tools that grew up around document analytics were built when PDFs were the answer, and stayed loyal to it. None of them tells you who opened your HTML deck, which section your investor read, or whether the brief you sent to a client landed at all.
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 sends an email the moment a real read happens, and tells you which sections kept them past three seconds.