Every website you've ever visited started as a simple text file with an .htm or .html extension. That's it. No special software license, no server subscription, no computer science degree. Just a plain text file that a browser knows how to read. If you've been curious about how to make an HTM file from scratch, you're closer to building your first web page than you probably think. The whole process takes about five minutes, and by the end, you'll have a working page you can open in Chrome, Firefox, Safari, or any other browser on your machine.
The reason this skill matters goes beyond casual curiosity. Understanding how HTML files work gives you a foundation for everything else on the web: CSS styling, JavaScript interactivity, frameworks, content management systems. All of those tools eventually produce HTML that a browser renders. Starting at the source means you actually understand what's happening under the hood, which makes debugging easier and learning new tools faster. Whether you want to build a personal portfolio, prototype a landing page, or just grasp what your developer colleagues are talking about, creating an HTML file by hand is the single best place to begin.
Here's the entire process broken into five clear steps, each one building on the last.
Choose Your Text Editor
Before you write a single line of code, you need a place to write it. An HTML file is just a plain text document, so technically anything that can produce unformatted text will work. But your choice of editor affects how fast you work, how many typos you catch, and how much you enjoy the process. Think of it like writing an essay: you could scratch it onto a napkin, but a decent notebook makes the experience far better.
The good news is that you already have at least one usable editor installed on your computer right now. And if you decide to grab a free professional tool, the setup takes less than two minutes.
Using Default System Tools
On Windows, Notepad ships with every installation. You can find it by searching "Notepad" in the Start menu. It's bare-bones: no syntax highlighting, no auto-complete, no line numbers. But it produces clean plain text, which is exactly what an HTML file requires. For a first project, Notepad gets the job done without any distractions.
On macOS, TextEdit is the built-in option, but there's a catch. TextEdit defaults to Rich Text Format, which embeds invisible formatting data that will break your HTML. You need to switch it to plain text mode before you start. Open TextEdit, go to Format in the menu bar, and click "Make Plain Text." You can also set this as the default in TextEdit's preferences under the "New Document" tab by selecting "Plain Text." Skip this step and your file will look like gibberish in a browser.
Linux users typically have access to editors like gedit, nano, or vim depending on the distribution. Any of these work fine for creating HTML files.
Professional Code Editors
If you plan to write more than one file, a proper code editor saves real time. Visual Studio Code (VS Code) is the most popular free option, and for good reason. It gives you syntax highlighting so your tags appear in different colors, auto-closing tags so you don't forget a closing bracket, an integrated terminal for running commands, and a massive library of extensions. Download it from code.visualstudio.com, install it, and you're ready in about 90 seconds.
Other strong free options include Sublime Text, Atom (though it's been sunset by GitHub, archived versions still float around), and Brackets. Sublime Text is especially fast and lightweight if VS Code feels heavy on an older machine.
Here's a practical tip: if you're on a Chromebook or a shared computer where you can't install software, browser-based editors like CodePen or JSFiddle let you write HTML directly in a browser tab. They won't produce a local file, but they're great for experimenting.
Pick whichever editor feels comfortable. The HTML you write will be identical regardless of the tool.
Write the Basic HTML Structure
Every HTML document follows a specific skeleton. Browsers are forgiving enough to render incomplete markup, but starting with the correct structure prevents weird behavior and ensures your page displays consistently across different browsers and devices. Think of this structure as the framing of a house: you can decorate later, but the walls need to go up first.
Essential Boilerplate Tags
Open your text editor and type the following:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My First Page</title>
</head>
<body>
</body>
</html>
Each line has a specific job:
<!DOCTYPE html>tells the browser this is an HTML5 document. Without it, the browser may switch to "quirks mode," which renders pages using outdated rules from the early 2000s. Always include this first.<html lang="en">is the root element that wraps everything. The lang attribute tells screen readers and search engines what language your content uses.<head>contains metadata: information about the page that doesn't appear visually. The charset declaration ensures special characters render correctly. The viewport meta tag makes the page responsive on mobile devices. The title tag sets the text that appears in the browser tab.<body>is where all visible content goes. Anything you want a visitor to actually see on the page belongs between the opening and closing body tags.
This boilerplate is the same for virtually every HTML page on the internet. Memorize it or save it as a template file you can copy for new projects.
Adding Visible Content
With the skeleton in place, put something between the body tags so you can actually see results. A heading and a paragraph are the simplest starting point:
<body>
<h1>Hello, World!</h1>
<p>This is my first web page. I built it from scratch.</p>
</body>
The <h1> tag creates a top-level heading. Browsers render it large and bold by default. The <p> tag creates a paragraph of regular text. You can add as many of these as you want.
Try adding a few more elements to see how they behave. An unordered list uses <ul> with <li> items inside it. A link uses <a href="https://example.com">link text</a>. An image uses <img src="photo.jpg" alt="description">. Each of these tags follows the same pattern: an opening tag, content, and a closing tag (except self-closing tags like img).
Don't worry about making it look pretty yet. Raw HTML without any CSS styling looks like a college paper from 1996, and that's perfectly fine at this stage. The goal right now is getting a functional file that the browser can read.
Save the File with the Correct Extension
This is the step where most beginners hit their first real snag. You've written valid HTML, but if you save the file incorrectly, your browser won't recognize it as a web page. The file extension and the text encoding both matter.
Naming Your Homepage
When you save your file, the name needs to end in either .html or .htm. Both extensions work identically. The .htm extension is a holdover from early Windows systems that limited extensions to three characters. Modern systems have no such restriction, so .html is more common today, but .htm is equally valid. Use whichever you prefer and stay consistent across your project.
For your very first file, name it index.html (or index.htm). The name "index" has special meaning in web hosting: when someone visits a directory on a web server without specifying a file name, the server looks for index.html by default. Getting into the habit of naming your main page "index" saves confusion later.
A few naming rules to follow: use lowercase letters, avoid spaces (use hyphens instead, like about-us.html), and stick to alphanumeric characters. A file named "My Cool Page!.html" will technically work on your local machine but can cause problems on web servers and in URLs.
Ensuring Plain Text Formatting
In Notepad on Windows, go to File, then Save As. In the "Save as type" dropdown, select "All Files" instead of "Text Documents." Then type your full file name including the extension: index.html. If you leave the dropdown on "Text Documents," Notepad may silently append .txt to your file name, giving you index.html.txt, which browsers won't treat as HTML.
Set the encoding dropdown to UTF-8. This matches the charset declaration in your HTML head and ensures characters like accented letters, currency symbols, and emoji display correctly.
In TextEdit on macOS, after switching to plain text mode, use File then Save. Change the file extension from .txt to .html. macOS will ask if you want to use .html: confirm that you do. If TextEdit keeps reverting to .txt, try using "Save As" and manually typing the full file name.
In VS Code or other code editors, this is simpler. Just type the file name with the .html extension when you first save, and the editor handles encoding automatically. VS Code defaults to UTF-8, which is exactly what you want.
Save your file somewhere easy to find: your Desktop or a dedicated "projects" folder works well.
Open the HTML File in a Web Browser
Here's the payoff. Find the file you just saved, and double-click it. Your default web browser should open and display your heading and paragraph. If you see the raw code instead of a rendered page, the file extension is wrong: go back and re-save with the correct .html or .htm extension.
You can also open the file by launching your browser first, then pressing Ctrl+O (Cmd+O on Mac) and browsing to the file. Or drag the file directly onto an open browser window. All three methods produce the same result.
Look at the address bar. You'll see something like file:///C:/Users/yourname/Desktop/index.html on Windows or file:///Users/yourname/Desktop/index.html on Mac. The file:// protocol means the browser is reading directly from your local disk rather than fetching the page from a remote server. This is perfectly normal for local development.
Your page will look plain. Black text on a white background, a big heading, a small paragraph. No colors, no fancy fonts, no layout. That's expected. All the visual polish comes from CSS, which you'll add later. Right now, you've confirmed that your HTML is valid and your browser can read it.
Try right-clicking anywhere on the page and selecting "View Page Source" or "Inspect." You'll see the exact code you wrote. This is a great habit to build: inspecting source code on any website teaches you how other developers structure their pages. Every site on the internet, from a simple blog to a complex web app, has viewable source code.
If the page is blank, check that you actually put content between the body tags. If the title shows in the tab but nothing appears on the page, your content might be accidentally placed inside the head section instead of the body.
Edit and Refresh Your Project
Web development has one of the fastest feedback loops of any creative discipline. Change a line of code, save the file, refresh the browser, and you see the result instantly. No compiling, no building, no waiting.
Go back to your text editor and make a change. Add a second paragraph, change the heading text, insert an image tag. Save the file with Ctrl+S (Cmd+S on Mac). Switch to your browser and press F5 or Ctrl+R (Cmd+R on Mac) to reload the page. Your changes appear immediately.
This edit-save-refresh cycle is the core workflow for front-end development, and it stays relevant even as your projects grow more complex. Professional developers use the same loop, often enhanced with tools like "live reload" that automatically refresh the browser whenever a file changes. VS Code has an extension called Live Server that does exactly this: install it, right-click your HTML file, select "Open with Live Server," and every save triggers an automatic browser refresh. It shaves a few seconds off each cycle, which adds up fast.
A practical exercise: try building a simple "About Me" page. Include an h1 with your name, a paragraph about yourself, an unordered list of hobbies, and a link to a website you like. Each time you add an element, save and refresh to see how the browser renders it. This hands-on repetition is how the tag syntax moves from something you look up to something you just know.
Keep your text editor and browser open side by side. On Windows, snap them to each half of the screen with the Windows key plus arrow keys. On macOS, use Split View. This dual-pane setup lets you see code and output simultaneously, which speeds up the learning process significantly.
Common Troubleshooting and Next Steps
Even with a process this straightforward, things go sideways sometimes. Most problems fall into a handful of categories, and once you've seen each one once, you'll spot them in seconds.
Fixing Broken Tags
The single most common HTML error is a missing closing tag. Every tag you open needs to be closed, with a few exceptions like img, br, and hr. If your page looks strange, like all the text suddenly appears bold or a section seems to swallow the rest of the page, look for an unclosed tag.
Here's a quick example of broken markup:
<p>This is a paragraph.
<p>This is another paragraph.</p>
The first paragraph tag is never closed. Browsers will usually guess what you meant and render it okay, but "usually" isn't "always." Get into the habit of typing both the opening and closing tag before filling in the content between them. In VS Code, the editor does this automatically when you type an opening tag.
Another frequent mistake is mismatched nesting. Tags need to close in the reverse order they opened. This is correct: <p><strong>bold text</strong></p>. This is wrong: <p><strong>bold text</p></strong>. The strong tag opened second, so it needs to close before the paragraph tag closes. Think of it like stacking boxes: the last one you put on top comes off first.
Typos in tag names cause silent failures. If you type <h1> but close with </h2>, the browser won't match them. Use your editor's syntax highlighting to catch these: mismatched tags often show up in unexpected colors.
Validation tools can help too. The W3C Markup Validation Service at validator.w3.org lets you paste your HTML and get a list of errors. It's free and catches problems you might miss by eye.
Transitioning to CSS and JS
Once you're comfortable creating and editing HTML files, the natural next step is CSS for styling and JavaScript for interactivity. Both work alongside HTML and follow a similar file-based workflow.
CSS controls how your page looks: colors, fonts, spacing, layout. You can add CSS directly inside a style tag in your HTML head, or create a separate .css file and link to it with <link rel="stylesheet" href="styles.css">. The separate file approach is better for any project beyond a single page because it lets you share styles across multiple HTML files.
JavaScript adds behavior: responding to button clicks, validating form input, fetching data from APIs, animating elements. Like CSS, you can write JavaScript inline using a script tag or link to an external .js file. Place script tags just before the closing body tag so the HTML content loads before the script runs.
A reasonable learning path looks like this: spend a week building simple HTML pages to get the tags memorized. Then add CSS to one of those pages and experiment with colors, fonts, and basic layout using flexbox. After that, write a small JavaScript function, maybe a button that changes the page's background color when clicked. Each layer builds on the one before it, and because you started with raw HTML, you understand what each layer actually does.
Free resources for continued learning include MDN Web Docs (developer.mozilla.org), freeCodeCamp, and The Odin Project. MDN in particular is the reference documentation that professional developers use daily. Bookmark it.
Where to Go From Here
You now know how to create an HTM file from a blank document, structure it with valid HTML5 boilerplate, save it with the right extension and encoding, view it in a browser, and iterate on it with the edit-save-refresh cycle. That's a complete workflow, and it's genuinely the same process working developers use every day, just with more files and fancier tools.
The best thing you can do right now is build something. Don't just read about HTML: open your editor and make a page. A recipe, a fan page for your favorite band, a list of books you've read this year. The subject doesn't matter. What matters is the repetition of writing tags, saving files, and seeing results. Every professional web developer started exactly where you are: staring at a blank text file, typing that first doctype declaration, and watching a heading appear in a browser window. Start small, stay curious, and build from there.
0 Comments
Post a Comment