How to Securely Share a ChatGPT Canvas (App, Dashboard, or Doc) in 2026

Last updated: July 2026

TL;DR: If you built a client deliverable in a ChatGPT canvas — a scenario model, a KPI dashboard, a little app in a code canvas — do not send it on the native share link. That link is view-only, offers no watermark, no NDA gate, no expiry, and no analytics, the recipient can fork their own copy — and in practice it demands a ChatGPT sign-in, so a board member without an account typically hits a login wall instead of your model. Worse, the Canvas surface itself is being sunset: OpenAI pulled it from current models in late May 2026 and the legacy models that still reach it are retiring through August 2026. The durable move is to own the exported file, not the vendor's surface — ask ChatGPT to rewrite the app as one self-contained .html, then share that file live through a controlled viewer. Peony renders .html natively with its JavaScript executing and wraps it in per-viewer dynamic watermarks, an NDA gate, tracked links, and instant revoke — at the Data Room tier ($52/month), not Enterprise.

Quick answer: Ask ChatGPT to rewrite your canvas app as one self-contained .html file, download it and confirm it opens in a browser, upload it to a viewer that renders HTML live, turn on dynamic per-viewer watermarks, gate it with an NDA, and send one tracked link per board member. You keep the app interactive and make every viewer accountable — which matters more every quarter. ChatGPT has passed 900 million weekly active users (TechCrunch, Feb 2026) and OpenAI now serves over 1 million business customers with more than 7 million ChatGPT for Work seats (OpenAI, Nov 2025), so AI-built deliverables are flooding into client work faster than the controls around them. Meanwhile GenAI is now the single largest corporate-to-personal data-exfiltration channel, accounting for 32% of all such data movement (LayerX, 2025), and 97% of organizations that suffered an AI-related breach lacked proper AI access controls (IBM, Jul 2025) — which is exactly the moment you hand a client's numbers to five people outside your firm.

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 two parties, and over the last year a new kind of deliverable has shown up on the desks of the fractional CFOs and independent consultants I talk to: the ChatGPT-built app. Someone advising a startup asks ChatGPT to build a runway scenario model with editable assumptions, or a KPI dashboard with toggles, or a small React app in a code canvas — for a client's board meeting. ChatGPT produces a working thing that runs in the browser. Then the consultant hits the wall this whole post is about: how do I get the living thing in front of a client's CEO and four board members — most of whom don't even use ChatGPT — without either killing it or losing control of it?

That wall is taller than it is for the Claude equivalent, for two specific reasons. First, a ChatGPT canvas share link in practice demands that the recipient be signed in to a ChatGPT account — so a board member without one typically hits a login wall instead of your model. Second, the Canvas surface itself is being retired: OpenAI removed it from its current models in late May 2026 and folded editing into inline "writing blocks" and "code blocks" in the chat thread, leaving Canvas reachable only through legacy models that are themselves retiring. A deliverable that lives on a surface the vendor is actively sunsetting is a deliverable on borrowed time.

I tested the paths a fractional CFO would actually reach for — the native ChatGPT share link, exporting the code, dropping it in Google Drive, deploying it to Vercel, and putting it in a data room — by pushing the same interactive model through each and checking two things: did the app still run for a recipient who doesn't use ChatGPT, 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 the native path, a competitor, or a free host is genuinely the right call, and where it isn't. If you happen to be building in Anthropic's tools instead, the sibling to this piece — how to securely share a Claude artifact — walks the same ground on that side.

What is a ChatGPT canvas — and why is it risky to share right now?

A ChatGPT canvas is a side-panel workspace where ChatGPT builds a document or code you can edit in place instead of scrolling through chat — and, increasingly, that means a live app: a financial model with editable inputs, a dashboard with toggles, a calculator, a small React or HTML tool. Canvas launched in October 2024 as a Plus and Team beta, opened to all tiers through 2025, and picked up a limited HTML and React preview along the way. So far, so useful.

It's risky to share right now for a reason that has nothing to do with your data hygiene and everything to do with timing: the surface is being sunset. In late May 2026 OpenAI removed Canvas from its current models (GPT-5.5 Instant and Thinking), replacing it with inline "writing blocks" and "code blocks" that live directly in the chat thread. Canvas still exists, but only through legacy models — and those are on the way out too: GPT-4.5 retired in June 2026, and o3 retires in August 2026. Users have noticed and pushed back; there's an active OpenAI community feature request to "bring Canvas back to current ChatGPT models" (July 2026) arguing the inline editor lost Canvas's precise-edit controls.

