AI tools are very good at building and very bad at sharing. The page Claude drew, the app v0 generated, the site Lovable spun up: each one is real and working inside the editor, and then you try to send it to someone and hit a wall. The preview link asks them to log in. The project will not open on their account. The shared URL expires, or it only ever showed a snapshot, not the live thing. So most people give up and send a screenshot of the work instead of the work.
This guide fixes that last step for good. It covers what kind of thing each AI tool actually hands you, how to get a public link in under a minute, and, more useful than any of that, the specific reasons an AI build breaks when you move it off the editor and how to stop each one. Most articles on this stop at "upload your file." The breakage is where the real time goes, so that is where this goes deep.
First, know what kind of thing the AI built you
This one decision determines everything else, and it is the part most guides skip. AI tools produce three different kinds of output, and only the first two can go online as a simple link.
| What the AI gave you | Examples | Can you host it as a link? |
|---|---|---|
| A single HTML page | Claude artifact, ChatGPT canvas, a Gemini page | Yes, the easiest case |
| A static front-end build | v0, Bolt, Lovable, Cursor, a Vite or React project | Yes, after one build step |
| A full app that needs a server | anything with a login, a database, secret API keys, or server actions | No, this needs a server host |
The rule behind the table: if everything the page does happens in the visitor's browser, it is static, and it can live on a plain link. The moment it needs a secret key kept off the browser, a database it talks to, or server-side code that runs per request, it needs a real server. Most AI-built landing pages, dashboards, prototypes, calculators, portfolios, and one-page apps are fully static, which is why this works for them. A SaaS backend with user accounts is not, and no static host can change that.
The 30-second version
If the AI handed you a single HTML page, you are basically done:
- Save the output as an
.htmlfile (name itindex.html). - Drop it in the box at the top of this page.
- Click Get my link. It is live at an address like
my-app.snapy.page.
If the AI handed you a project (a folder of code), there is one build step first, covered below. Either way, the person you send it to clicks once and sees the real thing running, not a picture of it.
Export it from your tool, step by step
Every tool hands the output over a little differently. Here is the exact move for each, plus the one thing that tends to trip people up.
Claude artifacts
A Claude artifact that is a web page is already a single HTML file. Open the artifact, use the code or export option to copy the full HTML, paste it into a file named index.html, and upload that. If the artifact pulls in a library from a CDN, leave those links as they are, they load fine on a public page. See the full Claude artifact walkthrough.
ChatGPT pages and canvas
ChatGPT can write you a complete HTML page in canvas or in a normal reply. Copy everything from <!doctype html> to the closing </html>, save it as index.html, and upload. If it split the work into separate HTML, CSS, and JS files, keep the same file names it used and upload all of them together as a small bundle. More in share a ChatGPT page.
Gemini
Gemini hands back HTML the same way. Save the page as index.html and drop it in. If it references an image by a local name, upload that image alongside the HTML so the link is not broken. See publish a Gemini page.
v0
v0 generates a Next.js project. Download the code, then build it as a static site: set the project to static export, run the build, and you get an out folder. Zip the contents of that folder and upload the zip. The catch with v0 is that it often uses App Router features that assume a server, so check the static-export note below before you build. Step-by-step in publish a v0 page.
Bolt
Bolt builds in the browser and lets you download the project. Run npm install then npm run build, which produces a dist folder for a Vite project. Zip the contents of dist and upload. Full steps in publish a Bolt page.
Lovable
Lovable connects to GitHub or lets you export the code. Pull the project, run the build, and host the output folder. Most Lovable projects are Vite, so the output is dist. Details in publish a Lovable site.
Cursor and hand-built projects
Whatever Cursor (or you) built, the rule is the same: run the project's build command, find the output folder, and zip its contents. The build command and folder depend on the framework, listed below. See publish what Cursor built.
Replit
Export or download the project, build the static front end, and upload the output. If the Replit app has a backend, only the front end can be a static link, the backend still needs to run somewhere. More in host a Replit project.
Where each framework puts the build
When the AI gives you a project instead of a single file, the build creates a folder of plain files to upload. The folder name depends on the framework:
| Framework | Build command | Output folder |
|---|---|---|
| Vite (most Bolt and Lovable apps) | npm run build |
dist |
| Create React App | npm run build |
build |
| Next.js (static export) | next build with output: 'export' |
out |
| SvelteKit (static adapter) | npm run build |
build |
| Plain HTML, CSS, JS | none | the files as they are |
Upload the contents of that folder, with index.html at the top level. That single detail prevents the most common failure, covered next.
The gotchas that break an AI build when you host it
This is the part no one writes down. Each of these has a clear cause and a one-line fix.
Blank page after upload
Two usual causes. First, the zip had a wrapper folder, so index.html landed at dist/index.html instead of the top. Fix: zip the contents of the build folder, not the folder itself, so index.html is at the root of the zip. Second, the build set its asset links to start from a domain root that no longer matches. Fix: build with relative paths (in Vite, set base: './'; in Create React App, set "homepage": "." in package.json).
Styling and scripts do not load (page looks unstyled)
The HTML is loading but its CSS and JavaScript are 404ing. This is the absolute-path problem again: a tag like <link href="/assets/style.css"> looks for the file at the site root, and if the build expected a sub-path it will not be found. Relative paths (./assets/style.css) fix it. Rebuild after changing the base setting, do not edit the built files by hand.
Links break when someone refreshes or opens a deep link
If the app uses client-side routing (React Router and friends), the home page works, but a visitor who lands directly on /dashboard or refreshes there can hit a not-found, because that path is not a real file. For a shared prototype, the simplest fix is hash routing (/#/dashboard), which keeps everything under the one real index.html. Keeping a demo to a single page also sidesteps it entirely.
It works in the editor but not once it is live
The AI editor runs a live dev server that compiles things on the fly. A public link serves plain files, so you have to run the build first. If you upload the raw source (the src folder, .jsx or .tsx files), the browser cannot run it. Always upload the built output, not the source.
Secrets and API keys
A static page cannot keep a secret. Anything in the built JavaScript is visible to anyone who opens the page. Public values are fine (a published map key restricted by domain), but a private API key, a database password, or an auth secret must never ship in a static build. If the app needs one to work, it needs a server. This is the honest line between "host it as a link" and "deploy it to a server."
API calls that worked locally now fail
If the AI app calls http://localhost:3000/api, that address means nothing on someone else's machine. It has to call a real public API. And the API it calls has to allow requests from the new address (CORS), or the browser will block them. For a demo, mock the data or point it at a public endpoint that allows cross-origin requests.
Next.js server features
Next.js App Router code from v0 often uses server components, server actions, or API routes. None of those run on a static host, they need a Node server. Static export (output: 'export') turns the app into plain files only if it avoids those server features. If the app genuinely needs them, host it on a Node platform instead and use Snapy for the static pieces, a one-pager, a preview, a marketing page, that you want a clean tracked link for.
What you get that the AI tool's own share does not
Once the page is on Snapy, it is a real link you control, not a preview tied to your editor session:
- A clean, named URL. Pick
pitch.snapy.pageinstead of a random string. - A password, an expiry, or view-only. Lock a prototype to a client, or let it expire after the pitch.
- A QR code for any link, ready to drop into a slide or print.
- It stays live as long as you want, and it never logs the viewer into your account.
- You see who opened it. Every link comes with free tracking: opens, time, and country. For a demo you sent to a client or an investor, that tells you whether anyone actually looked, which a preview link never does. See who viewed your link.
Snapy vs the other ways to share an AI build
| The AI tool's share link | Vercel or Netlify | A screenshot | Snapy | |
|---|---|---|---|---|
| Opens with no login | Often not | Yes | Yes | Yes |
| Setup needed | None | Account, Git, build config | None | None |
| Shows the live, working page | Sometimes | Yes | No | Yes |
| Custom name, password, expiry | No | Partly | No | Yes |
| See who opened it | No | No | No | Yes |
| Time to a link | Instant but gated | Minutes | Instant | Seconds |
Vercel and Netlify are the right call when the app needs a server or a real deploy pipeline. For a fast, free, public link to a static AI build that you also want to track, Snapy is the shortest path.
Quick troubleshooting
- Blank page:
index.htmlis not at the top of the zip, or asset paths are absolute. Zip the folder contents and rebuild with a relative base. - No styling: CSS and JS are 404ing on absolute paths. Use relative paths.
- 404 on refresh: client-side routing without a real file at that path. Use hash routing.
- Page is the raw code: you uploaded the source, not the build. Run the build first.
- Data does not load: the app calls localhost or an API that blocks cross-origin requests.
Pick your tool
- Share a Claude artifact
- Publish a v0 page
- Publish a Bolt page
- Publish a Lovable site
- Share a ChatGPT page or canvas
- Host a Replit project
- Publish what Cursor built
- Publish a Gemini page
Frequently asked questions
Which AI tools does this work with? Any tool that gives you an HTML page, a file, or a static build: Claude, v0, Bolt, Lovable, ChatGPT, Replit, Cursor, and Gemini among them. If you can export it as a file or a folder, you can publish it.
Does the person I share with need an account? No. The link is a clean public URL that opens for anyone, on any device, with no login.
Is it free? Yes. Publishing an AI-built page and getting a link is free. It needs a free account with a confirmed email.
Can I host a full-stack app with a database or a login? Not as a static upload. Snapy serves the front end the AI built. Anything that needs a running server, a database, or secret keys has to live on a server host. Most AI-built pages and prototypes are static, so they work.
Why does my AI app show a blank page when I host it? Usually the index.html ended up inside a sub-folder of the zip, or the page links to its assets with absolute paths. Zip the contents of the build folder and use relative paths.
Can I see who opened the link? Yes. Opens, time, and country come with every link, free.
New to this? Start with free HTML hosting or how to host an HTML file, then come back and publish what your AI tool built.