How to Share AI-Generated HTML With Clients

Table of contents

1. Why client review is a different job
2. Decide whether it is a website or an artifact
3. Publish one clean review link
4. Keep source access and visibility deliberate
5. Use a project link for multi-part client work
6. A client-ready handoff note
7. Final thought

Why client review is a different job

A developer can open a local .html file, inspect the source, and understand why a generated page behaves the way it does. A client usually should not have to do any of that. They need a link they can open in a browser, enough context to know what they are reviewing, and a way to compare feedback against the current version.

Recent search results and practitioner writeups around generated HTML keep circling the same practical problem: AI tools can produce useful pages, prototypes, reports, and small tools quickly, but the last step becomes awkward when the recipient is a boss, client, or non-technical reviewer. Sending code asks the reviewer to run something. Sending a file often creates download friction. Deploying every generated page as a website gives a short-lived review artifact more operational weight than it deserves.

That is the gap a BinHTML artifact link is meant to cover. For the broader product model, start with the complete guide to publishing AI-generated HTML.

Decide whether it is a website or an artifact

Before you share anything, make the lifecycle decision.

Use a website deployment workflow when the output needs:

• a production domain
• long-term public discovery
• multiple routes or server-side behavior
• analytics, authentication, databases, or environment variables
• a repository-owned release process

Use an artifact workflow when the output is a generated deliverable for review:

• a client-facing concept page
• a one-off report or explainer
• a proposal appendix
• a dashboard snapshot
• a prototype option that may be replaced after feedback

The distinction matters because clients read links as signals. A public website URL can look like a maintained product surface. A managed artifact link can be framed honestly as a review object: here is the generated page, here is what to check, and here is how long the link should remain useful.

If your team is still comparing artifact links with static hosts, the /compare pages give you language for that decision.

Publish one clean review link

The client should receive one primary URL. If the HTML came from ChatGPT, Claude, Codex, Cursor, Windsurf, a script, or another agent, publish the complete document and return the share link.

With the BinHTML API, an automation can send a title, optional description, visibility, expiry, project name, and complete sourceHtml. The response includes the share URL the workflow should hand back to the user.

With BinHTML MCP, an agent can do the same inside an MCP-capable workflow. That is useful when the same agent is generating the page, naming it, deciding whether it belongs in a project, and writing the final client note.

A good artifact title should survive forwarding. Avoid index.html, client page, or final. Use the name a reviewer would search for later:

• Q3 onboarding dashboard preview
• Homepage concept B - pricing-led variant
• Client renewal risk explainer

Keep source access and visibility deliberate

Client review should separate rendered access from owner controls.

The client usually needs the rendered page. The owner may also need the source HTML, dashboard management URL, version history, and revocation controls. Do not put every management link into the client message by default.

Before sharing, check four settings:

• **Visibility:** use unlisted when a direct review link is enough; use private when the artifact should stay owner-only.
• **Expiry:** set an expiry date when the review is tied to a proposal, approval window, or short-lived decision.
• **Sandboxing:** generated HTML can include scripts, forms, links, and external assets, so it should render inside a controlled viewer rather than being treated like a trusted local file.
• **Indexing:** client review links should usually be direct-link surfaces, not search-result surfaces. BinHTML artifact and project share pages are noindex by default.

Sandboxing and noindex are not magic security claims. They are review hygiene. The owner still needs to remove secrets, customer data, credentials, private URLs, and unnecessary external scripts before publishing.

For a deeper pre-share pass, use Run a Link Preflight Before Sharing Generated HTML and Scan and Redact Secrets Before You Publish HTML Artifacts.

Use a project link for multi-part client work

One artifact link is right for one generated page. A project link is better when the client needs to review a set.

Common client packets include:

• three landing page concepts
• a summary page plus an appendix
• a dashboard plus methodology notes
• before-and-after versions of a generated report
• a proposal explainer plus source references

A pile of separate links creates unnecessary review work. A BinHTML project can group related artifacts in the dashboard, and project sharing can give the client one unlisted project index while each artifact remains separately inspectable.

For more detail, read Project Share Pages: One URL for a Multi-Artifact Handoff.

A client-ready handoff note

The final note should be short and specific. Do not paste the HTML source. Do not bury the link under implementation detail. Tell the client what the artifact is, what to review, and whether the link is time-bound.

Example:

```text

Here is the generated homepage concept for review:

https://binhtml.com/a/example-slug

Please check the headline, offer clarity, and section order. The link is unlisted and intended for review only. I will update the same artifact after feedback so the URL stays stable.

`

For multi-part work, make the project link the first URL and list the expected review path:

```text

Here is the project link with three generated concept pages:

https://binhtml.com/p/example-project

Please start with the summary artifact, then compare concepts A, B, and C. I am looking for a direction decision, not final copy edits yet.

`

That small bit of structure prevents the common failure mode: the client opens the page, likes or dislikes something, and nobody knows which version or decision they are responding to.

Final thought

Client-facing generated HTML should feel simple to review and easy to retire. Publish the artifact, send one link, keep source and management controls with the owner, and make the review ask explicit. That gives the client a normal browser experience without pretending every generated page is a production website.