DEV Community: xhorizon

Netlify Drop, GitHub Pages, Tiiny Host: what the free tiers actually do with one HTML page (Oct 2026)

xhorizon — Thu, 15 Oct 2026 09:52:43 +0000

Disclosure: I build dochost, one of the four tools below. I've tried to state its limits as plainly as the others'. Everything was checked against each provider's own docs on Oct 15, 2026.

Ask an AI assistant "how do I put this HTML page online?" and you'll usually get Netlify Drop first, then GitHub Pages. Both are good answers, for a site. For one page you need someone to open today, the details of the free tier matter more than the brand. Here's what actually happens to your link on each.

The part that surprises people

Netlify Drop without an account is temporary. An unclaimed drop sits behind a temporary password until you claim it, and Netlify's CLI docs say anonymous deploys must be claimed within one hour or they're removed. Claim it with a free account and it stays up, with a free custom domain.
Tiiny Host's free link has no expiry date, but it has an activity rule. One project stays online as long as you log in at least once every three months. Free uploads are capped at 3 MB and show a Tiiny Host banner.
GitHub Pages on GitHub Free needs a public repo. So your source is public too. Changes can take up to 10 minutes to go live, and the terms rule out running a business/SaaS on Pages.
dochost free links expire. Public pages after 7 days, private (link-only) pages after 3 days. Permanent links are a paid feature. What you get in exchange is no account and a paste box: paste the HTML the assistant gave you, publish, send the link.

At a glance

	dochost	Netlify Drop	Tiiny Host	GitHub Pages
Signup to keep the link	Not needed (but link expires)	Yes (claim the deploy)	Yes	Yes (account + repo)
Paste HTML directly	Yes	No, drop a file/folder/zip	Yes	Commit a file
Markdown rendered	Yes	Needs a build step	Not advertised	Yes, via Jekyll
Free link lifetime	7 days public / 3 days private	Permanent once claimed	Permanent while you log in every 3 months	Permanent
Free custom domain	No (Max plan)	Yes	No (Solo plan)	Yes
JavaScript runs	Yes	Yes	Yes	Yes

Which one, for which job

Multi-file site (separate CSS, images, scripts): Netlify Drop. Drop the folder.
Portfolio or docs you'll maintain for years: GitHub Pages if you're fine with Git, otherwise a claimed Netlify Drop site.
One small page that should stay up for free with no dev tools: Tiiny Host, if the banner is OK.
One AI-generated page (a quiz, a report) someone needs to see this week: dochost. Nobody signs up, inline JS runs, and the link cleans itself up. If it needs to live longer, that's where the others win.

A practical check before using any single-file publisher: search the HTML for src=" and href=" pointing at local files. A relative path to an image you didn't upload will break on every host above except a full folder deploy.

The full comparison (pricing, password options, an FAQ) is on the original post: https://dochost.io/blog/netlify-drop-vs-github-pages-vs-tiiny-host?utm_source=devto&utm_medium=referral&utm_campaign=compare-2026-10

What's your default for "just put this one page online"? I'm curious which trade-off people hit first: the expiry, the account, or Git.

Why your HTML loses styles or images after upload: a debugging checklist

xhorizon — Tue, 13 Oct 2026 08:30:36 +0000

An HTML page can look correct on your laptop and lose its images or styling after you upload it. The first thing to check is what the browser is trying to fetch—not which host has the nicest landing page.

Disclosure: I work on dochost, one of the publishing options mentioned below. This guide was drafted with AI assistance. The examples explain browser URL resolution; they do not claim that every upload problem has the same cause.

What does a relative path mean after publishing?

Consider this HTML:

<link rel="stylesheet" href="./styles.css">
<img src="./images/chart.png" alt="Monthly totals">

Those references do not include the files. They tell the browser where to request them relative to the document's base URL. If you uploaded only report.html, its neighboring stylesheet and image may never have reached the host.

You can inspect resolution without making a network request:

new URL('./images/chart.png', 'https://example.com/reviews/report.html').href
// https://example.com/reviews/images/chart.png

new URL('/images/chart.png', 'https://example.com/reviews/report.html').href
// https://example.com/images/chart.png

The leading slash changes the location. A <base href="..."> element can also change the base used by relative links. See the MDN URL constructor reference for how relative references resolve.

Read the failed request before editing the page

Open the published link, open browser developer tools, select Network, and reload. Inspect failed requests for CSS, JavaScript, fonts, and images.

For each request, compare the requested URL with the intended asset location. A 404 suggests checking the path and whether the file was deployed. A 200 is not sufficient: inspect the response type and body. Some hosts return an HTML fallback page at a missing asset URL, which is still the wrong content for a stylesheet.