Two practical takeaways. First, vocabulary: your client and the wider web still say "canvas" (it's what people search, and it's the legacy surface that still exists), but the current product surface is "code blocks" and "writing blocks" — so if you're following a colleague's instructions from six months ago, the buttons have moved. Second, and this is the whole spine of the post: a deliverable that lives on the editing surface can be changed or retired out from under you. If your client's board model exists only as a ChatGPT canvas, its future depends on OpenAI's product roadmap. That's the setup for the first of two frames this post runs on.

Why should you own the file, not the surface?

Own the file, not the surface — that's my first frame, and the Canvas sunset is the cleanest proof of it you'll ever get. A "surface" is the vendor's live editing environment: the ChatGPT canvas, the inline code block, the share link that only works inside their product. A "file" is the thing you can export and hold: a self-contained .html app that opens in any browser on any machine. When your deliverable lives on the surface, three risks ride along — the vendor can change the UI (as OpenAI just did), the vendor can retire the surface (as OpenAI is doing to Canvas), and the sharing mechanics are whatever the vendor decided (in ChatGPT's case, a login wall).

When your deliverable lives in a file you control, all three evaporate. The exported .html doesn't care that Canvas is retiring; it runs the same in December as it did in May. It doesn't require the recipient to have a ChatGPT account. And you get to choose how it's shared and controlled, because it's your file now, not OpenAI's surface. This is why the entire back half of this post is about getting the app out of ChatGPT as a portable file and then sharing that. The surface is convenient for building; it's the wrong place to leave a deliverable a client is depending on. For the broader question of letting AI output into sensitive work safely, our companion piece on AI in the data room is the strategic complement to this mechanics-level post.

Should you share a ChatGPT canvas as a live app or export it to a PDF?

Keep it live if the interaction carries the value, which for a model or a dashboard it almost always does. Flattening to a PDF feels safe and is the default instinct, but it quietly destroys the deliverable: a board member opening a flattened model sees one frozen scenario, can't stress-test it, and emails you "can you re-run at a 15% haircut?" — which recreates the back-and-forth you used ChatGPT to escape. The interactive format earns its keep precisely after the meeting, when a director reruns your covenant headroom at 11pm without needing you on the call.

Here's the decision in one line: flatten only when the value survives flattening. A prose memo, a finished chart, a signed engagement letter — export to PDF freely; nothing is lost. A scenario model, an interactive dashboard, an ROI calculator, anything where someone is supposed to change an input — keep it live. The trap is believing live-and-controlled is impossible, so you must trade interactivity for safety. You don't — but only if the tool you share through renders HTML live instead of converting it. That's the fork the next section is about, and it's also worth being fair about the other direction: if your deliverable genuinely is a static board deck, a PDF through a tracking tool like DocSend is a perfectly good answer, and I'd tell a client so.

Is the native ChatGPT canvas share link safe for confidential client numbers?

For confidential client numbers, no — the native share link is missing almost everything a board deliverable needs, and it has a couple of traps on top. Start with the mechanics, because they're the direct answer to what a lot of people actually search. A canvas share link is view-only and, critically, in practice requires the recipient to be signed in to a ChatGPT account to open it. That's the consistently reported behavior — and for ChatGPT Business and workspace shares it's explicit: someone outside the workspace can't see the share at all and is simply redirected away. So the board member who doesn't use ChatGPT — on most boards, that's most of them — clicks your link and hits a sign-in wall, not your model. Either way, you can't count on a recipient without ChatGPT reliably opening your link, and that gap is the number-one reason the native path fails for client work: your deliverable is only as reachable as your least-technical recipient's willingness to create an OpenAI account.

Even for recipients who are signed in, the control surface is nearly empty: no per-viewer watermark, no NDA gate, no expiry, no password, no view analytics, and no per-viewer links. Revoking means going into settings and deleting the shared link. And there are two traps worth stating outright. First, a shared canvas is not a running interactive app for the recipient — Canvas's HTML/React preview is a limited preview pane, not a full sandboxed app renderer, and sharing does not preserve interactivity; treat the share link as sharing the document or code, not a live app. Second, and this one bites people: deleting the chat does not kill an existing share link. You have to delete the shared link itself in settings (Bitdefender documented this in 2025). Delete the conversation, feel safe, and the link can quietly stay live.

There's also a cautionary episode worth getting exactly right, because it's easy to garble. In July and August 2025, ChatGPT's chat-share feature (this is chats, not canvas links) briefly included an opt-in "make this chat discoverable" toggle, and roughly 4,500 shared conversations ended up indexed by Google and other search engines — some containing names, emails, and sensitive details (TechCrunch, Jul 2025; Fortune, Aug 2025). OpenAI removed the feature in early August 2025; its CISO Dane Stuckey called it a "short-lived experiment" that created "too many opportunities for folks to accidentally share things they didn't intend to." To be precise: canvas links were never search-indexed by default, so this is not "your canvas will show up on Google." What it does show is how thin the line is between "shared" and "public" on a consumer AI share surface — a single toggle turned private conversations into search results. For a client's confidential financials, that's not a surface you want to be one setting away from exposure on.

Why is a view-only link not the same as control?

Here's my second frame, and it's the one that cuts through the false comfort of that login wall: view-only is not control. It's tempting to look at the ChatGPT share link — account required, view-only, no download button — and conclude it's safer than a public link. It isn't, and conflating "restricted" with "controlled" is the mistake that gets client numbers leaked. View-only tells you what the recipient can do in the moment (look, not edit). Control is a different axis entirely — it's about the three questions that actually matter for a confidential deliverable: who saw it, can you prove who saw it, and can you end their access.

The native canvas link answers none of those. It doesn't know who opened it beyond "someone with a ChatGPT account." It can't prove anything to you afterward, because there are no per-viewer analytics. It can't end cleanly, because there's no expiry and the recipient may have forked their own copy via "Edit with ChatGPT" — at which point they hold a fork in their own account that your "revoke" can't touch. A login-walled, view-only link is still an uncontrolled copy the moment it's open; the wall just gates the front door while leaving every window open. Real control means knowing who (analytics), proving who (a per-viewer watermark burned onto the render), and ending when you decide (revoke and expiry). Everything Peony does in this workflow is aimed at those three, and none of them are things "view-only" gives you.

How do you get the app out of ChatGPT as one self-contained .html file?

Ask ChatGPT to rewrite the app as a single self-contained .html file, then download it — because there's no one-click button that does this for you. This is the step that turns a surface-bound canvas into a file you own, and it's a prompt technique, not a menu item. The canvas download button will hand you a .py, .js, .docx, or .md depending on the content (and copy-to-clipboard works), but none of those is a runnable single-file app. So you ask for one directly:

1. Prompt ChatGPT to consolidate the app into one file. Say, in plain terms: "Rewrite this as a single self-contained .html file — inline all the CSS and JavaScript, and convert any React to vanilla JavaScript or load it from a CDN — so the whole app is in one file that opens in a browser." The goal is that markup, logic, and styling all travel together.
2. Download the file (or paste it into a blank .html). Save what it produces as, say, board-model.html. If it hands you the code in the chat, paste it into an empty text file and save it with an .html extension.
3. Open it locally and confirm it actually runs. Double-click the file so it opens in your own browser, and click through it — flip a toggle, change an input, check the charts recompute. This is the step people skip and regret; if a dependency didn't inline correctly, you find out now, not when the CEO opens it. Ask ChatGPT to fix anything that's broken and re-download.
4. You now hold a portable app that outlives Canvas. That file doesn't depend on ChatGPT, doesn't need the recipient to have an account, and doesn't care that the Canvas surface is retiring. It's yours to host and control.

That's the whole export playbook, and it's tool-agnostic — nothing in it is Peony-specific. It's simply how you take ownership of the file. What you do with the file next is the part that determines whether it stays interactive and controlled.

Should you just deploy it to Vercel or Netlify instead?

For a public portfolio demo, yes — deploy to Vercel or Netlify and don't overthink it. For a confidential client deliverable, no. Let me be fair first, because the technical path is genuinely good: Vercel and Netlify are fast, free at the tier you'd use for this, and purpose-built for putting a web app online. If what you have is a demo you'd happily post on your website or share publicly, they're the right, cheap answer, and a data room would be overkill.

