What seven deck-sharing tools actually load in your recipient's browser

Why we looked

We sell read tracking. Our tracker sends section titles and per-section seconds to our own servers, and the payload it sends is listed later in this piece. The person who opens a shared link did not sign up for anything, so what runs in their browser is worth writing down. I looked for a published answer to that and did not find one, so on 30 August 2026 I opened one public link from each of six other products and recorded the network requests, cookies, storage, scripts and frames listed below.

We ran the same test on our own share link, and this piece publishes what came back, including the two findings we are acting on.

How each link was captured

Common to every capture: one public, ungated share link per product. Playwright Chromium, viewport 1512x982. Load, wait ten seconds, capture, scroll to the bottom, wait five more seconds, capture - a fifteen-second window. Nothing was typed, clicked or submitted: no e-mail, no consent button, no page-advance control. All timestamps are UTC.

What each capture recorded: every network request and its host, document.cookie, localStorage keys, every script src in the DOM, and the page's visible text. sessionStorage was checked on five of the seven links - DocSend, Papermark, Peony, HummingDeck and HTMLRadar - and the Stacktree and Tiiny.host files do not record it. Iframes were counted on those same five. For Stacktree and Tiiny.host the capture transcribes the top and the bottom of the page rather than the whole text.

One thing to carry through the whole piece: document.cookie cannot see HttpOnly cookies, and it reads only the top-level origin. Every cookie count here is therefore a lower bound, and is written as "visible to document.cookie" rather than "set".

How each one was captured, from its own evidence file:

• DocSend - https://docsend.com/view/58em2uebezhisqvy (published on nextgencodingcompany.com), 2026-08-30T06:59:08Z. A browser launched fresh for this subject, a brand-new context with no profile and no cookies carried in, a normal desktop Chrome user-agent string. Fifteen-second window.
• Papermark - https://www.papermark.com/view/cmkz9p9de0014js04sf4ex5u8 (publicly posted by its sender), 2026-08-30T06:56:48Z. A browser launched fresh for this subject, a brand-new context with no profile and no cookies carried in, a normal desktop Chrome user-agent string. Fifteen-second window.
• Peony - https://app.peony.ink/view/daa6031a-a4d2-42bd-a85b-e3f1dc345b82, 2026-08-30T06:41:27Z. A new tab in the running browser. The evidence file records no separate context and no user-agent override. Fifteen-second window.
• Stacktree - https://example-brand-audit.stacktr.ee/ (vendor's own live example), 2026-08-30T06:34:21Z. The evidence file records the browser and viewport only: no separate context, no user-agent override. Fifteen-second window.
• Tiiny.host - https://ai-agents-guide.tiiny.site/ (a real user-published site), 2026-08-30T06:35:31Z. The evidence file records the browser and viewport only: no separate context, no user-agent override. Fifteen-second window.
• HummingDeck - https://hummingdeck.com/r/mt3uu5qwv7kpxb3g (vendor's own demo room), 2026-08-30T06:36:41Z. The evidence file records the browser and viewport only: no separate context, no user-agent override. Fifteen-second window.
• HTMLRadar - https://htmlradar.com/r/lumenforge-demo (our public demo), 2026-08-30T07:11:08Z. A browser launched fresh for this subject, a brand-new context with no profile and no cookies carried in, a normal desktop Chrome user-agent string, driven by a standalone script rather than the shared browser. Two runs: the fifteen-second window used for comparison with the six above, and a separate 55-second run from 07:12:27Z to 07:13:23Z made only to observe the heartbeat, which falls outside the comparison window. Every heartbeat line in this piece is labelled as coming from that longer run.

One disclosure about our own link. htmlradar.com/r/lumenforge-demo had been revoked on 23 July 2026, and we un-revoked it ourselves immediately before measuring, with one database update that set revoked_at to null and changed nothing else. It is the only link in this set that we control. The other six were opened the way any recipient opens one.

The limits, stated plainly because they are real:

