Working With An HTML File: The Basics Nobody Explains

You have a folder of files and you are not completely sure what any of them are.

Maybe you wrote them. More likely something else did, handed the whole lot over with a cheerful "here is your website", and left you to work out the rest. You double-clicked the one ending in .html, a page opened in your browser, and roughly half of it looked the way it was supposed to.

That is where most people meet an HTML file for the first time. Not in a class and not in a tutorial, but in a folder they did not organise, looking at a page that is nearly right.

So this is the map. Not a coding lesson, and not a step-by-step fix for one specific problem. What the file actually is, how a browser turns it into a page, how the other pieces hang off it, and the one idea that explains most of what goes wrong: paths.

Get those right and the rest of the folder starts to make sense. Get them wrong and you will spend an afternoon convinced the page is broken when it is only lost.

What An HTML File Actually Is

An HTML file is a plain text document that describes a page. That is the whole definition.

You can open one in Notepad or TextEdit and read every character in it. There is nothing compiled, nothing hidden, and no special software needed to write one. Rename notes.txt to notes.html and your computer starts treating the same characters as something a browser should open.

What makes it HTML is the tags. Tags are labels in angle brackets that say what each piece of the text is, and the browser decides how to draw each label.

Here is a complete page. Not a snippet, an entire working document:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My Page</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <h1>Hello</h1>
    <p>This is a paragraph.</p>
    <img src="images/logo.png" alt="Our logo">
    <script src="app.js"></script>
  </body>
</html>

Four parts matter, and once you can name them you can find anything in a file somebody else wrote:

• The doctype. The first line, <!DOCTYPE html>, tells the browser to use modern rules. It is not really a tag and it never changes. Copy it and move on.
• The head. Instructions about the page. The title in the browser tab, the character set, links to stylesheets. Nothing in the head is drawn in the window, which is why beginners often paste content there and see nothing happen.
• The body. Everything a visitor sees. Headings, paragraphs, images, buttons, the lot.
• Paired tags. Most tags open and close: <p> starts a paragraph and </p> ends it. A few do not need closing, like <img>. A missing closing tag does not throw an error message, it just makes the rest of the page inherit something it should not have.

That is genuinely the shape of every page on the internet. The complicated ones are the same four parts with thousands of lines in the body. MDN on basic HTML syntax

The File, The Page And The Site Are Three Different Things

They get used interchangeably and it causes real confusion, because they live in different places and break in different ways.

The distinction that matters most: your file has a location, and your page has an address, and until you host something those are not the same thing at all.

Right now your file lives at something like C:/Users/you/Desktop/my-site/index.html. That is a location on one computer. Nobody else on earth can type it in and reach anything.

A page gets an address when the folder is sitting on a machine that is always on and answering requests. That is all hosting is, and what a static site actually is covers the category properly if you want the longer version.

One folder can hold many pages, and many pages make a site. But it starts as one file that a browser can read.

How A Browser Turns An HTML File Into A Page

The browser reads the file from top to bottom, builds a model of the page out of the tags it finds, and every time it meets a reference to another file it stops and goes to fetch that file too.

Think of it as a shopping list. The HTML is the list. The stylesheets, scripts and images are the items, and the browser has to go and collect each one.

The sequence goes like this:

1. The browser is handed the file, either from your disk or from a server.
2. It reads the tags and builds a structure: this is a heading, this is a paragraph, this is an image slot.
3. Every href and every src it meets is a request for another file, so it fires those off.
4. Stylesheets come back and it repaints everything with the rules they contain.
5. Scripts come back and it runs them, which can change the page again.
6. Images and embedded files arrive and drop into their slots.

Two things follow from this, and they explain a lot of confusing behaviour.

First, a missing file is not an error you will see. If the stylesheet does not arrive, the browser does not stop or complain. It just draws the page with no styling at all, which is why a page can look like a wall of black text on white and still be technically working.

Second, the order is why a page sometimes flashes unstyled for an instant before snapping into shape. You are watching step 2 finish before step 4 arrives.

How File Paths Work, And Why They Break

This is the part nobody explains, and it is behind most of the questions people ask about a page that half works.

A Path Is Directions, Not A Name

When you write src="images/logo.png", you are not naming a file. You are giving directions, and the browser follows them starting from the folder your page is in.

That starting point is the whole trick. The same line of code means different things depending on where the page sits, because the directions are always read from wherever the reader is standing.

Move the page one folder deeper and every relative path in it now points somewhere else. Nothing in the file changed. Its starting position did.

The Four Kinds Of Address

There are only four, and they behave differently the moment you move the folder anywhere.

For a folder you are going to upload as one piece, use the relative forms with no leading slash. They mean the same thing on your desktop as they do on a server, so what you tested is what ships.

The leading slash is the one that catches everyone. Locally it points at the root of your drive, so /styles.css goes looking for a file in C:/ and finds nothing. Uploaded, it points at the top of your site and suddenly starts working. That is the exact reason people say their styling "only worked after I put it online".

Your Folder Structure Becomes Your Web Address

This is worth ten minutes of thought before you upload anything, because it is annoying to change later.

The shape of your folder becomes the shape of your URLs, one to one:

my-site/
  index.html          ->  yoursite.com/
  about.html          ->  yoursite.com/about.html
  work/
    index.html        ->  yoursite.com/work/
  images/
    logo.png          ->  yoursite.com/images/logo.png
  brochure.pdf        ->  yoursite.com/brochure.pdf

Two rules fall out of that. A file called index.html is the default page for whatever folder it sits in, which is why the top-level one answers the bare address and why work/index.html gives you a clean /work/ link with no filename showing.

