DEV Community

Neurobin
Neurobin

Posted on Originally published at previewship.com

How to Publish AI-Generated HTML When You Do Not Use Git

#webdev #ai #html #beginners

AI can generate a useful web page before you have learned Git, domains, deployment pipelines, or servers.

That is good news. It also creates a very practical question:

How do you turn the file into a link that another person can open?

For a browser-ready page, the answer can be much smaller than a production deployment. You need to identify what the AI created, upload the right artifact, open the returned URL, and verify it.

This guide explains that workflow without assuming you already know web hosting.

First, identify what you actually have

The phrase “my AI made a website” can describe three different things.

1. One self-contained HTML file

You may have a file such as:

report.html
Enter fullscreen mode Exit fullscreen mode

or:

index.html
Enter fullscreen mode Exit fullscreen mode

If you can double-click the file and the complete page works in your browser, it may be ready to publish directly.

2. An HTML file with local assets

Your page may reference files next to it:

my-page/
├── index.html
├── styles.css
├── app.js
└── images/
    └── chart.png
Enter fullscreen mode Exit fullscreen mode

In this case, uploading only index.html will break the CSS, JavaScript, or images. Keep the directory structure intact and upload the folder as a ZIP.

3. Framework source code

A project containing files such as these is usually source code, not the final website:

my-vite-app/
├── package.json
├── src/
├── public/
└── vite.config.js
Enter fullscreen mode Exit fullscreen mode

Do not upload src/ and expect a static host to run the project for you.

Build it first:

npm install
npm run build
Enter fullscreen mode Exit fullscreen mode

Vite normally creates a dist/ directory. Other frameworks may create build/, out/, or another configured output directory. That browser-ready output is what you publish.

The beginner workflow

Step 1: remove anything private

Before uploading, inspect the files for:

  • API keys
  • passwords or tokens
  • .env values
  • customer data
  • private conversations
  • internal URLs

A shareable URL should be treated as public unless the product explicitly shows an access control you have tested.

Step 2: open the artifact locally

For one HTML file, double-click it.

For a Vite build, run:

npm run preview
Enter fullscreen mode Exit fullscreen mode

Check the page before publishing. A hosting tool cannot fix a page that is already broken locally.

Step 3: publish the correct artifact

Use PreviewShip’s browser publishing flow:

https://previewship.com/try?utm_source=devto&utm_medium=community&utm_campaign=beginner_publish_2026q4&utm_content=article_0925_01_ai_html

Choose the artifact that matches your project:

  • one self-contained .html file
  • the complete static folder or ZIP when local assets are required
  • dist/, build/, or out/ after a framework build
  • Markdown or PDF when that is the actual document you want to share

PreviewShip is designed for browser-ready static output. It does not run a backend, database, server route, or secret-bearing application.

Step 4: wait for the final status

Selecting a file is not proof that deployment succeeded.

Wait until the publishing flow reports completion and gives you a URL.

Step 5: verify the URL like a recipient

Open the URL in a private browser window and check:

  • the page loads
  • CSS is present
  • images appear
  • buttons and links behave as expected
  • the browser console does not show missing asset errors
  • the result does not expose private data

Only then send the link to another person.

If the published page is blank

Use this short checklist:

  1. Does the uploaded root contain index.html?
  2. Did you upload the complete asset directory?
  3. Are filenames using the same uppercase and lowercase letters as the HTML references?
  4. Does the Network panel show 404 responses?
  5. Did you upload framework source instead of the built output?
  6. Does the app expect a backend or environment secret that is not present?

The most common beginner mistake is not “bad hosting.” It is uploading the wrong artifact.

When you should use a production platform instead

A quick preview URL is useful for:

  • showing an AI-generated page to a friend or client
  • sharing a static report
  • reviewing a landing-page draft
  • opening a prototype on another device
  • getting feedback before a real release

Use a production application platform when the project needs:

  • a backend or database
  • private server-side secrets
  • production authentication
  • a custom domain and operational guarantees
  • long-term monitoring, policy, and release automation

The important skill is not memorizing one hosting tool. It is recognizing whether you have source code or a browser-ready artifact.

Once you can make that distinction, publishing an AI-generated page becomes much less mysterious.

Top comments (1)

Collapse
 
neurobin_ profile image
Neurobin •

What did your AI tool give you: one HTML file, a folder with assets, or framework source? If you share the file shape (without private data), I can suggest which artifact should be published.