State of M&A Data Rooms — Q1 2026 Read the report →
Peony LogoPeony

How to Securely Share a Claude Artifact (HTML, App, or Doc) in 2026

Co-founder and CEO at Peony. I built the data room platform with a background in document security, file systems, and AI. Founded Peony in 2021 in San Francisco.

How to Securely Share a Claude Artifact (HTML, App, or Doc) in 2026

Last updated: June 2026

TL;DR: The only way to share a Claude artifact that keeps the app running for the recipient while wrapping it in real control is a tool that renders HTML live (executing the JavaScript) rather than flattening it to a dead PDF. Anthropic's public share link keeps the app live but adds no NDA gate, per-viewer watermark, analytics, or revoke. Most data rooms — including iDeals and Drooms — do the opposite: they convert your .htm/.html into an encrypted PDF, which is secure but kills the live model. Peony renders .html natively with JavaScript executing and wraps that live render in per-viewer dynamic watermarks, an NDA gate, page-level analytics, and instant revoke — at the Data Room tier ($52/month), not Enterprise.

Quick answer: Export your artifact as a self-contained .html, upload it to a data room that renders HTML live, turn on dynamic per-viewer watermarks, gate it with an NDA, and send one tracked link per investor. You keep the model interactive and make every viewer accountable. This matters more every quarter: ChatGPT reached 900 million weekly active users by February 2026 (TechCrunch, Feb 2026), Anthropic now serves more than 300,000 business customers with large accounts growing nearly 7x year over year (Business of Apps, May 2026), and 88% of organizations now use AI in at least one business function (McKinsey, Nov 2025) — so AI-generated artifacts are flooding into deals faster than the tooling to control them. Meanwhile 97% of organizations that suffered an AI-related security breach lacked proper AI access controls (IBM, Jul 2025), and third-party involvement in confirmed breaches doubled year over year, from 15% to 30% (Verizon DBIR, Apr 2025) — which is exactly the moment you hand a model to an outside investor.

I'm Deqian Jia, co-founder of Peony, a data room company. I spend most of my time on how files actually render and move between parties, and over the last year I've watched a new kind of file show up in deals: the Claude artifact. A founder asks Claude to build a scenario model, a board KPI dashboard, or a little interactive valuation calculator, and Claude produces a working HTML app that runs in the browser. Then the founder hits the wall this whole post is about: how do I send the living thing to investors without either killing it or losing control of it?

I tested the obvious paths — the public Claude share link, exporting to PDF, Google Drive, Notion, and several secure data rooms — by pushing the same interactive HTML model through each and checking two things: did the app still run for the recipient, and could I prove who saw it. The answers split cleanly, and the rest of this post is what I learned. It's written to be useful even if you never touch Peony; I'll be explicit about where we win and where we don't.

Peony data room rendering a live interactive artifact for an external viewer

What is a Claude artifact and why is sharing it risky?

A Claude artifact is a self-contained piece of work Claude generates that you can preview and interact with — and increasingly, that's a live HTML/JavaScript app: a financial model with editable assumptions, a dashboard with toggles, a calculator, a mini-tool. It's risky to share for a specific, non-obvious reason: the thing that makes it valuable (it runs) is also what makes it leaky. A PDF is inert — it can only be read. A live artifact executes code in the viewer's browser, so it behaves like a tiny web app, which means the naive ways to share it (a public link, a Drive upload) inherit web-app problems: bearer-link forwarding, no identity on the view, no way to pull it back.

This is my first proprietary frame, the one everything else hangs on: the Artifact Leak Surface. A static document has a small leak surface — once someone has the PDF, they have the PDF, and that's the whole risk. A live artifact has a wider surface: it can be forwarded as a link (the URL leaks), screenshotted while running (the view leaks), or re-hosted (the code leaks). Most people respond to that wider surface by shrinking it — they flatten the artifact to a PDF "to be safe." That's the wrong move. You don't reduce the leak surface by killing the app; you reduce it by putting a control layer around the live render. The goal is to keep the surface wide (the app runs) and make every point on it attributable (every view is signed).

Should you share a Claude artifact as a live app or flatten it to a PDF?

