AI can generate HTML. Publishing it is still weirdly annoying.

jaxxchen — Thu, 28 May 2026 16:17:05 +0000

AI tools are now pretty good at making complete HTML artifacts:

a small portfolio page
a product one-pager
a pitch deck in HTML
a resume
a visual prototype
a client preview

But after the model gives you the HTML, there is still an awkward last step:

How do I turn this into a real URL I can send to someone?

For developers, the normal answer is GitHub Pages, Netlify, Vercel, Cloudflare Pages, or an object-store flow. Those are good tools. But they are also a lot of ceremony when the artifact is just one finished HTML file.

For non-developers, the gap is even worse. They can ask ChatGPT to create a nice HTML page, but the result often stays trapped in a chat window or a local file.

The narrow problem

The use case I wanted to solve was not "deploy a website."

It was:

Publish one complete AI-generated HTML document as a shareable link.

That means:

no repo required
no build step
no ZIP project
no framework deployment
no DNS setup
optional access-key sharing for private previews

So I built FolioDrop around that narrow contract.

What FolioDrop does

FolioDrop accepts one complete single-file HTML document and returns a real URL.

It is intentionally smaller than a static host:

Paste or upload one HTML work manually.
Publish from an AI tool through MCP or OpenAPI.
Save public works into a lightweight personal folio.
Keep access-key protected works unlisted.
Keep individual shared work routes out of search indexing.

The important boundary: FolioDrop is not a replacement for Vercel, Netlify, GitHub Pages, or Cloudflare Pages. If your project needs multiple files, a framework, a custom domain, or long-term production hosting, those tools are a better fit.

The comparison is here: FolioDrop vs static hosting.

Why MCP/OpenAPI matters here

The manual flow is useful, but the more interesting flow is agent-native publishing.

If an AI host can call a publish tool, the user can ask for:

Make this into a single-file HTML page and publish it.

The agent can then:

generate the HTML
validate that it is a complete document
call the publishing endpoint
return a URL

FolioDrop exposes:

MCP endpoint: https://foliodrop.app/mcp
public MCP config: https://foliodrop.app/api/ai/mcp-config.json
OpenAPI description: https://foliodrop.app/api/ai/openapi.json

I also packaged the publishing workflow as an open GitHub skill:

github.com/jaxxchen003/foliodrop-publisher-skill

That repo includes a single-file HTML validator and templates for decks, resumes, product one-pagers, emails, and portfolio case studies.

The publishing contract

The current contract is deliberately strict:

include <!doctype html>
include <html>, <head>, and <body>
inline CSS in <style>
inline JavaScript only when needed
use public HTTPS URLs for external images or fonts
do not include tokens, secrets, passwords, or local file paths

This constraint keeps the product predictable. It also makes the output easier for AI agents to reason about.

What I learned

The hard part was not generating HTML. The hard part was making the last mile boring:

return a stable URL
avoid leaking access keys
avoid indexing private previews
make deletion and expiry clear
keep the product boundary honest
give agents a structured way to publish without putting secrets into prompts

I wrote up two answer pages for the common questions: