How to share an HTML file as a link

Why you can't just attach the file or use cloud storage

An HTML file attached to an email or shared from Google Drive arrives as a file, not a webpage. When the recipient double-clicks it, one of two things happens: their browser opens it locally with a file:/// path (which breaks any relative links, CSS, or JavaScript), or the file manager just asks what to open it with. Either way, the person you sent it to is staring at raw HTML source instead of the rendered page.

OneDrive and SharePoint have the same problem — they're file storage, not web servers. A browser and a server exchange HTTP headers that tell the browser "render this as a page." File storage skips that exchange entirely. Google Drive can preview some file types, but HTML is not one of them reliably; you'll get a download prompt or a "preview not available" message.

The fix is to put the file on an actual HTTP server that delivers it the right way. You don't need to own a server — the options below are all free for small files.

Five ways to get a shareable link

1. Netlify Drop (fastest, no account required to try)

Go to drop.netlify.com, drag your HTML file (or a folder containing your HTML, CSS, and JS files) onto the drop zone, and Netlify generates a live URL instantly — something like quirky-name-abc123.netlify.app. The link works for anyone with a browser. If you want to keep the URL or update the files later, you'll need to create a free Netlify account. For a one-off share, the anonymous drop is enough.

Gotcha: if your HTML file depends on external CSS or JS files sitting in subfolders, drag the whole folder, not just the .html file. Netlify preserves the folder structure and the relative paths work. If you drag only the HTML file and it references ./styles/main.css, those styles will 404.

2. GitHub Pages (persistent, version-controlled)

If you're already using Git, GitHub Pages is the most durable option. Create a repository, push your files, go to Settings → Pages, set the source to your main branch, and GitHub publishes it at yourusername.github.io/repo-name. Free, permanent, and updates when you push.

The friction: public repositories on the free tier mean your source is visible. If the HTML contains a draft proposal or a prototype you don't want indexed, either upgrade to a paid plan (Pages works on private repos for Pro/Team) or use a tool that doesn't require a public repo.

GitHub Pages is also the slowest of these options for quick one-offs — the initial deploy after enabling Pages can take a few minutes, and you need Git set up locally.

3. Tiiny Host or Linkyhost (purpose-built for single files)

Services like tiiny.host and linkyhost.com exist specifically for this workflow: upload one HTML file (or a ZIP with the whole project), get a link. No Git, no config, no deploy pipeline. Tiiny Host gives you a URL under tiiny.site; Linkyhost keeps files available for as long as your account is active.

Both handle multi-file projects if you ZIP the folder first. The critical thing: use relative paths in your HTML before you ZIP. If your stylesheet is referenced as C:/Users/you/project/styles.css, it will not work when hosted. It needs to be ./styles/css or just styles.css.

4. CodePen or JSFiddle (for self-contained snippets)

If your HTML is a single self-contained file — no external stylesheets or scripts, just one .html with everything inline — paste it into codepen.io (separate HTML, CSS, JS panels) or jsfiddle.net and share the pen URL. Free, no account required to create a fiddle on JSFiddle.

This works well for prototypes, animations, and demos where the whole thing is one file. It breaks down if your project has dependencies spread across multiple files.

5. Share as a canvas link (when you need feedback, not just a view)

The options above get you a viewable URL. They don't give reviewers a way to point at a specific element and leave a comment — so feedback lands in Slack as "the button feels off" with no way to know which button.

This matters most when the HTML is a deliverable — a prototype a client needs to approve, a dashboard a PM is signing off on — rather than a quick demo. A viewable link answers "can you see it?"; a canvas link answers "can you tell me precisely what to change?"

What to do when your HTML has multiple files

Most prototypes aren't a single .html file — they have a CSS folder, a JS folder, images, fonts. The method that works for every option above:

1. Put everything in one folder. Your main file should be named index.html (most hosts default to this as the entry point).
2. Make sure all paths inside the HTML are relative: ./styles/main.css not /Users/you/project/styles/main.css.
3. ZIP the folder.
4. Upload the ZIP to Netlify Drop, Tiiny Host, or Linkyhost.

The most common failure after uploading is broken styles — almost always caused by absolute local paths that made sense on your machine and mean nothing on a server.

AI-generated HTML (from Claude, v0, Cursor)

If your HTML came from an AI tool, it's likely already self-contained: Claude artifacts, v0 exports, and Lovable downloads bundle the CSS and JavaScript inline or reference a CDN, so there are no local files to worry about. A single .html file from any of these tools can go straight to Netlify Drop or Tiiny Host and render correctly.

The pattern that works well: generate the page in Claude or v0, download the HTML file, upload to a host, share the link. The problem with this loop is that the link is static — when you ask Claude to revise the page, you get a different file and have to share a new URL. Anyone who bookmarked or commented on the first link is now looking at a stale version.

Publishing to a canvas that supports in-place updates solves this: one URL, multiple versions, the client always has the right page.

A note on permanence

Free tiers on most of these services have time limits or traffic caps:

For anything you'll share with a client and expect them to come back to, choose a permanent host or create an account on the free tier.