# How to share a ChatGPT Site with a client · Stacktree Source: https://stacktr.ee/blog/share-chatgpt-site-with-client [Skip to content](#main) [Stacktree](/)[Developers](/developers)[Agents](/agents)[Docs](/docs)[Use cases](/use-cases)[Pricing](/pricing)[Blog](/blog)[Dashboard](https://app.stacktr.ee)[Sign in →](https://app.stacktr.ee) By [ Steve Smith ](/about) · Founder, Stacktree · Last updated September 11, 2026 # How to share a ChatGPT Site with a client Private sharing shipped on 11 September 2026, and it answers half of this question. A named client outside your company can now be invited by email without the Site going public. The other half is unchanged: they open it by signing in with a ChatGPT account, and there is still no passcode, no email-domain gate, and no link that works on its own. [ Get started free ](https://app.stacktr.ee/?join=1&from=seo_blog_share_chatgpt_site_with_client) install npx stacktree-install Copy No card · 3 pages free · about a minute ## Can you share a ChatGPT Site privately with a client? Yes, by invitation, since September 2026: add the client's email address as a named external viewer and the Site stays private and view-only. But every private option is an identity check. The invited client must sign in with the ChatGPT account on that address, so a client with no ChatGPT account is still reachable only by publishing publicly. There is no passcode, no email-domain gate, and no expiring link. ## On this page - 01 [ The four options, and what each costs ](#options) - 02 [ What collaboration and private sharing added ](#collaboration) - 03 [ The four workarounds ](#workarounds) - 04 [ When public is genuinely fine ](#public-ok) - 05 [ When you need a different tool ](#different-tool) ## The four options, and what each costs Straight from the documentation, a Site can be visible to owner and workspace admins only, to selected active users or groups and named external viewers, to anyone in the workspace, or to anyone on the internet when public publishing is enabled. Read those as two categories rather than four settings. The first three are the same mechanism with a widening list: the viewer proves who they are by signing in to a ChatGPT account you have named. The fourth removes the check entirely. For internal work that is a good model. For client work it half-fits. Since September the client no longer needs to join your workspace, but they do need a ChatGPT account on the invited address and the willingness to sign in to read a proposal. For a client who lives in ChatGPT that is nothing. For one who does not, you are asking them to do the admin so you can send them something. Worth noting what else falls on the wrong side of that line. In Enterprise workspaces, public publishing is off by default, custom domains are not available at launch, and analytics is not available for Enterprise-owned Sites. The organisations most likely to have external client relationships get the fewest of the tools for serving them. ## What collaboration and private sharing added On 20 August 2026 OpenAI added editors. The announcement: "Add teammates as editors to your ChatGPT Sites so you can build and publish together. Collaborators can push changes to the same project while Codex handles git management and CI behind the scenes." Three roles are documented. The owner controls audience settings, editor management, analytics, versioning and the first publish. An editor can open the site, make changes, save versions and publish updates once the owner has published once. A visitor gets read-only access to the live site. This is a real feature and it solves a real request. A month before it shipped: "ChatGPT sites are a great way to share and present work (as opposed to ppt or docs) but it still doesn't solve the collaboration aspect for me. Wish I could do it sites itself." Now you can. What it did not touch, at the time, was the audience. The docs qualified collaborators as "active members of the same workspace", so the new roles lived entirely inside the boundary that was already there. People noticed. Eight days before the launch: "ability to more than one more user using chatgpt Sites in Plus Plan. I only see option for Private or anyone with link." The next day: "why are these the only options for sharing chatgpt sites?" Both were accurate for three more weeks. On 11 September 2026 OpenAI added the audience half: "Share privately: invite specific people to a private Site without making it public." The help center flow is enter an email, save, and "ask them to open the Site while signed in with the account that received access". That answers the 12 August request for anyone willing to sign in. What it did not add is a gate without an identity: no passcode, no email-domain rule, no expiry, and no per-recipient link. [The private-sharing post](/blog/chatgpt-sites-private-sharing) walks through the mechanism and the replies. ## The four workarounds Publish publicly and rely on the URL. The most common choice, and the one most likely to be regretted. A public Site is on the open web: it can be indexed, forwarded, and read by anyone who ends up with the link. There is no expiry, and you cannot cut off one recipient without changing the address for everyone who has it. Invite the client by email. The new route, and the right one for a client who already uses ChatGPT. Private, view-only, revocable per person. The cost is the sign-in: the client needs a ChatGPT account on that address and has to be logged in to open the link, every time. That is a hurdle for a client who does not use ChatGPT, and a hard stop for a shared inbox or a procurement contact who will not create accounts. Add the client to your workspace. Technically correct and commercially awkward. It generally means a seat, an account your client did not ask for, and an onboarding conversation before they can read the thing you sent. For a one-off proposal it is more friction than the deliverable is worth. Take the work elsewhere. Community reports at launch described being able to export a Wrangler project of a Site for self-hosting on your own Cloudflare account, though that is still not in the documentation. Exporting solves the gate problem by leaving, at the cost of the thing that made Sites appealing: asking for a change in the chat and having the live page update. ## When public is genuinely fine Plenty of the time. A demo, a prototype you want feedback on, a public-facing microsite, a conference talk companion, a little game to send round. If you would not mind a stranger reading it, an unlisted public URL is a sensible control and Sites is an excellent way to produce one. The line is worth stating precisely, because the answer changes with the content rather than the audience. Pricing, scope, client data, anything under an NDA, anything with a named individual in it: those need a gate, not an unguessable string. A URL is a secret you cannot revoke, cannot expire, and cannot audit. ## When you need a different tool If the deliverable should reach one named person, without an account, and stop being readable later, you need a host whose access model starts from the link rather than from an identity provider. That is what a [publish primitive](/vibe-coding-hosting) does differently: the page is [private by default and shared with a link a client just opens](/share-html-file-with-client), a passcode or email-domain gate is one setting rather than a directory invitation, links expire, and each recipient can get their own link that can be revoked on its own without touching anyone else's. The useful part is that these are not competing answers to the same question. Sites is for building something, together now, and showing it to your workspace or to everyone. The other half of the category is for sending finished work to someone outside the building and knowing how it landed. If your job is client delivery, you will keep hitting the boundary described above, and no amount of collaboration features will move it, because it is a decision about identity rather than a missing setting. Fix it now You've read why the public link is a problem. Paste the artifact here and get a private one, no account, and a passcode if you want it. Paste HTMLDrop a fileno account · 24 h linkHTML to publishAdd a passwordPublish private link FAQ ## Frequent questions Can you share a ChatGPT Site with someone outside your workspace? + Yes, since September 2026, in two ways: publish it publicly, or invite them by email as a named external viewer, which keeps the Site private and view-only. The catch is that the second route requires the person to sign in with the ChatGPT account on the invited address. There is no passcode, no email-domain gate, and no unguessable private link in between. Did the September 2026 private-sharing update change this? + Partly. Collaborative editing (20 August) added teammates as editors inside the workspace. Private sharing (announced 11 September) added named outside viewers: enter an email, and that person can open the Site without it being public. Both are identity checks. The help center says "invited visitors must sign in with the account that received access", so a client without a ChatGPT account is still outside the door. Can you password protect a ChatGPT Site? + Not as documented. Access is controlled by workspace identity or by publishing publicly. A password or passcode that a recipient types without holding an account is not among the sharing options, and neither is an expiry date on the link. What do people do instead? + Four things, all with a cost. They publish publicly and rely on an unguessable URL, which puts the page on the open web. They invite the client by email, which means the client needs a ChatGPT account and has to sign in to read. They add the client to their workspace, which usually means a seat. Or they export the work and host it somewhere with its own gate, the only route that gives a private link a client opens with no account. Is a public URL with a random name private enough? + It depends what is on the page. An unlisted URL is a reasonable control for something you would not mind a stranger reading. It is not a control for pricing, client data, or anything under an NDA, because there is no gate, no expiry, and no way to revoke access for one recipient without changing the URL for everyone. Keep reading ## Related guides - [ ChatGPT Sites private sharing, explained The 11 September update: who can open an invited Site, and why they still sign in. ](/blog/chatgpt-sites-private-sharing) - [ ChatGPT Sites explained Cost, access, domains, privacy, and what is still undocumented. ](/blog/what-is-chatgpt-sites) - [ Share an HTML file with a client The account-free version: a private link, a passcode, an expiry. ](/share-html-file-with-client) - [ The private alternative When the deliverable should not be public at all. ](/openai-codex-sites-alternative) - [ Knowing how it landed Who opened it, how long they stayed, how far they read. ](/page-engagement) References ## Sources and further reading - [ Collaborative editing announcement (OpenAI Developers) ↗ The 20 August 2026 launch: teammates as editors, Codex handling git and CI behind the scenes. ](https://x.com/OpenAIDevs/status/2090515079058108745) - [ ChatGPT Sites update: 5M sites, private sharing, custom domains (@ChatGPT) ↗ The 11 September 2026 announcement: "Share privately: invite specific people to a private Site without making it public." ](https://x.com/ChatGPT/status/2098457920291946894) - [ OpenAI Help Center: Creating and managing ChatGPT Sites ↗ The invite flow for named external viewers and the line "Invited visitors must sign in with the account that received access." ](https://help.openai.com/en/articles/20001339-creating-and-managing-chatgpt-sites) - [ ChatGPT Sites documentation ↗ The primary source for the four sharing options, the owner/editor/visitor roles, and the "active members of the same workspace" requirement for editors. ](https://learn.chatgpt.com/docs/sites) - [ User feedback on sharing options ↗ 12 August 2026: "I only see option for Private or anyone with link", eight days before the collaboration launch. ](https://x.com/zshansyd/status/2087444665465549116) - [ The collaboration request, before the launch ↗ 31 July 2026: Sites as a way to present work, and the collaboration gap that editors have now closed. ](https://x.com/anukshi13/status/2083274843043271031) ## Send it to one client, not to everyone Private by default, a passcode they type without an account, an expiry, and a named link per recipient so you know who opened it. [ Sign up free → ](https://app.stacktr.ee/?join=1&from=cta_blog_share_chatgpt_site_with_client) install npx stacktree-install Copy Private hosting for the HTML your agents make. [](https://betalist.com/startups/stacktree?utm_campaign=badge-stacktree&utm_medium=badge&utm_source=badge-featured)[Featured on](https://devhunt.org/tool/stacktree)[](https://buildlist.io)[Get started free](https://app.stacktr.ee/?join=1) ## Product - [Templates](/templates) - [Example deliverables](/examples) - [Custom domains](/custom-domains) - [Client feedback](/client-feedback-loop) - [One-time links](/one-time-view-links) - [See how pages get read](/page-engagement) - [Made with Stacktree](/made-with) - [Security](/security) - [Watch the demo](/demo) ## Agents - [All integrations](/agents) - [Claude Code](/claude-code) - [OpenAI Codex](/codex) - [Cursor](/cursor) - [Claude.ai connector](/claude-ai-connector) - [MCP server](/mcp-publish-html) - [Deploy from Claude Code](/deploy-html-from-claude-code) - [Skills](/skills) - [Slack app](/slack) - [n8n node](/n8n) - [Agent payments (x402)](/x402) ## Alternatives - [All comparisons](/alternatives) - [Head-to-head comparisons](/compare) - [Tiiny Host](/tiiny-host-alternative) - [GitHub Pages (private)](/github-pages-private-alternative) - [Vercel](/vercel-alternative-for-agents) - [ngrok](/ngrok-alternative-for-html) - [Display.dev](/display-dev-alternative) - [Static.app](/static-app-alternative) - [OpenAI Codex Sites](/openai-codex-sites-alternative) - [here.now](/here-now-alternative) - [Shippage](/shippage-ai-alternative) - [Best private hosting](/best-private-html-hosting) ## Use cases - [All use cases](/use-cases) - [Share with clients](/share-with-clients) - [Send a file to a client](/share-html-file-with-client) - [Share Claude artifacts](/share-claude-artifacts) - [Share Jupyter notebooks](/share-jupyter-notebook-html) - [Host Storybook privately](/host-storybook-privately) - [Architecture diagrams](/share-architecture-diagrams) - [AI-generated reports](/host-ai-reports) - [Internal HTML tools](/internal-tool-hosting) - [Private HTML hosting](/private-html-hosting) - [Vibe-coded page hosting](/vibe-coding-hosting) - [Leave a website builder](/website-builder-migration) ## Learn - [Blog](/blog) - [Glossary](/glossary) - [FAQ](/faq) - [Agent-loop hosting](/agent-loop-hosting) - [Why agents need a publish primitive](/blog/why-agents-need-a-publish-primitive) - [MCP servers explained](/blog/mcp-servers-explained-for-developers) - [What changed in the 2026-07 MCP spec](/blog/mcp-2026-spec-changes) - [Sites in Codex explained](/blog/sites-in-codex-explained) - [Private-by-default hosting](/blog/private-by-default-html-hosting) - [An agent paid us $1 (x402)](/blog/agent-paid-to-provision-itself) - [When a loop hits a paywall](/blog/loop-engineering-paywall) - [Pricing](/pricing) - [Self-host (new)](/self-host) - [Changelog](/changelog) - [Docs](https://stacktr.ee/docs) - [About](/about) © 2026 Stacktree · stacktr.ee [Privacy](/privacy)[Terms](/terms)[Security](/security)[Dashboard](https://app.stacktr.ee)[npm](https://www.npmjs.com/package/stacktree-mcp)[Sitemap](/sitemap.xml)[llms.txt](/llms.txt)[API spec](/openapi.json) --- Full markdown summary of the Stacktree marketing surface: https://stacktr.ee/llms-full.txt