1. One link each. On DocSend and on Papermark we opened gated links before finding an ungated one, and both attempts are recorded in the evidence files, so gated and ungated links of the same product plainly differ. A demo link and a customer's configured link can differ too. Nothing here describes any other link.
2. We record what loaded, not why. No claim about who chose a given script, what any vendor intends, or what a product does on any other page.
3. Vendors change things. This is one fifteen-second window per product, on one day.
4. Cookie counts are a lower bound. document.cookie cannot see HttpOnly cookies, and it reads only the top-level origin, so cookies set inside a cross-origin iframe are not counted.

How vendors were notified. Each of the six vendors tested here - DocSend, Papermark, Peony, Stacktree, Tiiny.host and HummingDeck - was sent one note on 30 August 2026, naming the specific finding recorded on their product and 4 September 2026 as the date this piece would publish. Where a reply came back, it is reproduced below exactly as sent, under that vendor's own section. A vendor that had not replied by publication is marked as such in the same place.

The table

Checked on 30 August 2026. Every cell in this table comes from a recorded network log, a document.cookie read or a DOM capture inside the fifteen-second window described above. Two facts elsewhere in this piece come from outside that window, and both are labelled where they appear: HTMLRadar's heartbeat calls, which come from the separate 55-second run, and the Cloudflare zone setting on htmlradar.com, which we read from our own Cloudflare account. "None observed" means exactly that - not observed on this link, in this window, by this method.

Re-checked on 31 August 2026. Vendors change things, so all seven links were opened again on 31 August 2026 with the same script, the same viewport and the same fifteen-second window. The findings summarized in the table held. DocSend made the same advertising requests and wrote __Secure-dbx_consent with all five categories true and "userInteracted":false while the banner sat untouched. Peony attempted a Mixpanel Session Replay upload through app.peony.ink/mp/record, answered 402. Papermark showed one non-first-party host and one visible cookie. Stacktree returned an empty document.cookie and one cloudflareinsights request blocked by its own policy. Tiiny.host returned an empty cookie and empty storage, with Plausible served from analytics.tiiny.site. HummingDeck loaded the same Calendly frame, the same 24 non-first-party hosts and the same img.logo.dev request. Four differences, all small: Peony attempted one replay upload instead of two, Tiiny.host's Plausible script loaded but sent no /api/event POST inside the window, per-page request totals moved by a handful either way as image loads vary run to run, and HTMLRadar's own row changed for reasons given in its own section below. The counts in the table are the ones recorded on 30 August, which is the date the table carries.

Checked again ahead of publication. A further check on 2 September 2026 found Peony's Mixpanel Session Replay upload answered 200, not the 402 recorded on 30 and 31 August: the upload that had been stalling behind a payment gate went through this time. Everything else held. This piece re-runs the same check once more immediately before publishing, so this line is updated again if that changes.

Product by product

DocSend

174 requests, the busiest page in the set. Alongside DocSend's own view tracking (POST /presentation_analytics/record_page_view, twice for a two-page deck, no e-mail entered and none requested), the browser made requests to three Google properties, each carrying the recipient's URL:

149. [POST] https://www.google.com/ccm/collect?…&en=page_view&dl=https%3A%2F%2Fdocsend.com%2Fview%2F58em2uebezhisqvy…
152. [XHR]  https://www.google-analytics.com/j/collect?…&tid=UA-40340055-1&cid=1353163225.1788073151…
153. [GET]  https://googleads.g.doubleclick.net/pagead/viewthroughconversion/982651595/?…
158. [GET]  https://www.google.com/pagead/1p-user-list/982651595/?…&is_vtc=1&cid=CAQS0wEAQM4h…
159. [GET]  https://www.google.co.in/pagead/1p-user-list/982651595/?…&rmt_tld=1…
160. [POST] https://analytics.google.com/g/collect?v=2&tid=G-JPP8SP2PRX&…
161. [POST] https://stats.g.doubleclick.net/g/collect?v=2&tid=G-JPP8SP2PRX&…

Advertising-related hosts appeared on two of the seven links. On DocSend they were googleads.g.doubleclick.net, stats.g.doubleclick.net, and pagead/1p-user-list requests for Google Ads conversion id 982651595 on both www.google.com and www.google.co.in. On HummingDeck it was connect.facebook.net, serving fbevents.js, which appeared after the calendly.com frame loaded. On the other five links, none appeared.