The problem is that "confidential client board model" is the opposite of "public demo," and a default Vercel or Netlify deploy is a public URL with no access control — no per-viewer identity, no NDA gate, no expiry, and no analytics you can act on. Anyone with the URL opens it; you can't tell who did; you can't take it back. On top of that, you've quietly taken on DNS, builds, and maintenance for what was supposed to be a one-off deliverable — and a client's private financials living on a hobby-tier public URL reads as unprofessional even before it's a security issue. The choice people frame as "Vercel vs Netlify" is the wrong axis; the real fork is public host vs controlled share. For anything carrying a client's real numbers, take the same exported .html and put it somewhere that renders it live and answers the who/prove/end questions from the last section. That's the next part.

How do you keep the app interactive AND controlled?

Put the exported .html in a viewer that renders it live — executing the JavaScript in the recipient's browser — and that wraps per-viewer control around that same render. This one capability decides whether your model survives the trip. Peony renders .html/.htm natively in its in-browser viewer with the JavaScript actually executing, so a ChatGPT-built 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, and the recipient does not need a ChatGPT account (or any account of yours). You can confirm the native-render behavior on our supported file formats page.

What makes that useful rather than just clever is the control layer traveling on the live render. The same app that's running for your client's board is simultaneously carrying:

• A dynamic per-viewer watermark — the viewer's email, IP, and a timestamp burned onto the live render, per person, not a generic logo. This is the Data Room plan, $52/month.
• An NDA gate — a Simple acknowledge-to-enter notice (Business, $30/month) or an Advanced NDA that captures a signed PDF (Data Room, $52/month) that the viewer clears before anything renders.
• Page-level analytics and one tracked link per recipient — so every open is attributable and you can see which board member engaged (Business, $30/month). Analytics are page-level, not keystroke-level.
• Granular permissions — so an observer sees less than the CEO if you want, and instant revoke plus link expiry, built in, so access has an ending you control.

The live app and the control aren't two things you bolt together — the control rides on the running render. As far as I know, live-render-plus-per-viewer-control on the exported app itself is unusual; most tools give you one or the other. It's the reason a fractional CFO can send a board model that's both alive and accountable. This is also, worth noting, the same live-render pattern our other client-deliverable guides use from different seats — sending a live dashboard to a client, sharing an interactive financial model with an investor, and sharing an interactive board report with directors — the mechanics carry across, the counterparty and stakes change.

If a board member forwards or screenshots the model, can you tell who leaked it?

A per-viewer tracked link can't be usefully forwarded, and a screenshot of a watermarked render points back at the person who took it — so usually yes, by attribution rather than prevention. Take forwarding first. A native canvas link or a public URL is a bearer link: whoever holds it can pass it along, and on ChatGPT the recipient can even fork their own copy via "Edit with ChatGPT" and walk off with an uncontrolled version in their own account. A tracked link bound to one named viewer removes the anonymous forward — access is tied to a person, not floating in a URL you've lost track of.

On screenshots, be precise about what's actually possible. No tool can stop someone photographing their own screen with a phone — 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 straight back at the person who leaked it. That turns watermarking into attribution and deterrence, not capture-prevention — the screenshot still happens; it's just signed now. On the desktop, screenshot protection (Business, $30/month) deters the easy in-app capture; on mobile, Screenshield (Data Room, $52/month) 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 client's board numbers is most of the battle. For the deeper version of exactly this dynamic, our dynamic watermarking guide goes further.

What does it cost — and is a data room overkill for a solo practice?

It costs roughly $30 to $52 a month, and no, a modern data room is not overkill for a one-person practice — the pricing is built for exactly this. This is the most common objection I hear from solo fractional CFOs, so let me lay out the real options honestly, including the ones that aren't us.

DocSend is excellent for what it's built for — a PDF board deck or pitch deck with view tracking — but it's a document-and-deck tool: running an interactive HTML app isn't its job, so a live model arrives flattened or not at all. Right tool for a static deck, wrong one for a live model. Papermark deserves genuine credit here: it's the one other vendor thinking seriously about AI-built artifacts, with agent and MCP positioning and an open-source core, and it's a legitimate alternative worth evaluating. Google Drive, Notion, or email will each either flatten the app, refuse to execute its JavaScript, or give you link-level rather than viewer-level control — fine for a doc, wrong for a live deliverable you need to attribute. And a data room like Peony renders the exported app live under per-viewer control.

Here's the exact Peony map for this job, because the pricing is the whole point of the objection:

