DEV Community: htmlput

5 ways to put a single HTML file online, actually tested

htmlput — Thu, 22 Oct 2026 05:08:23 +0000

Last week I published a Pomodoro timer as one self-contained HTML file — no build step, no dependencies, about 1.6 KB. The obvious next question: how do you actually get a file like that onto the internet?

I took the exact same file and ran it through five popular options in October 2026, timing each and writing down what each one really asks of you. No marketing copy — just the flows as they are.

1. GitHub Pages

The classic. Push your file to a repo, turn on Pages, get a username.github.io/repo link.

What actually happened: I wasn't signed into GitHub in this session, so the flow stops at the account wall: create a repo, add the file as index.html, go to Settings → Pages, deploy from a branch, wait about a minute for the first build.

Time to link: not timed hands-on (account required); about a minute after the first push per the documented flow.

2. Cloudflare Pages

What actually happened: same story — this one needs a Cloudflare account before anything else. After that it's "Upload assets" (drag a folder straight into the dashboard, no git needed) or connect a git repo, then deploy.

Time to link: not timed (account required).

3. Netlify Drop

What actually happened: the only one of the five with no account gate on the front door. Open app.netlify.com/drop and you get a giant "Drag & drop to publish instantly" zone — drop a file, a folder, or a zip (their FAQ explicitly blesses dropping a single index.html), or use the file/folder picker buttons. No login to start dropping.

I couldn't complete the drop in this session — I had the file as pasted text, not as a file on disk — but the UI is exactly what it claims to be. Their FAQ: drops stay on the free plan "for as long as you like," and you can rename the project or attach a custom domain from the dashboard (which is where the account comes in).

Time to link: seconds after the drop, by design; not timed end-to-end here.

4. htmlput — paste the code

(Disclosure: I built this one.)

What actually happened: opened htmlput.com, pasted the full file into the editor — it counted "1.5 KB of 1 MB used" — ticked the Cloudflare "Verify you are human" checkbox, clicked "Host now"… and landed on the sign-in page: "Please sign in to host a page." Their FAQ confirms it: "Yes. Create a free account (or sign in), then paste HTML or upload a ZIP to get a share link in seconds."

So the paste flow is real and quick, but anonymous hosting is gone — you need the free account first. The free tier is 30 MB of storage, and per their FAQ, "hosted pages stay available and share links keep working unless you delete the page."

Time to link: blocked at sign-in; the paste-and-verify part took under a minute.

5. tiiny.host — Paste HTML

(Side note: itty.bitty, the link-in-a-URL trick, no longer resolves — DNS failure, tried twice — so tiiny.host stood in for this slot.)

What actually happened: opened tiiny.host, switched to the "Paste HTML" tab, pasted the code (their editor reformatted it), clicked Continue — the file staged as code.html (index), 1.67 KB — and then: "Please verify your email. We need to verify your email to reduce spam." Google, GitHub, Microsoft, or Yahoo SSO, or an email field. I stopped there rather than create an account.

Their FAQ: links stay online indefinitely on the free plan as long as you log into your account once every 3 months.

Time to link: blocked at email verification.

The comparison

Method	Steps	Time to link	Custom domain on free	Expiry	Best for
GitHub Pages	new repo → add `index.html` → Settings → Pages → deploy from branch	~1 min after push (documented; account needed, not timed)	yes	none	maintained projects
Cloudflare Pages	account → Pages → Upload assets or connect git → deploy	not timed (account needed)	yes	none	projects that will grow
Netlify Drop	open app.netlify.com/drop → drop file, folder, or zip	seconds after drop (not timed end-to-end; no local file in session)	via dashboard (account)	none — "as long as you like"	fastest share of a file on disk
htmlput	paste code → verify you're human → Host now → sign in	blocked at sign-in (free account required)	not stated	none, until you delete the page	paste-and-share once you have an account
tiiny.host	Paste HTML tab → paste → Continue → verify email	blocked at email verification	feature listed; free-tier terms not verified	indefinite if you log in every 3 months	quick share once you have an account

How to choose (no winner declared)

Maintained project → Pages. Git history, real custom domains, nothing expires. The minute of setup pays off forever.
One file in 30 seconds → a paste host. Just know that in 2026 both paste options I tried want an account first — "instant" starts after signup.
A file sitting on your disk and zero patience for signup forms → Netlify Drop. It's the only flow here that goes from file to link with no account in between.

The honest surprise of this test: the "no signup needed" era of paste-and-host is mostly over. The real cost was never money — it's the account.

A Pomodoro timer in 20 lines of vanilla JS

htmlput — Thu, 22 Oct 2026 05:01:59 +0000

Most first JavaScript projects die in setup. You pick a framework, install a toolchain, and by the time anything appears on screen you've forgotten what you wanted to learn.

A Pomodoro timer is the opposite. It needs exactly three things: a heartbeat, a piece of state, and a screen. That's it. No libraries, no build step, no backend. One HTML file, a handful of lines of JavaScript, and you end up understanding the core loop behind nearly every interactive UI ever built.

The three moving parts

1. setInterval is the heartbeat. The entire timer is this line:

timer = setInterval(tick, 1000);

Every second, the browser calls tick(). Everything else is decoration around that one repeating pulse.

2. One variable is the entire state. let left = FOCUS — seconds remaining. 25 x 60 = 1500. There is no state object, no store, no reducer. The timer's whole memory is a single number counting down. When you're learning, that's the point: state doesn't have to be architecture. It can be a number.

3. textContent is the render. A fmt helper turns seconds into MM:SS with padStart, and tick writes it to the page:

