What is an HTML file?

HTML is a plain-text format you can open in any editor. It can hold both pixels and drawn shapes on the same page. It is used for the web and editing.

The extension is .html, and the full name is HyperText Markup Language. Both matter less than what the file can hold, which is what the rest of this page is about.

It comes from WHATWG. The specification is HTML Living Standard.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

Visual Studio Code and Google Chrome read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

Every current browser reads it.

That makes it a safe thing to put on a page or attach to a message without wondering what the other end has installed.

HTML is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

This is the one thing to understand about HTML, and nearly every difficulty with it follows from here. An HTML file contains the text and the structure — headings, paragraphs, tables, links — and points at everything else. The stylesheet that makes it look designed is a separate file. So are the images, the fonts, the scripts and anything loaded from another server.

So an HTML file saved on its own and opened later shows the content with none of the appearance: unstyled headings, missing pictures, a page that looks like 1994. Nothing is corrupted. The references simply lead nowhere, because the things they point at were never in the file.

Browsers know this, which is why saving a page produces an HTML file and a folder beside it with a matching name, holding the images and stylesheets. The two travel together or not at all — email the HTML on its own and the recipient gets the unstyled version.

Most browsers also offer a single-file option, sometimes called "Web page, complete" or MHTML, which packs everything into one file. It solves the transport problem and creates a new one: the result is only reliably readable in a browser from the same family. For handing a page to somebody, PDF is the format that actually behaves — one file, everything embedded, and it looks the same for everyone.

Converting a document format usually means mapping one set of structures onto another. Converting HTML to PDF is different: the page has to be laid out first, because nothing in the file says how wide anything is. A browser decides that from the window size, the stylesheet and the fonts available, and only then are there positions to put on a page.

This is why the same page produces different PDFs in different tools, and why a page that depends on a script to build its content can come out empty. It is also why print stylesheets exist — a well-made site has a set of rules for what the page should look like on paper, and a converter that respects them produces a far better result than one that photographs the screen.

Email. Almost every marketing message and notification is HTML, written against a much older and stranger subset than a web page uses — layout tables, inline styles, and none of the modern features, because email clients render with engines that stopped developing a long time ago. An HTML file exported from a mail client will look wrong in a browser for that reason, and it is not a fault in the export.

Documentation and reports are the other big use. Anything generated by a tool — test results, coverage reports, analytics exports, e-book chapters — tends to be HTML, because every machine can display it without licensing anything. EPUB, the e-book format, is a ZIP of HTML files with a manifest.

An HTML file is text, which means somebody has to decide how the letters are stored, and the file declares it in a meta tag near the top. Get that declaration wrong and accented characters, curly quotes and every non-Latin script come out as question marks, black diamonds or pairs of nonsense letters.

UTF-8 is the answer everywhere now, and a file without a declaration is being guessed at by whatever opens it. If a page looks fine in one browser and mangled in another, this is nearly always why — the file, not the reader, is missing the information.

It is text, so any editor works. An editor built for code adds two things worth having: it colours the tags so structure is visible at a glance, and it points out an unclosed element before you spend twenty minutes wondering why half the page is bold.

What no editor can do is protect you from the browser being forgiving. HTML has no strict parser — a malformed page is not rejected, it is repaired according to rules, and the repair may not be what you meant. A page that looks right is not evidence that the markup is right, which is what validators are for.

HTML itself is safe. It is the most widely implemented format in existence, it is specified in public, and a document written in 1995 still renders. The risk is everything around it: a page whose layout depends on a script from a content delivery network, or whose images sit on a server, becomes an empty shell the moment either disappears.

For an archive, convert to PDF — the layout and every asset end up inside one file that needs nothing but a reader. Keep the HTML too, since it is the version that can still be searched, edited and re-rendered. The pair together is the durable answer; either alone is a compromise.