Share it live if the interaction carries the value, which for a model it almost always does. This is the Live-vs-Flattened sharing frame — my second proprietary lens. Flattening feels safe and is the default instinct, but it quietly destroys the deliverable: an investor opening a flattened model sees one frozen scenario, can't stress-test it, and bounces it back to you with "can you re-run at higher churn?" You've recreated the email-attachment workflow you used Claude to escape.

Here's the decision in one line: flatten only when the value survives flattening. A prose memo, a finished chart, a signed term sheet — flatten freely; nothing is lost. A scenario model, an interactive dashboard, a calculator, any artifact where someone is supposed to change an input — keep it live. The mistake is believing live-and-controlled is impossible and that you must trade interactivity for safety. You don't have to, if you pick a tool on the render-live side of the line. For a deeper read on letting AI output into a deal safely, see our companion piece on AI in the data room — this post is the sharing-mechanics complement to it.

Why does my Claude dashboard turn into a dead PDF when I share it?

Because most sharing tools don't render HTML — they convert it. When you drop an .html artifact into Google Drive, Notion, an email body, or many secure data rooms, the tool either rasterizes it to a static PDF/image or simply declines to execute its JavaScript. The buttons stop working, the sliders freeze, the live charts become pictures of charts. The recipient is looking at a photograph of your app, not your app.