The cookie banner does offer "Decline" and "Customize cookies". Nothing was clicked. The consent cookie written during that same load, verbatim:

__Secure-dbx_consent = {"consentType":1,
  "consentDate":"2026-08-30T06:59:11.034Z",
  "categories":{"strictly necessary":true,
                "general marketing and advertising":true,
                "analytics":true,
                "performance and functionality":true,
                "social media advertising":true},
  "userInteracted":false,"numDots":1}

Every category recorded as true, userInteracted recorded as false, and the advertising requests above already sent, while the banner was still on screen and untouched.

DocSend's owner, Dropbox, acknowledged the note through its privacy support desk on 30 August. No substantive response had arrived by 4 September 2026, the day this piece went up on the HTMLRadar blog.

Papermark

One non-first-party host across 70 requests, serving the document's own page images from CloudFront on signed URLs. That is the smallest recorded count among the products here that ship analytics. PostHog is present, loaded through a first-party proxy path on app.papermark.com/ingest; no request went to a posthog.com host. One cookie visible to page scripts, the PostHog one. Papermark's own view tracking fired: POST /api/views and POST /api/record_view on load, and four POST /api/views/pages after the scroll moved the counter from 1 to 10.

No response by 4 September 2026, the day this piece went up on the HTMLRadar blog.

Peony

Two Mixpanel Session Replay uploads were attempted, both through the first-party proxy path app.peony.ink/mp/record. The query strings carry the numbers:

95. [POST] …/mp/record/?…&seq=0&batch_start_time=1788072088.388&replay_id=1a05166d344321-…
      &replay_length_ms=5020&replay_start_time=1788072088.388&…&format=gzip => [308]
96. [POST] …/mp/record?…(same, no trailing slash)…                          => [402]

replay_start_time=1788072088.388 is 2026-08-30T06:41:28Z, one second after load. replay_length_ms=5020 is a 5.02-second segment, so the upload went out around 06:41:33Z, about five seconds before the ten-second wait finished and well before the scroll. A second upload followed with replay_length_ms=2092. Both were answered 402 Payment Required and did not complete.

Also observed: Hotjar (static.hotjar.com/c/hotjar-5115897.js), Sentry, Crisp live chat, thirteen POST /api/track_page_view_time calls, and one POST /api/viewer/authenticate issued without any e-mail being entered. The Mixpanel cookie carries distinct_id, $device_id and $user_id.

No response by 4 September 2026, the day this piece went up on the HTMLRadar blog.

Stacktree

No cookies visible to document.cookie, no localStorage keys, one script tag, and one non-first-party request that did not complete:

2. [GET] https://static.cloudflareinsights.com/beacon.min.js/v3d52b479… => [FAILED] csp

The page's own Content-Security-Policy blocked it. That is the whole third-party surface I recorded on this link: one blocked request.

No response by 4 September 2026, the day this piece went up on the HTMLRadar blog.

Tiiny.host

Nine requests in total. Analytics is Plausible, served from the vendor's own analytics.tiiny.site, not plausible.io, with one POST to /api/event answered 202. No cookies were visible to document.cookie and no localStorage keys were written. The only non-first-party hosts are Google Fonts, for the three typefaces in the publisher's own page. Two further first-party resources loaded from tiiny.host itself: /ad-script.js and /assets/img/ad.png.

Tiiny.host's response (30 August 2026, from their support channel):

Thank you for sharing the test results. Your observation is consistent with Tiiny Host's analytics design: we do not use cookies or persistent identifiers, so visitors are not tracked across sites. The analytics are intended to provide aggregate metrics such as visits, page views, referrers, locations, browsers, devices, and operating systems. Accordingly, the absence of document.cookie values and localStorage entries is expected. The analytics script is included on projects to measure usage and plan limits; analytics dashboards are available on paid plans. We cannot independently confirm the exact nine-request count or the specific behavior of the page at the timestamp provided, but we have no correction to the privacy-related findings described above.

HummingDeck

24 non-first-party hosts is the largest count in the table, and the structure behind it needs stating first. The room contains exactly one iframe:

https://calendly.com/ilya-hummingdeck/30min

The Calendly iframe is the room's "Let's meet!" section. Segment, Google Analytics, Google Tag Manager, Facebook, Amplitude, Sprig, Braze, Statsig, OneTrust, Airbrake, Stripe and reCAPTCHA all appear in the log after that frame loads. They are attributed here by timing, not by inspecting the frame. Per HummingDeck's reply below, these requests are initiated inside the Calendly embed configured in this room, not by HummingDeck's own analytics stack, which HummingDeck says is disabled on /r and /view paths - our attribution by timing is consistent with that. The top-level cookie count is nonetheless not the whole picture: any cookie set inside that frame belongs to calendly.com, and this test cannot read it.

What HummingDeck's own page requested, separately from the frame: 18 Next.js build chunks on hummingdeck.com; POST /api/room-views and GET /api/room-shares/b0c3f880-…/discussions for its own view tracking; eight assets from a storage.googleapis.com bucket named "hummingdeck" on signed URLs; and one request, at view time, to a third-party logo service:

https://img.logo.dev/northstarlg.com?token=[redacted]&size=128

northstarlg.com in that URL is buyer-branding metadata configured for the room, not the domain of the person opening the link. HummingDeck says it is fixed per room and identical for every visitor, and that it plans to fetch and cache the logo once, when the room is configured, instead of requesting it at view time.

Limit. The tested link is HummingDeck's own open example room, not a link configured for a specific recipient. A customer's configured room could differ.

Corrected 30 August 2026 after HummingDeck's reply.

HummingDeck's response (Ilya, founder, 30 August 2026, 08:58 UTC):

Some context for accuracy: HummingDeck's own analytics and advertising scripts are disabled on /r and /view paths. The tracker requests you mentioned were initiated inside the Calendly iframe included in this demo room, rather than by HummingDeck's analytics stack. It is third-party content configured in the room (scheduling embed is preloaded). I'd appreciate it if the piece made that distinction clear. The tested URL is an open example room, not a recipient-specific link. northstarlg.com is fixed buyer-branding metadata configured for the room and is identical for every visitor; it is not inferred from the person opening the link. That said, the Logo.dev finding is useful. We should fetch and cache the logo once when the room is configured, rather than request it at view time.

HTMLRadar, held to the same standard

HTMLRadar is ours, which is why the test covers seven links and not six. Same link type, same method. The fifteen-second window below is directly comparable with the six products above. The heartbeat lines come from the separate 55-second run and are labelled as such.

Where the document is served from. On 30 August the link was htmlradar.com/r/lumenforge-demo. Recipient documents have since moved to their own domain: that address now answers 301 to htmlradar.page/r/lumenforge-demo, and htmlradar.page carries none of the application's cookies.

What our tracker sends, and where. In the fifteen-second window, one remote procedure call to our own Supabase project at ewennjnxuqjzsgawbzur.supabase.co. In the 55-second run, three more, all to the same host. No other destination appeared in either log: no third endpoint, no image beacon, no separate event collector, no non-HTMLRadar host.

Fifteen-second window
POST /rest/v1/rpc/start_session   => 200
  p_share_slug, p_email, p_fingerprint, p_referrer, p_user_agent,
  p_country_code, p_city, p_device_type, p_os, p_browser

55-second run only - heartbeat, three times
POST /rest/v1/rpc/update_session  => 200
  p_session_id, p_token, p_active_seconds, p_max_scroll, p_sections[]
    p_sections[].section_id, p_sections[].section_title,
    p_sections[].depth, p_sections[].ordinal, p_sections[].time_seconds

start_session fires about five seconds after load. On an ungated share p_email carries no address. The geo fields are not empty labels: on this load they carried IN, Bengaluru and desktop, set by our own configuration line in the page.

What the sender is told. One e-mail, on the first open only, and nothing on repeat opens by the same reader. Its subject is the reader's address, or "An anonymous viewer" on an ungated link, then the document's title. The body is headed "First open" and carries the reader, the time in the sender's timezone, the title, and one link reading "See the read". Section titles and per-section seconds are in the dashboard, not in that e-mail.

Cookies and storage. None readable, and none can be written by page script on this page. We serve recipient documents with Content-Security-Policy: sandbox allow-scripts allow-forms allow-popups allow-downloads. Without allow-same-origin the document runs in an opaque origin, so:

window.origin                 -> "null"
document.cookie               -> THREW SecurityError: The document is sandboxed and
                                 lacks the 'allow-same-origin' flag.
localStorage / sessionStorage -> THREW SecurityError: same message.

One consequence is visible in the payload above: p_fingerprint is generated fresh on every load, because the tracker's attempt to persist it in localStorage throws and is swallowed. Nothing identifying the reader is written to the reader's machine.

A second policy rides alongside that one: frame-ancestors 'none'; base-uri 'none'; form-action 'none'. The last of those means a form inside an uploaded document cannot submit anywhere at all, so a convincing fake sign-in page cannot collect what a reader types into it.

Google Fonts. Four requests went to Google on this page, from the sender's own document: that stylesheet line (Fraunces plus Inter) is in the uploaded source file. Our own injection asks for a different Fonts URL, and only on the gate and error pages. On a document page it adds no Google Fonts request.

Two findings about HTMLRadar, treated the same way.

One. A Cloudflare Web Analytics beacon loaded on our recipient pages. At the time of testing, static.cloudflareinsights.com/beacon.min.js returned 200 and ran on this document page, and on the gate and not-found pages measured in an earlier pass. It came from a zone setting covering the whole htmlradar.com domain, which we read from our own Cloudflare account rather than from the browser. A setting rather than our code is an explanation and not an excuse, because it is our zone. Its data POST to htmlradar.com/cdn-cgi/rum was recorded as FAILED net::ERR_FAILED, blocked by our sandbox header, so the payload (page timings, memory figures, the page URL) never left the browser - a side effect of a security control, not a decision. We switched the setting off on 30 August 2026, and the re-check on 31 August recorded no request to cloudflareinsights at all.

Two. We show the reader nothing on the document itself. A search of the served HTML for "we record", "is tracked", "being tracked", "this data will be shared", "opt out" and "do not track" returns nothing, on both test dates. The only HTMLRadar chrome on the document is a "Powered by HTMLRadar" badge in the corner, on the free tier, and it says nothing about tracking. A gated link shows more: the e-mail gate says reading activity on the document is shared with the sender and links to our privacy page, and both gates carry a "Report this document" link to an anonymous form that reaches us, not the sender. An ungated document like this one shows neither. The opt-out is window.HTMLRadar.optOut(): it stops the running session, then sends the reader to a confirmation page, and the button there records the choice in a cookie the proxy sets and checks on every request. None of the other six tools in this set offers a way to opt out of its own read tracking - DocSend's cookie banner controls third-party advertising and analytics cookies, not DocSend's own page-view tracking.

What we changed, and what we decided not to.

1. Cloudflare Web Analytics auto-install on the htmlradar.com zone is off, so the beacon no longer loads on recipient pages - done 30 August 2026, confirmed by the re-test on 31 August.
2. We decided not to put a notice or a visible opt-out link on the document. Every tool in this set treats read tracking as the sender's setting, and we're not changing that. What we did instead is make the documented opt-out survive a reload, behind a confirmation the reader presses, so that neither a mailed link nor a document's own script can flip the setting for them.

What a recipient can check

The network and storage parts of this test can be run on any link, by the person who received it. In Chrome or Edge, press F12, or Ctrl+Shift+I, or Cmd+Option+I on a Mac, to open developer tools. Then:

• The Network tab. Reload the page with the tab open. Every request the page makes is listed with its host, so the number of other companies' servers the browser talked to can be read straight off the list.
• The Application tab. Under Storage, "Cookies" lists the cookies for the page's origin, including the HttpOnly ones that the document.cookie check used in this piece cannot see. "Local storage" and "Session storage" list what was written to the machine.

Between them, the Network tab and the Application tab show what loaded and what was stored. It does not show who receives the data or what is done with it afterwards; no browser can show that.

Corrections

If you build one of these products and something above is wrong, incomplete, or has changed since we tested, write to [email protected] and say so. I'll re-run the same test on a link of your choosing, publish your response verbatim alongside the original numbers, and date the update. The capture files behind the 31 August re-check - every request, its host and its status, per link - are kept, and I'll send yours on request.

Cheers,
Abhinandan