Single HTML File vs Zip: Which Should You Share?

· · Updated

An HTML page is either one file that carries everything it needs, or a folder of files that depend on each other. Which of the two you have determines how you share it, and getting it wrong is the most common reason a shared page renders unstyled. This is how to tell which you have and what to do with each.

The Problem

HTML references other files by relative path. <link href="styles.css"> means “a file called styles.css next to me.” That reference works as long as the neighbour is actually there.

Send the HTML file on its own and every one of those references fails. The browser asks for styles.css, gets a 404, and renders the page with no styling at all: black text on white, single column, default fonts, broken image icons.

The page is not corrupted. It is complete and it is missing its context. From the recipient’s side this looks like you sent something broken, and the fix — “can you also send the CSS?” — costs a round trip and often two, because there is usually a JavaScript file and an images folder as well.

How to Tell Which You Have

The test takes ten seconds:

  1. Create an empty folder.
  2. Copy only the HTML file into it.
  3. Open it in a browser.

If it looks and behaves correctly, it is self-contained. If styling, images, or interactivity disappear, it has external dependencies.

That is the whole diagnostic. It is more reliable than reading the source, because it catches the dependencies you forgot about — a font file, a favicon, a background image referenced from inside the CSS.

What makes a file self-contained

  • Styles inside <style> tags rather than a linked .css file
  • Scripts inside <script> tags rather than a linked .js file
  • Images as data URLs, or hotlinked from a public URL
  • Fonts from a CDN, or system fonts

Pages generated by AI tools are usually built this way, which is why they are so easy to share. Everything is in one document by design.

What makes it a folder

  • <link rel="stylesheet" href="...">
  • <script src="..."> pointing at a local file
  • <img src="images/...">
  • @font-face with a local url(...)
  • Anything built by a bundler — a dist/ or out/ folder is always multi-file

Sharing Each One

Single file

Upload the .html file. That is it. It renders wherever it is served from, and it survives being moved, copied, and re-uploaded.

Folder

Zip it, and get the structure right. The archive must have index.html at the top level:

site.zip
├── index.html
├── styles.css
└── images/
    └── logo.png

Not this:

site.zip
└── my-site/
    ├── index.html
    └── styles.css

The second is what you get by right-clicking the folder and choosing Compress, and it is the single most common upload mistake in this whole category. The host looks for index.html at the root, finds a directory instead, and serves a listing or a 404. Select the contents of the folder and compress those.

Two related snags worth checking before you upload:

Absolute paths. /assets/logo.png assumes the site lives at a domain root. Served from a subpath, it 404s. Relative paths (./assets/logo.png) work anywhere. If you control the build, set the base path to relative and rebuild.

Case sensitivity. Local development on Windows or macOS is usually case-insensitive; most web servers are not. Logo.PNG referenced as logo.png works on your machine and breaks when hosted. This one is genuinely confusing when it happens, because the file is visibly right there.

Should You Convert a Folder Into a Single File?

Sometimes worth it, often not.

Worth it when the recipient may be offline, when you want one artifact that cannot lose its parts, or when the page is small.

Not worth it when there are large images. Inlining an image as a data URL makes it about 33% bigger and prevents it from being cached separately, so a page with a dozen inlined photos loads noticeably slower.

For a review prototype, either is fine — a zip upload is one step and preserves the structure you already have. There is rarely a reason to do the conversion work.

Examples

Getting it wrong

  1. Export a built site to dist/.
  2. Right-click dist → Compress → upload dist.zip.
  3. The link shows a directory listing.
  4. You re-zip from inside the folder, selecting the contents.
  5. Now the page loads, but images are missing — the build used absolute paths.
  6. Set the base to relative, rebuild, re-upload.

Three uploads.

Getting it right

  1. Run the ten-second test: the HTML alone in an empty folder is unstyled, so it is a folder job.
  2. Open dist/, select all its contents, compress those.
  3. Confirm the zip has index.html at the top level.
  4. Upload. Page renders first time.

Summary

  • Run the empty-folder test before sharing — it tells you in ten seconds whether you have one file or a folder.
  • Check the zip has index.html at the root — compressing the parent folder is the most common cause of a broken upload.
  • Avoid absolute asset paths — a relative base path is what makes a build work regardless of where it is served from.

Next: the step-by-step guide to share an HTML file, single file or zipped folder.

Frequently Asked Questions

When should you share a single HTML file?

When the page is genuinely self-contained: styles in a style tag, scripts in a script tag, and no local image or font files. If it renders correctly after being moved to a different folder on its own, it is self-contained.

When do you need a zip instead?

As soon as the HTML references anything alongside it — a stylesheet, a script file, images, fonts. Those relative paths only resolve if the whole folder structure travels together.

How do you tell whether an HTML file is self-contained?

Copy the file alone into an empty folder and open it. If it still looks and behaves right, it is self-contained. If styling or images disappear, it has external dependencies.

How should the zip be structured?

With index.html at the top level of the archive, not nested inside a wrapper folder. Zipping the parent directory is the most common upload mistake and produces a directory listing or a 404 instead of the page.

Does bundling everything into one file have downsides?

Yes. Inlined images as data URLs are roughly a third larger than the original files and cannot be cached separately, so a heavily inlined page loads slower. For a review prototype that tradeoff is almost always worth it.

More on this topic: Sharing HTML Files

A

Founder at Undraft · Product manager

Built Undraft after watching prototype review break down into screenshots and ZIP attachments one too many times. Writes from direct experience running the product.

More posts by Ari Kliger