You have an HTML file or Markdown document from ChatGPT or Claude. The recipient needs the rendered page, not a code block. The useful question is: are you sharing one self-contained file, a folder of assets, or a project that needs a build?
Disclosure: I built dochost, one of the options below. This is a workflow comparison, not an independent ranking. Updated October 11, 2026: the earlier version incorrectly said dochost disabled JavaScript. Its published HTML now runs JavaScript in a sandbox; the seven-day free-link expiry still applies.
Choose by what you actually have
| What you have | A suitable starting point | Main trade-off |
|---|---|---|
| One HTML quiz, calculator or Markdown report | dochost | Free links expire after seven days; single-file assets need to be self-contained or publicly accessible |
| A folder containing HTML, CSS, JS and images | Netlify Drop | Upload the built folder; manual deployment does not run a build |
| A static site you want to maintain in Git | GitHub Pages | Repository and Pages setup; no server-side application runtime |
| Prebuilt site assets and a Cloudflare account | Cloudflare Pages Direct Upload | Account/project setup; a Direct Upload project cannot later switch to Git integration |
| A frontend experiment where readers should inspect the code | CodePen / JSFiddle | A code playground rather than a document-first sharing workflow |
These are starting points, not exclusive capabilities. For example, a single HTML file can also live in a repository or a static-site folder.
1. Netlify Drop: upload the whole static folder
If your page references style.css, app.js and an images/ directory, keep those files together. Netlify documents a drag-and-drop deployment of the project's build/output folder. A manual deploy does not run a build command: if an AI assistant gave you a framework project, build it first and upload the output, not the unbuilt source.
For a simple site, put the entry page at index.html and retain the relative asset paths. When you change the site, upload the updated folder. Check the current account and plan requirements for keeping and managing the deployment.
Source: Netlify deployment documentation.
2. GitHub Pages: use a repository when maintenance matters
GitHub Pages publishes a static website from repository content, including HTML, CSS and JavaScript. It is a sensible choice when the source should be versioned and future edits should follow a Git workflow.
The cost is setup rather than a paste-only workflow: create or use a repository, configure Pages and make subsequent changes in that repository. Static hosting does not give your page a Node.js/Python backend or a database. A secret API key embedded in browser JavaScript remains visible to readers.
Source: What is GitHub Pages?.
3. Cloudflare Pages Direct Upload: publish prebuilt assets
Cloudflare Pages supports Direct Upload through Wrangler or dashboard drag and drop. The dashboard accepts a folder or ZIP; Wrangler accepts a folder. This works when you already have the static files and want a managed static-site project.
One decision to make early: Cloudflare says a Direct Upload project cannot later switch to Git integration. If automatic repository-based deployments are your likely next step, choose that workflow at project creation instead.
Source: Cloudflare Direct Upload documentation.
4. CodePen / JSFiddle: share an experiment and its source
A code playground is useful when the recipient is another developer who wants to inspect and modify the HTML, CSS and JavaScript. It is less natural when the deliverable is a report or lesson that should open as a finished page.
Match the environment to the generated code. A full HTML document, external libraries and a multi-file project may need adaptation to the playground's editor and dependency setup. Do not assume any code block from an AI assistant will run unchanged in every editor.
5. dochost: publish one HTML or Markdown document
Paste HTML or Markdown, or upload a .html/.md file, then publish a shareable link without creating an account or configuring a build. Markdown renders as a page; HTML JavaScript runs in a sandbox, so self-contained quizzes and calculators can remain interactive.
The important limitation is retention: free links expire after seven days. Paid plans provide permanent links and additional options. If students need the page next month, a seven-day link is not enough.
This is a single-document workflow. Inline separate CSS/JS files, or reference assets at publicly accessible URLs. Sandboxed browser JavaScript is not a backend: do not expect server code, private local files or every browser capability to work unchanged.
Start with the HTML publishing page, and check the current plans before choosing a permanent-link option.
Check the file before sharing
- Open it locally and test the actual interaction: submit the quiz, calculate a result, or switch the chart.
- Look for local file paths and missing assets. Folder hosts need the referenced files included; single-file publishers need inline or public assets.
- Remove secrets and personal data you did not intend to publish. Browser source is accessible to recipients.
- Open the final URL in a separate browser session and test again. Local success does not prove hosted success.
- Check the link lifetime and access settings against how long the recipient needs it.
For a classroom quiz, the deciding factors are working interaction, student access and retention. For a maintained website, repository-based deployment may be a better fit. Pick the workflow that matches the deliverable.
Top comments (0)