And renaming a folder renames every address inside it. If you have already sent someone a link, that link is now dead. Decide on your folder names while nobody is looking.

Case Only Starts Mattering When You Move

Logo.png and logo.png are the same file on Windows and on a standard Mac. On almost every web server they are two different files, because servers run Linux and Linux counts capital letters as part of the name.

So this is a bug that cannot exist on your machine and appears the second you upload. The page was perfect for a week, nothing changed, and the images are gone.

Name everything in lowercase, use hyphens instead of spaces, and copy filenames rather than retyping them. That habit costs nothing and removes an entire category of problem.

Opening A File Is Not The Same As Visiting A Page

Double-click your page and look at the address bar. It says file:///C:/Users/you/... rather than https:// anything, and that difference is bigger than it looks.

With file:// there is no server involved. The browser is reading straight off your disk. There is no site, so there is no site root, which is why leading-slash paths fail locally. There is also no origin, and a lot of browser security rules are built around what origin a page came from.

Practically, these behave differently on your desktop than they will once hosted:

• Paths that start with a slash, as above.
• JavaScript modules, which browsers refuse to load over file:// entirely.
• Any script that tries to fetch a local data file, such as a .json or a .csv, which gets blocked.
• Embedded PDFs and some media, depending on the browser.

None of that means your page is broken. It means a local preview is an approximation, and the real test is the hosted version. Opening a page properly in Chrome, and reading the console when something does not load, is a small subject of its own and worth learning before you blame the file.

Where CSS, JavaScript, Images And PDFs Attach

Everything else in your folder connects to the page through one line of HTML. Here is the map of what connects to what, at the level you need to recognise it in somebody else's code.

Stylesheets

A stylesheet is a separate .css document holding all the colours, spacing and layout. It attaches in the head with a single line:

<link rel="stylesheet" href="styles.css">

Change that one file and every page pointing at it changes. That is the entire reason CSS lives outside the HTML instead of inside it. When styling does not apply, the cause is nearly always the href pointing somewhere the file is not, and telling a wrong path apart from a wrong style rule is its own short investigation.

Scripts

JavaScript is what makes a page do things after it has loaded: menus that open, forms that validate, counters that count. It attaches with a script tag, normally just before the closing body tag:

<script src="app.js"></script>

Two things about that line surprise people. The closing </script> is mandatory even though there is nothing between the tags, and a self-closed version silently swallows the rest of your page. And position matters, because a script that runs before the elements it wants to touch exist will simply do nothing, with no error a normal person would notice.

Images

Images are files sitting in your folder that the page points at:

<img src="images/logo.png" alt="Our logo">

The alt text is not optional in any sense that matters. It is what a screen reader announces and what shows when the image does not load.

One trap specific to this decade: if an AI tool showed you a picture in a chat window, the src may point at a temporary address inside that session which will expire. Download the image, put it in your folder, and point at it locally. pages an AI handed you goes through what usually arrives in those folders.

PDFs

A PDF is never inside the page. It sits beside it as its own file, and the page shows it in a frame:

<iframe src="brochure.pdf" width="100%" height="600"></iframe>

Which means the PDF needs its own address once you go live, exactly like an image does. Upload the folder and it gets one. If the PDF is the entire point and there is no page around it, you do not need HTML at all, and putting a PDF online on its own is the shorter path.

What Breaks, And Why

Nearly every problem in a folder of web files is one of six things. This table is the one I would keep.

The pattern behind five of those six is the same: something asked for a file and the file was not where the directions said. Before you rewrite any code, check the path, then check the capitals, then check that the file is actually in the folder you uploaded.

What An HTML File Cannot Do, No Matter Where You Put It

A static page is served, not run. The server hands over the file exactly as it is stored and does no thinking on the way out. That single sentence explains every limit below, and it is better to know now than three weeks in.

So it cannot, on its own:

• Log people in or remember who they are
• Read or write a database
• Run PHP, WordPress plugins, or anything else on the server
• Email you when somebody submits a form, unless a form service or your host handles it
• Show different content to different visitors, beyond what JavaScript can do in their own browser

That form point catches people constantly. A <form> in plain HTML on a static host does nothing at all when submitted. It needs a handler somewhere else, and every host does that differently.

If your project genuinely needs a database or a WordPress plugin, static hosting is the wrong tool and OxyPages is the wrong tool with it. You need an application platform, and no amount of clever file arrangement substitutes for one.

For everything else, which is most brochure sites, portfolios, event pages, one-page sites and anything an AI just built you, static is faster, cheaper and has almost nothing in it to attack.

What To Do Next

You now have the map. The useful next move is small.

1. Open your folder and look at what is in it. Find the file named index.html, and note every other file sitting beside it.
2. Open that page in a text editor and search for src= and href=. Every one of those is a path, and every path is a thing that can break.
3. Make the filenames lowercase with hyphens instead of spaces, and fix the paths to match.
4. Upload the whole folder, not one file. This is the single most common mistake and it takes no extra effort to avoid.
5. Open the resulting link on your phone, on mobile data, not on the laptop that still has the original cached.

When you are ready for step four, how to host an HTML file and get a link is the shortest version of the process, and what free plans actually restrict covers where each free tier draws its line. If you want to skip the comparison, drag your folder in and get a live link takes about a minute and keeps the folder structure exactly as it is on your desk.

The four subjects this page pointed at, linking a stylesheet, adding a script, opening a page properly in Chrome, and embedding a PDF, each have a lot more to say than a paragraph. But they all rest on the same idea, and you have it now: the file is a set of directions, and the directions are read from wherever the file happens to be standing.