el.textContent = fmt(left);

No virtual DOM, no diffing — you compute the string, you set the string. Every framework's render cycle is a fancier version of this exact idea.

The pause/resume trick

Here's my favorite part. Look at the start button handler:

btn.onclick = () => {
  if (timer) { clearInterval(timer); timer = null; btn.textContent = 'Resume'; return; }
  if (left <= 0) left = FOCUS;
  timer = setInterval(tick, 1000); btn.textContent = 'Pause';
};

Pausing isn't a mode. It's the absence of the interval. timer is either an interval ID (running) or null (paused), so the variable doubles as the paused flag. Beginners often reach for an isPaused boolean and then spend an hour keeping it in sync with reality. The trick: make the state be the reality. If there is no interval, you're paused. Nothing to sync, nothing to drift.

Reset is the same idea in reverse: clear the interval, put 1500 back into left, redraw.

The full file

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Pomodoro — 25 min focus</title>
<style>
  body{font-family:system-ui;display:grid;place-items:center;min-height:100vh;margin:0;background:#0f172a;color:#f1f5f9}
  #time{font-size:5rem;font-variant-numeric:tabular-nums;margin:0 0 1rem}
  button{font-size:1rem;padding:.6rem 1.4rem;margin:.3rem;border:0;border-radius:999px;cursor:pointer}
  #start{background:#22c55e;color:#052e16}#reset{background:#334155;color:#e2e8f0}
</style>
</head>
<body>
<div style="text-align:center">
  <p id="time">25:00</p>
  <button id="start">Start</button>
  <button id="reset">Reset</button>
</div>
<script>
const FOCUS = 25 * 60;
let left = FOCUS, timer = null;
const el = document.getElementById('time');
const btn = document.getElementById('start');
const fmt = s => `${String(Math.floor(s/60)).padStart(2,'0')}:${String(s%60).padStart(2,'0')}`;
const tick = () => { el.textContent = fmt(left); if (--left < 0) { clearInterval(timer); timer = null; btn.textContent = 'Start'; alert("Time's up — take a break!"); } };
btn.onclick = () => {
  if (timer) { clearInterval(timer); timer = null; btn.textContent = 'Resume'; return; }
  if (left <= 0) left = FOCUS;
  timer = setInterval(tick, 1000); btn.textContent = 'Pause';
};
document.getElementById('reset').onclick = () => { clearInterval(timer); timer = null; left = FOCUS; el.textContent = fmt(left); btn.textContent = 'Start'; };
</script>
</body>
</html>

Copy it into a file called pomodoro.html, open that file in your browser, and you have a working focus timer. No server, no install, nothing to configure.

Fork it in 30 seconds: change one constant — const FOCUS = 5 * 60; — and you get a 5-minute test run instead of waiting 25 minutes to see the "Time's up" alert. Edit, refresh, observe: the fastest feedback loop in programming.

What to build next

This timer is a seed. Each natural upgrade teaches one new concept:

Break mode — alternate 25-minute focus blocks with 5-minute breaks. Teaches you state machines (a mode variable: 'focus' or 'break').
A sound when time's up — swap the alert for the Web Audio API. Teaches you browser APIs beyond the DOM.
A streak counter in localStorage — persist completed sessions across reloads. Teaches you the only browser database most small projects ever need.

Pick one, and the 20-line timer becomes a real app — still in a single file.

Single-file HTML is underrated: lessons from shipping 50+ one-page sites

htmlput — Sat, 10 Oct 2026 04:05:22 +0000

Everyone I know reaches for a framework before they've finished the sentence describing what they're building. Next.js for a landing page. A full CMS for a project retrospective. I've done it too.

But over the last year I've shipped 50+ single-file HTML pages — reports, explainers, dashboards, interactive demos — and I've become convinced the humble .html file is the most underrated medium on the web. Here's what I learned.

1. One file forces one idea

When your entire page lives in a single file, scope creep becomes physically painful. There's no components/ folder to hide half-finished ideas in. Every section has to justify its existence, because you can feel the file getting heavy. This constraint produces tighter writing and clearer structure than any linter ever did for me.

2. A URL beats a repo

The moment someone can open your work in a browser with zero setup, your distribution changes completely. "Clone this, npm install, ..." is a funnel with 90% drop-off at each step. A link is a funnel with one step. For anything meant to be read rather than run — reports, proposals, visual explainers — a single file shared via URL will reach 10x the people.

3. Own your bytes

A single HTML file is the most portable artifact in computing. It works offline. It works in 20 years. No build step to rot, no dependency to deprecate, no platform to shut down your account. I've re-opened pages I made a decade ago and they render fine. Try that with a framework project.

4. Know when NOT to do it

Single-file breaks down when: you need a database, you have more than ~3 distinct page types, or multiple people edit concurrently. It's a medium for documents and demos, not applications. Respecting that boundary is the whole trick.

Practical tips that actually matter

Inline everything, but watch the weight. CSS and JS inline is the point — but base64 images balloon fast. Keep total under ~500KB or split images out.
Design for the phone first. Over 60% of my page views are mobile. If your layout needs horizontal scrolling on a 390px viewport, it failed.
Print styles are free goodwill. Five lines of @media print CSS makes your page genuinely useful as a document. Nobody does this; everyone appreciates it.
Semantic HTML is your SEO. No framework, no meta framework — just real headings, real paragraphs, alt text. It works.

The takeaway

We rebuilt the web to be programmable and forgot it was supposed to be readable. Before you scaffold a project, ask: could this just be a really good HTML file? Half the time, the answer is yes — and you'll ship it today instead of next month.