Also check filename capitalization. A reference to Chart.png can fail when the deployed file is named chart.png. Do not assume that a local filesystem and a remote host treat names identically.

Choose a single file or a complete folder

If the report is small, make it self-contained where practical. Put CSS in a <style> element and small browser scripts in a <script> element. For images, use a supported asset upload workflow, appropriate embedded image data, or stable public URLs. Weigh document size and privacy before embedding or publicly hosting an image.

dochost publishes pasted or uploaded HTML and Markdown as shareable pages. For a single HTML document, include the dependencies the page needs and test the public result. Published HTML supports JavaScript in a sandbox; that does not mean every browser API or external resource will work. Free links expire after seven days.

If the page belongs to a multi-file site, deploy the complete browser-ready folder instead. Netlify's manual deployment documentation explains uploading a prebuilt site folder. A source project with package imports may need a build first; uploading source code is not the same as deploying its generated output.

If the files load, inspect the interaction

Once CSS and images are present, a broken button is a separate diagnosis. Read the Console for JavaScript errors. Check whether the element exists when the script runs and whether its selector matches. For a form, decide whether you want a normal navigation or a client-side interaction; an unintended submission can reload the page and discard the result.

Do not label every failure as “the host blocks JavaScript.” An incorrect path, a missing file, an error in the script, or a sandbox restriction can produce different symptoms. Use a small reproduction to separate them.

Test the recipient's version

Open the link in a signed-out browser or a separate profile, then on a phone. Confirm that images and source links do not depend on your login. Try the actual buttons and check the expiry window against the review date.

Keep the original HTML and its assets separately. The repair should leave you with a reproducible document or deployment folder, not a page that happens to work only in your own browser.

How to share a ChatGPT HTML quiz with students: a preflight checklist

xhorizon — Sun, 11 Oct 2026 14:18:52 +0000

An AI assistant can give you a complete HTML quiz, but a code block in a chat is not a classroom link. Before choosing a host, check whether the output is actually a self-contained browser page.

Disclosure: I build dochost. I will use it as one single-file publishing option below, alongside folder and repository hosting. Free dochost links expire after seven days, which matters if students will return to the quiz later.

1. Ask for a browser-ready deliverable

A useful prompt is:

Make this quiz a single self-contained HTML document. Put CSS in a style element and JavaScript in a script element. Do not require npm, a development server, a backend, API keys or local files. Keep the questions and answer checking in the document. Use standard HTML form controls and show accessible feedback after submission. Return the complete HTML source.

This makes the requirements explicit; it does not prove the generated result is correct. If you need saved scores, accounts or a teacher dashboard, you are asking for an application with data handling, not just one static file.

2. Test the submit button, not just the appearance

Save the source as quiz.html and open it locally. Try an unanswered question, a wrong answer and a correct answer. Check whether the score changes and whether reset clears it.

For a form-based quiz, the JavaScript normally prevents the browser's default navigation and handles submission itself:

const form = document.querySelector('#quiz');
form.addEventListener('submit', (event) => {
  event.preventDefault();
  // Validate the answers and render feedback here.
});

This is an event-handling pattern, not a complete quiz. Ask the assistant to connect it to the actual questions and feedback elements. A page that looks finished can still have an unwired button.

3. Check what the file depends on

