How to Publish a React Component as a Web Page

To publish a React component as a web page, upload the .tsx or .jsx file itself. If it has a default export, SnapHost compiles it when you publish, bundles the libraries it imports, generates the Tailwind styles it uses, and gives you one link that opens as a working page. No build step, no project folder, no deploy.

That is the whole answer. The rest of this post is about the file you actually have, which is usually a component an AI wrote in a chat, and the handful of things that decide whether it becomes a page in one try or comes back with a refusal you need to act on.

Why you have a React component and not a website

You asked Claude for a dashboard, or ChatGPT for a calculator, or v0 for a landing page, and what came back was a single file: a Claude artifact, a canvas, an export. It ran fine inside the chat. Then you tried to show it to someone and discovered that the file is not a website. It is one component, written in a language browsers do not read directly, importing libraries that are not in the file.

The developer answer is to create a project, install the dependencies, run a build, and put the output on a host. If you are a developer with an afternoon, that works. If you are the person who asked the AI in the first place because you did not want to do any of that, it is exactly the wall you were trying to avoid.

The question worth asking is whether you can hand over the one file you have and get a link. For most components that come out of a chat, you can.

What happens when you publish the file

SnapHost reads a single .tsx or .jsx with a default export as a React component. On publish it does three things the chat did for you invisibly.

• It compiles the file, so the TypeScript and JSX become something a browser runs.
• It bundles in the libraries the component imports, at one pinned version each, so the page carries its own copy and loads nothing from anywhere else.
• It generates the Tailwind utilities the component's class names ask for. Most AI-written components use Tailwind classes, and without this step the page would come out unstyled.

The result is a page that holds everything it needs. A reader opens the link and sees the component running, on a laptop or a phone, with nothing to install. The full list of what SnapHost takes, from HTML to Word files to notebooks, is in what you can publish.

A file without a default export is treated differently. It is shown as a code listing with line numbers, the same as any other source file, because there is nothing to mount. If your page came out as code instead of a running component, that is the first thing to check: the file needs an export default.

Which imports work

This is the part most likely to decide the outcome, so it is worth knowing before you publish rather than after. A component may import these libraries:

• react and react-dom
• recharts, for charts
• lucide-react, for icons
• d3
• framer-motion, for animation
• the @radix-ui/react-* primitives, for dialogs, menus, tabs and the rest

Look at the import lines at the top of your file before you publish. If each one is on this list, the imports are not what will stop it.

Anything outside the list is refused, and the refusal names the import. The same goes for an import of another file sitting beside the component: there is no "beside" when you upload one file. The practical fix is to paste the refusal back to your AI and ask it to rewrite without that dependency, or to inline the second file into the first.

The reason for the fixed list is the same reason the page loads nothing from the open internet. A published site cannot quietly pull in code or data from other places. The page you send to a client runs exactly the code that was compiled when you published, and nothing that arrives later. If a component genuinely needs to call an outside API, that is a setting you turn on for a specific source, and it is a paid capability.

The limits, and what they mean in practice

A component may be up to 512 KB of source, and it may build to at most 4 MB of script. Past either, the publish is refused and says so.

For a component an AI wrote in a conversation, neither limit is close. A long dashboard with several charts is a few tens of kilobytes of source. The build ceiling exists because of the libraries that get bundled in, not because of anything you write.

The honest limitation is a different one. One file is one page. A component that is really the entry point of a multi-page app, with routes and a folder of other components, does not fit this path. For that you build the app the normal way and publish the output as a zip, which SnapHost also takes and serves with working deep links.

It runs like a real app, inside a sandbox

A published component is not a screenshot or a preview. It runs. Buttons work, state updates, charts respond to hover. It also runs with the same isolation as every other SnapHost site: in a locked-down frame on its own origin, so one page cannot read another or reach your account.

That isolation has a useful side effect for interactive components. The page can use localStorage and IndexedDB, and what it stores is private to that one site. A settings panel that remembers a choice, a game that saves progress, a form that keeps a half-finished draft: these work with nothing configured. Two things to know, both in hosting interactive apps: storage is keyed to the address the site is viewed on, and service workers do not take effect yet.

A component becomes its page and has no separate download. Readers get the running page, not the source file, which is usually what you want when the audience is a client rather than a collaborator.

Deciding who can open it

The component is now a link. What is left is deciding who can open it. A SnapHost site is either restricted, so only the people you name can open it and each one confirms their email before any content loads, or open to anyone with the link.

On Free you can have up to 3 pages at a time, each private to up to 3 people, or public. A new site on Free is public unless you name people, so for anything you would not want found, add the names first and copy the link second. On Pro the default flips: a new site is private unless you open it, there is no cap on readers, you can let in a whole company by its domain in one line, and you can put a password or an end date on any page.

Two more controls matter once the link is out. Someone who is not on the list can ask for access, and approving the request adds them, so a forwarded link becomes a request you see rather than a view you do not. And every request, verification, view and denial is recorded, so you can tell whether the dashboard was opened before the meeting. The details are in sharing and access control.

If the component is a prototype and the audience is people you want feedback from, sharing an AI prototype for user testing covers how to run that round without exposing the prototype to everyone.

Updating it after people have the link

A component an AI wrote gets revised. You ask for one more chart, the AI hands you a new file, and now there is a new version of the thing you already sent. Upload the new file to the same site and the link stays the same. On Free that is the whole story: the next time your reader opens the link, they see the current version.

On Pro each update is also saved as a version, the ten most recent are kept, and you can roll back to an earlier one while keeping the link. That matters on the day the AI "improves" something it should not have and you notice after you published. If you want to review a build before anyone can see it, keep the site as a draft: nothing is reachable until you publish.

If your AI is connected to SnapHost, the upload step disappears too. You tell it to publish the component and it sends the file over itself, which works on Free. The same loop from a code editor is in publishing from Cursor without a deploy step.

When this is not the right path

Three cases, and in each one a different route fits better.

• The component imports a library that is not on the list and cannot be rewritten without it. Build the project yourself and publish the output as a zip.
• It is a multi-page app with a router and a folder of files. Same answer: build it, zip it, publish the bundle.
• The person on the other end wants to edit the code, not use the page. Send them the file. A page is for an audience, and that person is a collaborator.

For everything else, which is most of what comes out of a chat, the one file you already have is enough. Free covers a single component for a few named people. Pro is 19 euros a month for each member who can publish, and the people who open the page are free. Pricing has the current lines.