Private vs Unlisted: Pick the Right Visibility Before You Publish Generated HTML

Table of contents

1. Visibility is part of the handoff
2. Use private for owner-only iteration
3. Use unlisted for direct-link review
4. Where project links fit
5. What to tell your API or MCP workflow
6. Final checklist

Visibility is part of the handoff

Teams often treat visibility like a small publish setting. In practice, it changes the whole handoff.

The question is not only "can I publish this HTML?" It is "who should be able to open it next?"

For BinHTML artifacts, the default split is simple:

• private means the artifact stays owner-only
• unlisted means anyone with the link can open it

That is why visibility should be chosen before the agent publishes, not after the link has already been pasted into chat.

Use private for owner-only iteration

Choose private when the HTML is still being worked on and the next step is owner review, not outside sharing.

Typical cases:

• an agent generated a first draft and you want to inspect it before anyone else sees it
• the artifact may still contain sensitive details, rough numbers, or debugging output
• the workflow needs source inspection or cleanup before a share link exists

This is the right mode for early iteration because it keeps the artifact inside the owner account while the content is still moving.

Private visibility also matches the product model on /pricing: private sharing is part of Pro. If your workflow depends on owner-only artifact review before link-based sharing, confirm that plan up front instead of assuming every workspace can use the same publish path.

The rendering model does not change: generated HTML still belongs in a sandboxed viewer, not as a raw attachment or a first-party website. MDN's iframe sandbox guidance is a useful baseline for why untrusted HTML needs that boundary.

Use unlisted for direct-link review

Choose unlisted when the point of publishing is to hand somebody a URL they can actually open.

Typical cases:

• you need feedback from a teammate, stakeholder, or customer
• an agent should return one review link at the end of a run
• a CI or scheduled workflow publishes a report for a small audience

This is the correct mode when link possession is the access model. That is powerful, but it also means the link should be treated carefully. Anyone who gets the URL can open it, so the right follow-up controls are expiry, revocation, and disciplined sharing. If you want the operational checklist, start with Expiry and Revocation: Make Unlisted HTML Links Safe to Share and Prevent Unlisted Share Links Leaking via Referrers and Logs.

Unlisted links also fit BinHTML's indexing stance. Shared artifact and project pages are meant for direct collaboration, not search discovery. If you are thinking in web-page terms, that is the wrong mental model. Think controlled handoff link instead.

Where project links fit

Project links are a separate decision from artifact visibility, but they interact with it.

If the handoff is one artifact, choose between private and unlisted based on who needs access.

If the handoff is a bundle, BinHTML's project share flow gives you one unlisted project URL for the packet. That is important: project sharing is a link-sharing workflow, not an owner-only private workspace surface. If the set is not ready to share yet, keep the underlying artifacts private until the packet is ready.

For the project-specific shape, see Project Share Pages: One URL for a Multi-Artifact Handoff.

What to tell your API or MCP workflow

BinHTML exposes visibility in both the API docs and the MCP docs, so the decision can be made explicitly at publish time.

A practical rule for automations is:

• publish as private when the next step is owner QA
• publish as unlisted when the next step is external or cross-team review
• do not ask the agent to guess which one you meant

Good prompt for an owner-only loop:

Good prompt for a shareable handoff:

That small instruction reduces the most common mistake: an agent returns a shareable URL when the artifact was still supposed to stay internal.

Final checklist

Before you publish, ask one question: should the next person need the owner account, or only the link?

Choose private when:

• the artifact is still under owner-only review
• the content may need cleanup before sharing
• the workflow depends on Pro private sharing

Choose unlisted when:

• the handoff needs a direct URL now
• the recipients are outside the owner account context
• you are ready to manage link lifecycle with expiry and revocation

Final thought: visibility is not a cosmetic setting. It decides whether BinHTML is acting like a private staging step or a review handoff step. Pick it deliberately, and the rest of the workflow gets much easier.