Search the HTML for src=, stylesheet links, fetch( and paths such as C:\\ or /Users/. A local image or a missing CSS file will not magically be included when you publish just the HTML.

For a single-file publisher, inline the assets or use public asset URLs.
For a folder host, upload the HTML and its CSS, JavaScript and images together, keeping the relative paths.
For a framework project, build the static output first, or use a host that supports its build workflow.

Public external assets can still fail because of permissions, browser rules or service outages. Test the hosted result too.

4. Pick the sharing workflow

One self-contained HTML file: dochost accepts pasted HTML or an uploaded file without an account or build setup. Its HTML JavaScript runs in a sandbox. Publish and copy the returned link. The free link lasts seven days; check the current plans if you need a permanent link.

A folder of assets: Netlify Drop is a folder-based deployment option. Manual deployment does not run a build, so provide the ready-to-serve output.

A site you will maintain in Git: GitHub Pages serves static HTML, CSS and JavaScript from repository content. It suits a versioned course site better than a one-off paste workflow.

5. Open the final link as a student

Use a separate browser session. Submit the quiz, reset it and try it on a phone. Check the expiry against the lesson date. Do not rely on your own signed-in access as evidence that students can open it.

Before sharing, remove student names, credentials and any secret API keys. Browser code can be inspected: if answers are embedded in the JavaScript, students can find them. This is suitable for practice and self-checking, not secure high-stakes assessment.

The final test is simple: can a student open the URL, answer the questions and see useful feedback during the time they need it? That is a better publishing check than whether the screenshot looks polished.

Building a citation-first game fieldguide without inventing the missing stats

xhorizon — Fri, 11 Sep 2026 15:35:34 +0000

Game databases have a data-integrity problem that looks deceptively simple: users want complete tables, while the primary sources are incomplete.

For a new or Early Access title, the tempting implementation is to copy a value from a video, a beta screenshot, or another guide and render it with the same confidence as publisher-confirmed data. That produces a tidy UI and a weak reference.

I used a stricter model while building the independent WARDOGS Fieldguide: every claim belongs to an evidence grade, and unknown is a real value rather than an empty authoring task.

type EvidenceGrade = "official" | "confirmed" | "beta-observed" | "unknown";

type Fact<T> = {
  value: T | null;
  grade: EvidenceGrade;
  sourceUrl?: string;
  observedAt?: string;
  note?: string;
};

That small distinction changes the whole publishing workflow.

An official store statement can be shown directly. A value visible in a dated beta frame can be useful, but it gets a beta label and does not silently survive into the launch build. A repeated community claim with no traceable source remains unknown. The interface renders the gap honestly instead of coercing it into a number.

The same rule applies at page level. A launch guide can say that WARDOGS supports up to 100 players, uses three teams, puts one randomized 2 × 2 km Control Zone inside a 256 km² map, and awards the match to the first team reaching 100 points. Those are sourced facts. A complete weapon-price table is not, because the official material does not publish one.

The public WARDOGS database is the resulting example. It is less “complete” than pages that guess, but it is easier to update and audit:

Store the claim with its evidence grade.
Keep the source URL and observation date beside the value.
Render unknowns explicitly.
Downgrade beta observations when the build changes.
Never promote a repeated secondary claim without finding its origin.

This pattern is useful beyond games. Any product catalog, compatibility matrix or living documentation set benefits when uncertainty is modeled instead of hidden.

HTML to URL: five ways to turn an HTML or Markdown file into a shareable link

xhorizon — Fri, 07 Aug 2026 15:10:14 +0000

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.

Three ways to share your ChatGPT / Claude output as a real web page

xhorizon — Sun, 14 Jun 2026 06:25:17 +0000

Your LLM just produced a great report, a README, a doc, a table. Now you want to send it to someone. Pasting raw Markdown into Slack looks broken. A screenshot isn't searchable or copyable. Forwarding the whole chat shares more than you want. So how do you turn one AI output into a clean, linkable web page?

Here are three approaches, with the trade-offs.

1. GitHub Gist

Paste the Markdown into a .md Gist and share the link. Free, durable, and developers trust the domain.

Downsides: it renders in GitHub's wrapper (not a clean standalone page), HTML isn't rendered live, and it's a weird link to send a non-technical person. Good for code snippets, awkward for a polished doc.

2. Publish from a static-site setup

Drop the content into a repo with GitHub Pages, Netlify, or a notebook tool. Maximum control.

Downsides: it's a project, not a 10-second action. Overkill when you just want one page to exist at one URL.

3. A paste-to-link publisher

Tools in this category take Markdown or HTML, render it, and hand you a URL. No repo, no build. Options include Telegraph, JotBird, mdshare, and dochost (which I built, so fair disclosure). The differences worth knowing:

HTML support — some only take Markdown. If your AI produced an HTML artifact, you want one that renders HTML directly. dochost does; check the input formats supported by each publisher.
JavaScript — dochost runs HTML JavaScript in a sandbox, so self-contained quizzes and calculators can stay interactive. This does not supply a backend or guarantee every browser capability.
Permanence — free tiers often expire links (dochost's free links last 7 days). Fine for a quick share, check the tier if you need it to live forever.
Password / private — check whether protection is available on your plan. An unlisted URL is not the same as a password-protected page.

A concrete walkthrough (paste-to-link)

Copy your Markdown or HTML out of ChatGPT/Claude.
Paste it into the publisher's box.
Get a URL. Send it.

That's the whole loop. For AI output specifically, this is the lowest-friction of the three — no repo, renders HTML, and you're sharing a normal web page instead of a screenshot or a raw blob.

Which to pick

Code snippet for other devs → Gist.
A page you'll maintain and grow → static site.
One-off doc / AI output you just need to send → a paste-to-link tool.

Pick the boring one that matches the job. For me, sharing LLM outputs landed on the third.

Updated October 11, 2026. For a more detailed comparison of file, folder and repository workflows, see five ways to publish HTML or Markdown.