Files with a purpose

Multi-File HTML Editor

Build a multi-file HTML project in HCODX. Organize pages, CSS, JavaScript and images, check relative paths and export the complete folder structure.

Open project workspaceSee a file plan
Project treeRelative pathsZIP export
Start with ownership

Separate files when they have separate responsibilities

A multi-file project is easier to navigate only when its structure is predictable.

One large HTML file is convenient for a throwaway experiment. For a site with two pages, repeating the same style block in both files becomes error-prone. A shared stylesheet gives both pages the same visual rules and makes a design edit easier to review.

Keep page-specific text and semantic structure in each HTML document. Static HTML does not magically share a header component between files; if you duplicate that markup, you must update every copy or move to a templating/build system after export.

Pages

Give each document a clear filename and unique title and main heading.

Shared CSS

Place design tokens and reusable component rules in one stylesheet.

Assets

Use predictable filenames and verify image paths after moving files.

The path rule

Read paths from the file that references them

Relative URLs are the most common source of a preview that looks right on one page and broken on another.

In index.html at the root, styles/site.css is a path down into the styles folder. In pages/about.html, that same stylesheet is one folder up, so the relative path is ../styles/site.css. The browser does not search the project tree for a matching filename.

Choose either clear relative paths or a deployment-aware root path. Before publishing, inspect every page—not only index.html—because a nested page may have a different path to the same asset.

The ../ prefix moves from pages/ back to the project root before following the shared asset path.
<!-- index.html at the project root -->
<link rel="stylesheet" href="styles/site.css">
<script src="scripts/menu.js" defer></script>
<img src="images/logo.svg" alt="Site name">

<!-- pages/about.html, one folder deeper -->
<link rel="stylesheet" href="../styles/site.css">
<script src="../scripts/menu.js" defer></script>
<img src="../images/logo.svg" alt="Site name">
URL anatomy

Three asset paths that look similar but resolve differently

A link can be syntactically valid and still point to the wrong file after export or deployment.

Compare

Relative: styles/site.css

Resolved from the document that contains the link. From index.html at the root it reaches styles/site.css; from pages/about.html it would look for pages/styles/site.css instead.

Compare

Parent-relative: ../styles/site.css

Moves one directory up before following the rest of the path. This is the correct form for pages/about.html when styles/ is beside pages/.

Compare

Root-relative: /styles/site.css

Starts at the current web origin root. It can be convenient on a deployed root-domain site but may fail for file:// viewing or a site hosted below a subpath.

Compare

Absolute URL: https://example.com/site.css

Points to one specific origin. Use it deliberately for an external resource, knowing that availability, CORS policy and privacy may differ from a local asset.

Shared code, different pages

Make a shared script tolerant of page-specific elements

A shared JavaScript file should not crash on pages that do not include every component.

Suppose index.html has a signup button but pages/about.html does not. Both pages can link scripts/site.js, yet an unconditional addEventListener call on a missing button throws before later shared code can run. Check whether the element exists before binding behavior that belongs to only one page.

Keep the HTML path to the script correct on both pages. From the project root, scripts/site.js is direct; from pages/about.html, ../scripts/site.js climbs one folder. Test both entries after export rather than checking only the homepage.

The existence check lets the shared script load on pages with and without #signup.
<!-- index.html -->
<script src="scripts/site.js" defer></script>

<!-- pages/about.html -->
<script src="../scripts/site.js" defer></script>

// scripts/site.js
const signup = document.querySelector("#signup");
if (signup) {
  signup.addEventListener("click", () => {
    signup.textContent = "Thanks for your interest";
  });
}
Release check

Check the project as a set, not as a single preview

A ZIP is useful only if the linked pages and assets survive outside the editor.

Open each page Check titles, navigation and images on index.html and every nested document.
Inspect shared files Change a visible CSS value once and confirm all intended pages update.
Export and unpack Download the ZIP, inspect the folder tree and open a self-contained page locally.
Identify server-only features Fetch calls, server routes and backend templates require an appropriate host; a ZIP alone does not provide a server.
Project questions

Multi-file editing answers

Yes. Link the same script from each page with the correct relative path. Make the script tolerant of elements that appear on only one page.

Every page that links that stylesheet will load its current rules. Verify that pages in nested folders use the correct path.

No. Plain static HTML cannot include another document as a component by itself. Use a template or build step when repeated markup becomes costly.

Its relative path starts from the nested page, not from index.html. A file in pages/ usually needs ../styles/site.css to reach a stylesheet stored at the project root.

Confirm that every intended page, stylesheet, script and asset is present, and open more than one page. A successful ZIP download does not prove its internal links are correct.

Only if your deployment origin and base path match that assumption. Relative paths are more portable when a project may be opened locally or hosted below a subpath.
Related Tools

Explore the Full HCODX Suite

Download Your Project

Download your HCODX project as a ZIP with HTML, CSS, JavaScript and assets. Check the exported paths before moving the files to another editor or host.

HTML, CSS and JavaScript Editor

Build interactive pages with the HCODX HTML, CSS and JavaScript editor. Link your files, preview button behavior and inspect console output.

HTML Validator

Check HTML errors with the HCODX editor validator. Learn how to run Validate HTML, read diagnostics and fix nesting, duplicate IDs and form labels.

HTML File Viewer

Open a local HTML file in the HCODX file viewer without uploading it. Preview self-contained HTML and inline CSS in an isolated static frame.

JavaScript Console

Use the HCODX JavaScript console to inspect logs, read errors and debug event handlers while your HTML project runs in preview.

Save HTML Files

Learn how HCODX saves HTML files in your browser, how to reopen your project and when to download a backup before clearing site data.

Create a project with a real structure

Start with two pages and one shared stylesheet, then verify every relative path.

Open HCODX editor

Instant HTML Runner & Viewer with Live Preview

Need to run a short HTML, CSS and JavaScript snippet? The HTML Runner Online has a focused editing surface with live output.

Open HTML Runner Online