What if I just need to share with one person?

The free tier supports one-time password authentication — the viewer enters their email and receives a one-time login link. No SSO required. This works for sharing with a single collaborator or a small group.

Can I use gated publishing without the CLI?

Yes. The Display web UI has a drag-and-drop uploader. Drop your HTML file, get a URL. The CLI is faster (one command) and scriptable (works in CI/CD pipelines), but it's not required.

Does this work for Markdown files too?

Yes. Display renders Markdown to HTML and serves it at a permanent URL. Useful for sharing documentation, specs, and READMEs with non-technical stakeholders who don't have GitHub access.

The 7 Ways Engineers Share HTML Files With Their Team (And Why 6 Fail)

An HTML file with inline JavaScript, CSS, and interactive charts is not a document. It's an application. The same properties that make it valuable — interactivity, responsive layout, live data, animations — make it fragile to share.

Every workaround that treats it as a file destroys what makes it an artifact. When you screenshot it, you get a static image of an interactive thing. When you upload it to Slack, you get a download button. When you paste it into Google Docs, you get a broken skeleton.

There are seven methods engineers reach for. Here's exactly what happens with each.

Method 1 — Screenshot to Slack

What happens: You take a screenshot of the HTML page and drop it in Slack. Your D3 chart is now a JPEG. The architecture diagram that animates on hover is frozen. The sortable table can't be sorted. The tabs can't be clicked.

Who does this: Everyone, because it takes 10 seconds and Slack handles images natively.

The cost: The work product is permanently degraded. The interactive architecture proposal becomes a flat screenshot. Time saved sharing: 10 seconds. Value destroyed: everything that made it worth building.

When it's acceptable: Genuinely never for anything interactive. If the artifact is purely visual with no interactivity, a screenshot is defensible. For everything else, it's a loss.

Method 2 — Upload HTML file to Slack

What happens: You drag presentation.html into a Slack channel. Slack displays a paperclip icon and a download button. The recipient clicks "Download." The file lands in their Downloads folder. They double-click it. It opens in TextEdit showing <!DOCTYPE html><html><head>.... They close it.

Who does this: Engineers who know screenshots are wrong and want to send the actual file.

The cost: Zero recipients successfully view the artifact. The browser can technically open a local HTML file, but most users don't know to drag it into the browser address bar, and relative paths break anyway when files are opened locally.

Slack's position: Slack is a messaging platform. It was never designed to serve HTML. This isn't a gap Slack is likely to fill.

What happens: You print the HTML page to PDF. The layout renders, mostly. The D3 charts are frozen at their initial state. Tabs are gone — you get whichever tab was active when you printed. Animations, hover states, dynamic data: all absent. You get a static snapshot of one moment in time.

Who does this: PMs trying to help, and engineers who accept medium fidelity.

The cost: Medium fidelity. Better than a screenshot because the layout usually holds. Still broken because the interactivity is entirely absent. And there's still no persistent URL — the PDF gets attached to a Slack message and buried.

Time cost: 30–60 seconds to export. Permanent loss of interactive value.

Method 4 — Paste into Google Docs

What happens: You open the HTML file in a browser, select all, copy. You paste into a Google Doc. Docs strips every HTML tag, collapses the CSS, and removes all JavaScript. You get a wall of unstyled text with broken formatting. Manual reconstruction of tables, headers, and structure takes 30–45 minutes — and even then, you can't reconstruct charts or interactive elements.

Who does this: People who default to Google Docs for everything and assume it handles all content types.

The cost: 30–45 minutes of manual reformatting. The result is still static. The artifact's interactivity cannot be recovered by any amount of editing in Docs.

The fundamental problem: Google Docs is a word processor. It edits documents. It cannot run JavaScript. These are different tools for different jobs.

Method 5 — Use Claude's "Publish" button

What happens: If you're working in Claude's web UI (not Claude Code), there's a Publish button on artifacts. Clicking it creates a public URL on claude.ai/public/artifacts/{uuid}. Anyone on the internet with that URL can view it.

Who does this: Claude users who discover the button and want a real URL.

The cost: The URL is fully public. There is no way to restrict it to your company's domain. For anything internal — competitive analyses, architecture proposals, financial data, client information — a publicly accessible URL violates basic information security hygiene. "Obscure URL" is not access control.

The additional problem: The Publish button only exists in Claude's web UI. Claude Code (the CLI) writes HTML to disk and has no built-in publish step. If you're using Claude Code — which is where most AI-generated HTML comes from — this option doesn't exist.

Method 6 — Deploy to GitHub Pages

What happens: You push the HTML to a gh-pages branch, configure GitHub Pages, and get a URL. For public repos, anyone can see it. For private repos, viewers need a GitHub account — and not just any GitHub account. Private GitHub Pages requires GitHub Enterprise Cloud at $21/user/month.

Who does this: Developers comfortable with git who need a real, browsable URL.

The cost:

For public repos: the URL is public. Same problem as Claude's Publish button.
For private repos: Enterprise Cloud at $21/user/month. Your 100 teammates cost $2,100/month. And every viewer — PM, VP, legal, sales — needs a GitHub account. Most of them don't have one, and getting them to create one for this is a support ticket waiting to happen.
Setup time: 5–30 minutes for the first artifact, depending on existing repo structure.

When it works: Engineering-only audiences where everyone has GitHub, public repos, or teams already on Enterprise Cloud where the cost is sunk. That's a narrow set.

Method 7 — Gated publishing ✓

What happens: dsp publish ./presentation.html → permanent authenticated URL in 15 seconds.

Your teammates click the URL. They authenticate with their company Google or Microsoft email — one time, five seconds. They see the full interactive artifact: charts, animations, tabs, hover states, everything.

No accounts for viewers to create. No GitHub required. No enterprise contract. No IT ticket.

The cost: $49/month flat, unlimited viewers. Free tier available with one-time password authentication.

Setup time: 15 seconds for the first publish. CLI installation takes two minutes once.

For non-technical teammates: Configure Claude Desktop MCP once. Then PMs and analysts can say "publish this to my team" in any Claude conversation and get a company-gated URL back — no terminal required.

The comparison

Method	Interactivity preserved	Viewer needs account	Persistent URL	Time to share	Cost
Screenshot	❌	—	❌	10 sec	$0
Slack upload	❌ (doesn't render)	—	❌	10 sec	$0
PDF export	❌	—	❌	30 sec	$0
Google Docs paste	❌	Google account	❌	30–45 min	$0
Claude Publish	✅	❌ (public URL)	⚠️ unstable	5 sec	$0
GitHub Pages	✅	GitHub + Enterprise	✅	5–30 min	$2,100/mo
Gated publishing	✅	Company email (1x)	✅	15 sec	$49/mo

The six failing methods each make the same mistake: they treat an HTML application as a file to transfer, or they solve the rendering problem while breaking the access model (public URL), or they solve the access model while creating an account requirement that excludes half your audience.

Gated publishing solves all three: it serves the rendered page, behind company identity, accessible to anyone with a company email.

Try gated publishing — free tier, no credit card →

FAQ