• Business — $30/month: page-level analytics and tracked links, Simple NDA (acknowledge-to-enter), desktop screenshot protection, download prevention, custom logo. Good for a lower-sensitivity share where you mainly want read-receipts and a light gate.
• Data Room — $52/month: everything this job actually needs — live HTML render with dynamic per-viewer watermarks, Screenshield mobile capture blocking, Advanced NDA (signed PDF), granular permissions, custom domain, unlimited rooms. This is the tier for a confidential client model on a live app.
• Enterprise — custom: a different problem entirely — connecting an external LLM (GPT, Claude, or Gemini) agentically with every AI query audited, plus SAML, BYOK, and custom data residency.

For the fractional CFO sending a live, watermarked model to a CEO and four board members, the answer is the $52 Data Room tier — under $60/month. Against a $10,000-plus engagement that is a rounding error, and to be completely explicit: you do not need Enterprise to render the app live and watermark it per viewer — that lives on the $52 Data Room plan. The only reasons to climb to Enterprise are the external-LLM and data-residency needs, which are a different job than sharing a client deliverable. See full pricing for the current breakdown.

What about pushing from ChatGPT directly — can I skip the file entirely with MCP?

Not as an individual on a Plus or Pro plan — pushing out of ChatGPT into an external system is gated to workspace plans, so for most fractional CFOs the exported file is still the universal path. It's worth being precise here because the terminology shifted. OpenAI renamed connectors to "apps" in December 2025, and custom MCP connectors with write actions are limited to Business, Enterprise, and Edu workspaces (via a Developer Mode beta); individual Plus and Pro accounts get read and fetch only. So "push a finished artifact from ChatGPT into my sharing tool via MCP" is a workspace-plan capability, not something a solo Plus user can do today.

Where does Peony fit? Peony ships a bidirectional MCP server — an AI agent can read a room's contents and push an artifact into a room — and the confirmed push flow today runs from Claude: build in Claude, install the Peony MCP, push the artifact straight into a watermarked, gated, revocable room without leaving the chat (that's covered in the Claude artifact guide). For ChatGPT, I'd set expectations honestly: there is no shipped one-click Peony-ChatGPT app integration, so the export-the-file workflow is the universal path that works from any plan and any surface — and if your organization is on a Business or Enterprise ChatGPT workspace with write-capable connectors, MCP push becomes technically possible on that side over time. For now, the file is the thing you own and the file is the thing you share; that's a feature, not a limitation, and it's the same "own the file, not the surface" logic that started this post.

Is sending interactive deliverables the new normal for fractional CFOs?

Yes — interactive, drive-it-yourself deliverables are moving from novelty to expectation, and the consultants who handle the control question well turn it into a selling point. Boards and CEOs have gotten used to doing something to the numbers themselves: flipping the base case to the downside, stretching the date range, drilling from a headline metric into the cohort underneath. A static PDF board pack answers exactly one question and spawns three follow-up emails; a live model answers the follow-ups before they're sent. With ChatGPT past 900 million weekly active users and AI now embedded in day-to-day business work at most organizations, your clients have already seen interactive AI-built output and quietly reset what "a good deliverable" looks like.

The reason this matters for how you share is that interactive delivery raises a question a PDF let you dodge: the moment your work is a live app instead of a flat file, who-saw-it / can-you-prove-it / can-you-end-it stops being optional. That's not a reason to retreat to PDFs — it's a reason to get the sharing layer right so you can lean all the way into interactive work. The context around it only sharpens the point: 77% of employees paste data into GenAI tools, 82% of that from unmanaged personal accounts (LayerX, 2025), and GenAI-related data-policy violations more than doubled year over year (Netskope, 2026) — the volume of confidential, AI-built material moving between parties is only climbing, and 88% of organizations now use AI in at least one business function (McKinsey, Nov 2025). The practitioners who win send the living deliverable and stay the gatekeeper. Peony is the data room used by 5,900+ customers precisely because it lets you do both at once — own the exported file, render it live, and keep control — instead of choosing.

Frequently asked questions

I built a scenario model in ChatGPT for a client's board meeting — should I send it as a live link or export it to PDF?

Send it live if the value is in the interaction, and for a scenario model it almost always is — the whole reason you built it in ChatGPT was so the board could change an assumption and watch the output move. Export it to PDF and you've shipped a photograph of a calculator: the inputs die, the board sees one frozen scenario, and the CEO comes back with "can you re-run it at a 15% haircut?" — the exact friction you were trying to remove. But live and controlled are not a trade-off you have to choose between. The mistake is thinking you flatten it to make it safe; you don't, because a login-walled or public link is still a copy outside your control. Keep it live and wrap it in control instead: a per-viewer watermark, an NDA gate, one tracked link per board member, and instant revoke after the meeting. On Peony, a data room used by 5,900+ customers, an exported .html app renders natively with its JavaScript executing inside that control layer, so the model stays interactive and every viewer is accountable.