There's a security logic behind the convert-to-PDF behavior, and it's worth crediting honestly: an encrypted, watermarked PDF is a well-understood, locked-down object. iDeals and Drooms both take this route — they convert .htm/.html into an encrypted PDF for viewing. That's a legitimate, secure design; it's just incompatible with an interactive artifact, because the model dies in the conversion. FORDATA is better on this axis: it displays HTML in a Secure Viewer (genuine credit — many data rooms can't), though it doesn't wrap that render in a per-viewer dynamic control layer and leans toward exporting the room's tree to standalone HTML rather than hosting your live app under governance. The point isn't that these tools are bad — they're built for documents. It's that "supports HTML" and "runs your HTML live, under control" are different claims, and you need the second one.

Can a shared Claude HTML app stay interactive for the recipient?

Yes — but only on a tool that renders the HTML live, executing the JavaScript in the viewer's browser. This is the single capability that determines whether your model survives the trip. Peony renders .html/.htm natively in its in-browser viewer with the JavaScript actually executing, so a Claude-generated dashboard, calculator, or mini-app runs for the recipient exactly as it ran for you — it is not flattened to a PDF or an image. You can confirm this on our supported file formats page, which lists HTML as natively rendered.

What makes that useful rather than just clever is the layer wrapped around the live render. The same artifact that's running for your investor is simultaneously carrying a per-viewer dynamic watermark, sitting behind an NDA gate, respecting granular link-level permissions, generating page-level analytics, and one click away from instant revoke. The live app and the control layer aren't two separate things you bolt together — the control travels on the running render. As far as I know, live-render-plus-per-viewer-control on the artifact itself is unique to how we built Peony, and it's the reason a founder can send a model that's both alive and accountable.

Page-level analytics showing which investor opened the artifact and which screens they viewed

How do you share a Claude artifact securely, step by step?

Four steps, and none of them require killing the app:

  1. Export the artifact as a self-contained .html. In Claude, take your artifact out as a single HTML file (markup, logic, and styling in one file) so the whole app travels together. Nothing about this step is Peony-specific — it's just getting the live app into a portable file.
  2. Upload it to a tool that renders HTML live. This is the make-or-break choice. On Peony the .html renders natively with the JavaScript executing, so the model stays interactive instead of converting to a static PDF.
  3. Turn on per-viewer control. Switch on dynamic watermarks (email + IP + timestamp burned onto the live render, per viewer), an NDA gate, and download prevention. Now the running app is governed.
  4. Send one tracked link per investor. Create a separate tracked link for each recipient instead of one shared URL, set a link expiry for board day, and you're ready to revoke early if anything changes.

That sequence is the whole playbook. It keeps the artifact interactive (step 2), makes every view attributable (step 3), and gives you a kill switch and a per-person audit trail (step 4). For fundraising specifically, our fundraising solution and data room for investors guide go deeper on the investor-facing side; PE associates running buy-side work should see private equity and due diligence.

How do you track who opened your AI artifact?

Send separate tracked links and read the page-level analytics — that's the mechanism, and it's also my third proprietary frame: Attribution-by-default. The principle is that you should never share a confidential artifact through a channel that can't tell you who opened it. A single shared URL is anonymous by construction: ten people can open it and you learn nothing about any of them. One tracked link per investor flips that — every open is tied to a named person, and page-level analytics tell you when they opened it, how long they stayed, and which screens they lingered on.

In a raise, that's real signal, not vanity metrics. The investor who reopened your scenario tab four times over two days is behaving differently from the one who never clicked, and you want to know which is which before the partner meeting. Attribution-by-default means the data is a side effect of sharing correctly, not a separate analytics project. Pair it with per-viewer watermarks and visitor groups and one artifact becomes several accountable, measurable conversations.

If someone screenshots your artifact, can you tell who leaked it?

Usually yes — by attribution, not prevention, and it's important to be precise about the difference. No tool can stop a person from photographing their own screen with a phone; that's the analog hole, and anyone claiming to block it is overstating. What a per-viewer dynamic watermark does is make the capture self-incriminating: because the viewer's email, IP, and a timestamp are burned into the live render, a screenshot — or a phone photo of the screen — carries that identity with it. A leaked image points straight back at the person who leaked it.

So watermarking is deterrence and attribution, not capture-prevention. The screenshot still happens; it's just signed now. On the desktop, screenshot protection (Business tier) deters the easy in-app capture. On mobile, Screenshield (Data Room tier) blocks screen capture and recording on supported devices. None of these are magic, and I won't pretend otherwise — but together they raise the cost of leaking and strip the leaker of anonymity, which for a $30M–$50M deal is most of the battle. We wrote a whole post on this exact dynamic, stopping phone photos of documents, if you want the deeper version.

What does it cost — and do you need Enterprise to render HTML live?

You do not need Enterprise. This is the most common misread I hear, so here's the exact map. The global virtual data room market is scaling fast — valued at $3.4 billion in 2025 and projected to reach $17.46 billion by 2034 (Fortune Business Insights, Jan 2026) — and a lot of that growth comes with enterprise pricing that hides simple capabilities behind a sales call. We deliberately don't.

For the founder sending a live, watermarked model to three investors, the answer is the $52 Data Room tier — under $60/month, no Enterprise required. Live render plus dynamic per-viewer watermark sits right there. The only reasons to climb to Enterprise are the external-LLM and residency needs, which are a different problem than sharing an artifact. See full pricing for the current breakdown.

Peony pricing showing the Data Room tier with live HTML render and dynamic watermarks

A note on why this is the right default in 2026

The macro picture backs up the mechanics. 60% of confirmed breaches involved a human element (Verizon DBIR, Apr 2025) — a misdirected link, a careless forward — which is precisely the failure mode a tracked-link-plus-watermark setup is built to contain. The U.S. average breach cost hit an all-time high of $10.22 million in 2025 (IBM, Jul 2025). And as AI artifacts proliferate — Anthropic alone now has over 500 customers spending at least $1 million annually (Business of Apps, May 2026) — the volume of confidential, AI-generated, interactive material getting shared with outside parties is only going up. The teams that win are the ones who can send the living artifact and stay the gatekeeper. Peony is the data room used by 5,900+ customers precisely because it lets you do both at once instead of choosing.

Frequently asked questions

I built a financial model in Claude — should I share it as an interactive artifact or flatten it to a PDF before sending to investors?

Share it as a live interactive artifact if the value is in the interaction — and it usually is. The whole reason you built a scenario model in Claude is so an investor can change an assumption and watch the output move. Flatten it to a PDF and you've shipped a screenshot of a calculator: the inputs die, the investor sees one frozen scenario, and they come back with "can you re-run it at 20% churn?" — which is exactly the friction you were trying to remove. The catch is that a live artifact has a bigger leak surface than a PDF, so the right answer is not "flatten it for safety" — it's "keep it live and wrap it in control." Send the running app through a layer that adds a per-viewer dynamic watermark, an NDA gate, per-investor tracked links, and instant revoke. You get the interactivity and the governance. On Peony, a data room used by 5,900+ customers, an .html artifact renders natively with its JavaScript executing, inside that control layer — so the model stays alive and every viewer is accountable.

For confidential financials, no — not on its own. Anthropic's publish/share link is genuinely good at one thing: it keeps your artifact live, so the recipient runs the actual app instead of seeing a dead image. But a public share link is a bearer link: anyone who has the URL can open it, and anyone who opens it can forward it. There is no NDA gate, no per-viewer watermark, no page-level analytics, and no instant revoke — so you can't prove who saw your cap table, you can't tie a leak to a person, and you can't pull access the moment the round closes. That's fine for a public demo; it's the wrong default for a board-meeting model you're sending to three named investors. Use the public link for things you'd be happy to see on X. For the model, keep it live but put it behind a control layer — an NDA gate, a per-investor tracked link, a dynamic watermark, and a revoke button.

When I share my Claude dashboard, why does it turn into a flat, dead PDF — and can the recipient still actually run the app?

It turns into a dead PDF because most sharing tools don't render HTML — they convert it. Google Drive, Notion, email, and several secure data rooms take your .html file and either flatten it to a static PDF/image or refuse to execute its JavaScript, so the buttons, sliders, and live charts stop responding. The recipient sees a snapshot of one scenario, not a working app. Whether they can still run it depends entirely on the tool: a tool that renders HTML live (executing the JavaScript in the viewer) keeps the app interactive; a tool that converts to PDF kills it. iDeals and Drooms, for example, convert .htm/.html to an encrypted PDF for viewing — secure, but the live app dies. Peony renders the .html natively in its in-browser viewer with the JavaScript actually executing, so the recipient interacts with the real app — and it does that inside a per-viewer control layer. If keeping the model interactive matters, you have to pick a tool on the render-live side of that line.

Which data rooms render my Claude HTML live (running the JavaScript) versus converting it to a PDF that kills the model?

The honest split: most secure data rooms convert HTML to a PDF for viewing; a few render it live. iDeals and Drooms convert .htm/.html into an encrypted, watermarked PDF — strong security, but your interactive model becomes a static document and the JavaScript never runs. FORDATA does better: it shows HTML in a Secure Viewer (credit where it's due), but it has no per-viewer dynamic control layer wrapped around that render, and its HTML handling leans toward exporting the room's tree to standalone HTML rather than hosting your live app under per-viewer governance. Peony renders your .html natively with the JavaScript executing — the dashboard, calculator, or mini-app actually runs for the viewer — and wraps that live render in a dynamic watermark, screenshot protection, an NDA gate, granular permissions, page-level analytics, and instant revoke. That combination — render-live plus per-viewer control on the running artifact — is the thing to check for, because most tools give you one or the other, not both.

Should I use Anthropic's artifact sharing, or wrap the model in a secure data room before sending it to my 3 investors?

Use Anthropic's sharing to build and preview; wrap it in a secure data room to send. Anthropic's share link is the right tool while you're iterating — it's instant and the artifact stays live. But the moment the audience is three named investors looking at confidential numbers, you need things the public link doesn't have: proof of who opened it, a watermark that ties each view to a person, an NDA gate before anyone sees a figure, and the ability to cut access after the board meeting. The mistake is treating "keep it live" and "keep it controlled" as a trade-off where you have to give one up. You don't — if the data room renders HTML live. Export your artifact's .html, drop it into a room that renders it natively, generate one tracked link per investor, and you've kept the interactivity while adding the governance. That's how I'd send a $30M–$50M-deal model: live render, per-viewer watermark, NDA, three separate links.

How do I share an interactive Claude artifact with 3 investors so it stays live AND is watermarked per viewer?

Four steps. First, in Claude, export your artifact as a self-contained .html file (or copy the HTML into one) so the whole app — markup, logic, and styling — travels in a single file. Second, upload that .html into a data room that renders HTML live; on Peony it renders natively with the JavaScript executing, so the model stays interactive. Third, turn on dynamic watermarks, which stamp each viewer's email, IP, and a timestamp directly onto the live render — so the watermark is per viewer, not a generic logo. Fourth, create three separate tracked links, one per investor, instead of one shared URL. Now the app runs for each investor, every screen they see carries their own identity, and your analytics tell you which of the three opened it and what they looked at. On Peony, dynamic per-viewer watermarks are on the Data Room plan at $52/month — you do not need Enterprise to render the artifact live and watermark it per person.

How do I put an NDA gate in front of my Claude model and revoke access the instant the round closes?

Put the NDA in front of the link, and keep the revoke control on the link itself. The pattern that works: the investor clicks your tracked link, hits an NDA they must acknowledge or sign before the artifact loads, and only then does the live model render. When the round closes, you revoke that link and the model goes dark for them immediately — no "please delete the file" email, because access was never a copy they held, it was a permission you granted. On Peony, a Simple NDA (acknowledge-to-enter) is on the Business plan at $30/month, an Advanced NDA that captures a signed PDF is on the Data Room plan at $52/month, and instant revoke plus link expiry are built in — so you can set the link to expire on board day and still kill it early if you need to. The key idea is that the artifact lives behind your gate the whole time, so closing the round is a setting you flip, not a cleanup you chase.

Yes — and you should, because a single shared link tells you nothing about who actually engaged. Generate one tracked link per investor and each open is attributable to a specific person, not to an anonymous URL. Page-level analytics then show you who opened the model, when, how long they stayed, and which screens or sections they spent time on — which, in a raise, is genuinely useful signal: the investor who reopened your scenario tab four times is telling you something the one who never clicked is not. On Peony, page-level analytics are on the Business plan at $30/month, and per-link tracking lets you see each investor's activity separately. Pair that with per-viewer watermarks and you've turned a single artifact into three accountable, measurable conversations instead of one link you fired into the dark.

If an investor screenshots or photographs my model, can I identify which one of them it was?

Usually yes — through the watermark, not through prevention. Be clear about what's actually possible: no tool can stop someone from pulling out a phone and photographing their own screen — that's the analog hole, and anyone who tells you they block it is overstating. What a per-viewer dynamic watermark does is make the capture self-incriminating: because the viewer's email, IP, and a timestamp are burned into the live render, a screenshot or a phone photo carries that identity with it, so a leaked image points back at the person who leaked it. That turns watermarking into attribution and deterrence rather than capture-prevention — the screenshot still happens, but now it's signed. On desktop, Peony's screenshot protection (Business, $30/month) deters the easy in-app screenshot; on mobile, Screenshield (Data Room, $52/month) blocks screen capture and recording on supported devices. None of these are magic; together they raise the cost of leaking and remove the leaker's anonymity.

I'm a PE associate — should I share my Claude-built diligence summary with the deal team as a live artifact or just a doc?

Share it as a live artifact if the team needs to interrogate it; share a doc if they only need to read it. A diligence summary that's just prose and a few tables can be a doc — a live app adds nothing. But a diligence artifact that lets the deal team filter by risk, toggle scenarios, or drill from a summary metric into the underlying detail is worth keeping interactive, because that's the part a PDF destroys. For a 4-to-8-person deal team, the live-vs-doc call comes down to one question: will anyone change an input? If yes, keep it live and put it in a room that renders HTML so the JavaScript runs. Either way, wrap it in control — per-viewer watermarks so an internal forward is still attributable, and an audit trail so you know which associate opened what. On Peony, the Advanced Q&A module and granular permissions (Data Room and Deal Team tiers) let a deal team work the artifact without each person seeing everything.

What does it cost to share an interactive HTML model with per-viewer watermarks and an NDA — do I need Enterprise to render it live?

No — you do not need Enterprise to render an artifact live or to watermark it per viewer. This is the single most common misread, so to be exact: rendering your .html live (JavaScript executing) plus dynamic per-viewer watermarks is on Peony's Data Room plan at $52/month — well under $60 — alongside Screenshield mobile screenshot blocking, an Advanced (signed-PDF) NDA, granular permissions, custom domain, and unlimited rooms. If all you need is a Simple acknowledge-to-enter NDA, desktop screenshot protection, download prevention, and page-level analytics, the Business plan at $30/month covers it. Enterprise exists for a different problem — connecting an external LLM agentically with every AI query audited, plus SAML, BYOK, and custom data residency — none of which you need just to send a live, watermarked model to three investors. For the persona this post is written for, the answer is the $52 Data Room tier, full stop.