Share an HTML file with a client, as a link they just open.

Why not just email the file?

Because an emailed .html file is the worst version of your work. It arrives as an attachment the client has to download and open from their file system, where it renders as a local file rather than a page. Gmail caps attachments at 25 MB, which self-contained AI-generated files bump into surprisingly often. And security tooling is right to be suspicious: HTML attachments are a documented malware-delivery technique, so your deliverable competes with phishing for the benefit of the doubt. A link has none of these problems.

Chat is no better. Paste HTML into Slack and you get a code block; attach it and the client still ends up downloading a file. If the work is a page, the client should receive a page.

How do I share large HTML files?

This is the question that sends people hunting, usually right after a mail server bounces the attachment. The answer is to stop moving the file and start moving a link. Upload once (drag and drop, one API call, or one MCP tool call from the agent that wrote it) and the size problem ends at your side of the wire. The client's browser fetches the page from a CDN the same way it fetches any website, whether the file is 40 KB or 40 MB.

Send it without making it public

Private by default means the URL itself is the first gate: an unguessable token, no public gallery, no directory, no sitemap entry, crawlers opted out. Nobody finds the page by searching; only the people you send it to know it exists. That is private HTML hosting in practice, and it is the property the publish buttons built into AI tools do not offer, because their links are designed for the opposite job.

Share with a client without a login

When "anyone with the link" is not tight enough, add a gate. Neither one requires the client to have or create an account:

• Password. You set a passcode and tell the client. Forwarding the link alone opens nothing.
• Email-domain gate. You allow @yourclient.com. A viewer enters their work email, clicks a one-time magic link, and reads for 24 hours per verification. Forward the URL outside the company and it stops at the gate.

Passcodes are on every plan, Free included, and never metered. Email-domain gates start on Solo at $19 a month, alongside permanent pages and your own domain. Gated pages also unfurl in Slack and Teams as a locked graphic that leaks no title and no description, so even the preview of a confidential deliverable stays quiet.

Either gate can also sit on a whole client space rather than one page, so everything you publish for that client inherits it. The client types the passcode once for the lot and stays in for 30 days, and what they see is a styled page rather than the browser’s grey password box. A gate set on an individual page overrides the space’s.

One link per recipient: expire it, cap it, revoke it

For handoffs with more than one stakeholder, mint each person a signed share link on top of the same page: label it ("CFO", "legal review"), give it its own expiry, cap how many times it can be opened, and revoke it individually if a thread leaks. The underlying page and everyone else's links are untouched. Share links are free on every plan.

For the genuinely sensitive file

• Burn-after-read deletes the page after the first view. One open, then gone.
• Expiry scheduling ends the link on a date you pick, so a preview never outlives the engagement.
• End-to-end encryption encrypts the page in your browser with AES-GCM; the key rides in the URL fragment and never reaches the server, so the host cannot read what it stores. Free, no plan gate.
• A pre-flight scan checks the file for API keys, emails, and card numbers before it goes live, and blocks by default when an agent publishes over MCP. What it catches and why the agent path blocks.

Did they actually read it?

Sending is half the job; the other half is knowing it landed. Every plan carries the reactions and notes viewers leave anchored to specific parts of the page, which flow back to the agent that built it. Solo adds the numbers: opens, unique viewers, and when it was last read. Studio adds "How it's read": time on page, scroll depth, read-to-end rate, and a dwell heatmap, aggregate and anonymous rather than surveillance.

When the file is a demo or a report

The same handoff carries whatever the HTML actually is. If it is a build the client should click through before the meeting, host it as a private client demo site: one gated link instead of a staging server, updated in place as the build moves. If it is the monthly numbers, send the client report as a link they bookmark once, the same URL every month. Both sit behind the same gates as a single file.

Publish straight from the agent that made it

Most HTML files that need to reach a client were written by an AI five minutes earlier. Skip the export-and-upload step: Claude Code, Claude.ai (one-click OAuth connector), Codex, Cursor, and any MCP client can publish the file directly with publish_html and return the private link in the same conversation. Revisions go through update_site, so the link you sent on Monday shows Thursday's version without a resend. Prefer hands-on? Drag the file onto the dashboard instead.

Three finishing touches for client work: if the page arrived plain (an export, an agent's output), the design pass rebuilds it to Stacktree's design standard in about a minute, same content, same link. Paid plans render no Stacktree badge on the page, and you can serve the link from your own domain. See custom domains for putting the deliverable on reports.yourco.com, client spaces for giving one client a permanent address that every file you send them lands behind, and pricing for what sits in each plan.