Is it safe to put a client's confidential financials in a ChatGPT canvas share link?

For confidential client financials, no — not on the native share link alone. A ChatGPT canvas share link does one thing genuinely well: it keeps the document or code visible to the recipient. But it has none of the controls a board deliverable needs. There's no NDA gate, no per-viewer watermark, no expiry, no password, no view analytics, and no per-recipient link — so you can't prove who opened the client's numbers, you can't tie a leak to a person, and you can't cleanly pull access when the engagement ends. There's a specific trap, too: deleting the underlying chat does not kill an existing share link — you have to delete the shared link itself in settings (Bitdefender documented this in 2025). And the line between "shared" and "public" on consumer AI tools is thinner than it looks: in mid-2025 OpenAI briefly shipped a "make this chat discoverable" toggle and roughly 4,500 shared conversations ended up indexed by Google before OpenAI pulled it. Canvas links were never search-indexed by default, but the episode shows how fast a consumer share surface can leak. For client financials, keep the deliverable live but put it behind a control layer — an NDA gate, a tracked link per viewer, a dynamic watermark, and a revoke button.

How do I share a ChatGPT canvas with a board member who doesn't have a ChatGPT account?

You mostly can't, natively — and that's the single biggest gap. In practice, a ChatGPT canvas share link requires the recipient to be signed in to a ChatGPT account to view it — and for Business and workspace shares it's explicit: someone outside the workspace can't see it at all. So the board member without ChatGPT — which, on most boards, is most of them — clicks your link and hits a login wall instead of your model. (This is the opposite of Anthropic's public Claude publish link, which anyone can open in a browser; if you're choosing where to build, that difference matters, and we cover it in building in Claude instead.) The fix that works for any recipient is to stop sharing the ChatGPT surface and share the exported file: ask ChatGPT to rewrite the app as one self-contained .html file, download it, and host it somewhere that renders it live and doesn't require the viewer to hold an account. On Peony, that exported .html renders natively with its JavaScript executing behind a link anyone you invite can open — no ChatGPT account required — while still carrying a per-viewer watermark and access controls.

Do ChatGPT share links expire — and what happens to my canvas now that OpenAI is retiring Canvas?

Native ChatGPT share links don't expire on a schedule you set — there's no built-in expiry control, so a link stays live until you manually delete it in settings (and deleting the chat doesn't do it for you). The bigger issue in 2026 is the surface itself. OpenAI removed Canvas from its current models in late May 2026, replacing it with inline "writing blocks" and "code blocks" in the chat thread; Canvas is now reachable only through legacy models, and those are retiring too (GPT-4.5 retired in June 2026; o3 retires in August 2026). Users are protesting the change, but the strategic lesson is clear: a client deliverable that lives on the vendor's editing surface can be changed or retired out from under you. That's the whole argument of this post — own the exported file, not the surface. Export the app as a self-contained .html, and it keeps working in any browser no matter what OpenAI does to the Canvas UI. On Peony, that exported file renders live with instant revoke and link expiry built in, so the controls you can't get natively — a real ending, a real audit — come with it.

How do I turn a ChatGPT code canvas into a link my client can open in a normal browser?

Get the app out as one self-contained file, then host that file behind a link — don't rely on the canvas share link, which needs a ChatGPT account. There's no one-click self-contained .html export in ChatGPT (the download button gives you a .py/.js/.docx/.md, not a runnable single-file app), so the reliable move is a prompt: ask ChatGPT to rewrite the whole thing as one .html file with the CSS and JavaScript inlined, and any React converted to vanilla JS or loaded from a CDN. Download that file, double-click it to confirm it opens and runs in your local browser, and you now hold a portable app that doesn't depend on ChatGPT at all. Then upload it somewhere that renders HTML live. On Peony, that .html renders natively with the JavaScript executing, so your client opens a normal browser link and drives the real app — no account, no install — while you keep a per-viewer watermark, analytics, and revoke around it.

Should I deploy the React app ChatGPT built for me to Vercel or Netlify, or use a sharing platform with access control?

Deploy to Vercel or Netlify for a public portfolio piece; use a controlled sharing platform for a confidential client deliverable. Credit where it's due: Vercel and Netlify are excellent and free for the technical path, and if you're showing off a demo you'd happily post publicly, they're the right call. But the default deployment is a public URL with no access control, no per-viewer identity, and no analytics you can act on — and you now own DNS, builds, and maintenance for what was supposed to be a one-off board deliverable. Client financials sitting on a public hobby-tier URL is also a professionalism problem, not just a security one. Vercel vs Netlify barely matters here; public-vs-controlled is the real fork. If the app carries a client's private numbers, put the exported .html on a platform that renders it live behind a login-free-for-invitees link with a watermark and revoke. On Peony that's the Data Room plan at $52/month — you get the live render plus per-viewer control without running your own infrastructure.

How do I see who opened the model I sent to the board — and cut access after the meeting?

Send one tracked link per board member and read the page-level analytics; when the meeting's over, revoke the links. A single shared URL is anonymous by construction — five people can open it and you learn nothing about any of them. One tracked link per recipient flips that: every open ties to a named person, and page-level analytics show you who opened the model, when, how long they stayed, and which screens they lingered on — genuinely useful before a board meeting, because the director who reopened your runway tab three times is telling you something the one who never clicked is not. Cutting access is the other half. Because each viewer holds a permission, not a copy, you don't send a "please delete that file" email — you revoke the link and the model goes dark for them immediately, or you set the link to expire on board day so it closes itself. On Peony, page-level analytics and per-link tracking are on the Business plan at $30/month, and instant revoke plus link expiry are built in across plans. Analytics are page-level, not keystroke-level — you see which sections were viewed, not what anyone typed.

Can board members forward my link — and if someone screenshots the model, can I tell who leaked it?

A raw share link can be forwarded to anyone; a per-viewer tracked link can't be usefully forwarded, and a screenshot of a watermarked render points back at the leaker. Take them in order. A native canvas link (or a public URL) is a bearer link — whoever holds it can pass it on, and on the ChatGPT side the recipient can even fork their own copy via "Edit with ChatGPT," which means they walk away with a fork of it in their own account, outside your gate. A tracked link bound to one named viewer removes the anonymous-forward problem: access is tied to a person, not floating in a URL. On the screenshot question, be precise about what's possible: no tool can stop someone 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: the viewer's email, IP, and a timestamp are burned onto the live render, so a screenshot or phone photo carries that identity with it. On Peony, dynamic per-viewer watermarks are on the Data Room plan at $52/month; desktop screenshot protection is on Business at $30/month, and Screenshield blocks screen capture and recording on supported mobile devices on the Data Room plan. That's attribution and deterrence, not magic prevention.

Should I put an NDA in front of a board deliverable, or is that overkill for five people?

If the deliverable exposes real client financials, an NDA gate is cheap insurance, not overkill — and "only five people" is often exactly the room where a leak is most damaging. The distinction that matters is what the gate does. A Simple NDA (acknowledge-to-enter) makes each viewer click to accept a confidentiality notice before the model renders — light friction, useful when everyone's already under a master agreement and you want a logged acknowledgement. An Advanced NDA captures an actual signed PDF before access, which you want for an outside observer, a prospective investor, or anyone not already bound. Either way the pattern is the same: the viewer hits the gate on the tracked link, accepts or signs, and only then does the live app load — so confidentiality is enforced before a single number is visible, not requested in an email afterward. On Peony, a Simple NDA is on the Business plan at $30/month and an Advanced NDA (signed PDF) is on the Data Room plan at $52/month. For five board members looking at a client's private numbers, the acknowledge-to-enter gate is usually the right, proportionate call.

Is it normal for a fractional CFO to send interactive deliverables instead of PDFs?

Yes — increasingly it's the expectation, not the exception, and it's a differentiator when you do it well. Boards and CEOs have gotten used to driving the numbers themselves: flipping a scenario, stretching a date range, drilling from a headline metric into the cohort underneath. A static PDF board pack answers one question and generates three follow-up emails; a live model answers the follow-ups before they're asked. With ChatGPT past 900 million weekly active users and AI now used in a business function at the vast majority of organizations, clients have seen interactive, AI-built work and quietly recalibrated what "a good deliverable" looks like. The catch — and the reason a lot of consultants stall here — is that sending interactive work raises the control question a PDF let you ignore: who opened it, can they forward it, when does access end. Get that part right and interactive delivery is pure upside. On Peony, a data room used by 5,900+ customers, the whole point is that you can send the live deliverable and stay the gatekeeper at the same time, so "more interactive" doesn't have to mean "less control."

What's the cheapest way to share an interactive client deliverable securely — is a data room overkill for a solo practice?

The cheapest secure way is a purpose-built sharing tool at roughly $30–$52/month, and no, a data room is not overkill for a solo practice — modern ones are priced for exactly this. For a solo fractional CFO, the honest options are: a document-and-deck tool like DocSend (great for a PDF board deck with tracking, but running an interactive HTML app isn't its job — wrong tool for a live model); Papermark, the one other vendor thinking seriously about AI-built artifacts, with agent and MCP positioning and an open-source core, a legitimate alternative worth a look; or a data room that renders the live app under per-viewer control. On Peony, the Business plan is $30/month (page-level analytics, tracked links, Simple NDA, desktop screenshot protection) and the Data Room plan is $52/month (the live HTML render with dynamic per-viewer watermarks, Advanced signed-PDF NDA, Screenshield mobile capture blocking, granular permissions). Against a $10K-plus engagement, $52/month is a rounding error — and you explicitly do not need the Enterprise tier just to render the model live and watermark it per viewer. That's the $52 Data Room tier, full stop.

Related resources

• How to securely share a Claude artifact — the Anthropic-side sibling: the same live-render-plus-per-viewer-control pattern, but Claude's publish link is public (no account wall), which changes the tradeoffs
• Best tools to securely share a Claude or GPT artifact: Peony vs ShareDuo vs Stacktree vs LiveSend — comparing the tools rather than following one method? The honest head-to-head.
• How to share an interactive board report with your directors (securely) — the executive-to-board version of this same keep-it-live-or-flatten-it problem
• How to send a live dashboard to a client securely — the consultant-to-client version of the same workflow
• How to share an interactive financial model with an investor (securely) — the fundraising version: one live model to a VC under per-viewer control
• Dynamic per-viewer watermarks: the deeper guide — how attribution-by-watermark actually works
• AI in the data room: should you connect ChatGPT to your documents? — the strategic complement to this mechanics-level post
• Supported file formats — how Peony renders HTML natively
• Dynamic per-viewer watermarks
• NDA and confidentiality gating
• Page-level analytics and tracked links
• Instant revoke and link expiry
• Pricing — find the tier that renders HTML live

---

Sources

1. TechCrunch, "ChatGPT reaches 900M weekly active users" (Feb 2026). techcrunch.com
2. OpenAI, "1 million businesses putting AI to work" — over 1M business customers, 7M+ ChatGPT for Work seats (Nov 2025). openai.com
3. OpenAI Community, feature request: "Bring Canvas back to current ChatGPT models" (Jul 2026). community.openai.com
4. Bitdefender, "Your shared ChatGPT chats may be publicly searchable — here's how to delete them" (2025) — deleting the chat does not delete an existing share link. bitdefender.com
5. TechCrunch, "Your public ChatGPT queries are getting indexed by Google" (Jul 2025) and Fortune, on OpenAI removing the discoverability feature (Aug 2025). techcrunch.com · fortune.com
6. Netskope, Cloud & Threat Report 2026 — GenAI-related data-policy violations more than doubled year over year. netskope.com
7. LayerX — 77% of employees paste data into GenAI tools, 82% of that from unmanaged personal accounts (Enterprise AI & SaaS Data Security Report, 2025); GenAI is the single largest corporate-to-personal data-exfiltration channel, at 32% of all such data movement (2025). layerxsecurity.com · layerxsecurity.com
8. IBM, Cost of a Data Breach Report 2025 — 97% of organizations with an AI-related breach lacked proper AI access controls. newsroom.ibm.com
9. McKinsey, "The State of AI" — 88% of organizations use AI in at least one business function (Nov 2025). mckinsey.com
10. Peony product documentation — native HTML rendering, dynamic per-viewer watermarks, NDA/confidentiality gating, granular permissions, page-level analytics, instant revoke, link expiry, and the publicly available MCP server. peony.ink

Disclaimer: This article is for general informational purposes and is not legal advice; confirm confidentiality, NDA, and client data-handling requirements for your engagement and jurisdiction with qualified counsel.