HTML, explained: the skeleton of every webpage

In one sentence

HTML (HyperText Markup Language) is the standard text-based language used to create and structure the content you see on a webpage, a bit like a blueprint for a building.

The problem it solves

Picture the world before the web as we know it: a digital Wild West of disconnected documents. If you were a physicist at one university, sharing your latest research paper with a colleague across the ocean was a mess. You'd email a file, but they might not have the right software to open it. The formatting would be all wrong. There were no universal links, no easy way to jump from one document to another related one.

Enter Tim Berners-Lee at CERN in the late 1980s. The problem he faced was getting a bunch of brainy, busy, and geographically scattered scientists to share and access information efficiently. The solution needed to be simple, platform-independent, and robust. He didn't need a fancy page-layout program; he needed a way to mark up a plain text document to give it structure—this is a heading, this is a paragraph, this is a list, and crucially, this text links to that other document over there.

This "linking" part was the magic ingredient, the "HyperText" in HTML. Drawing inspiration from an older, more complex system called SGML, Berners-Lee created a simplified version that was easy for humans to write and, just as importantly, easy for a computer program (a "browser") to parse and display.

HTML solved the problem of a universal document format for the internet. It created a common language that any machine could understand, turning a chaotic collection of files into an interconnected "web" of information. It wasn't designed to be pretty—that would come later with CSS—it was designed to be functional, descriptive, and to connect the world's knowledge.

How it works under the hood

So how does a simple text file full of angle brackets become the rich, interactive webpage you're reading right now? It's a fascinating journey from text to pixels, involving a few key concepts.

### Tags, Elements, and Attributes: The Building Blocks

At its core, HTML is just text with special instructions called tags. A tag is usually a short, memorable keyword wrapped in angle brackets, like <p>.

Most tags come in pairs: an opening tag (<p>) and a closing tag (</p>). Everything in between—the tag pair and its content—is called an element.

<p>This whole line is a paragraph element.</p>

Tag: The <p> and </p> parts are the tags. They signal the start and end of a paragraph.
Content: The text "This whole line is a paragraph element." is the content.
Element: The opening tag, content, and closing tag together form the <p> element.

Some elements are "void" or "empty," meaning they don't have content or a closing tag because they represent a single, self-contained thing, like an image <img> or a line break <br>.

To add more information to an element, we use attributes. These are name="value" pairs that live inside the opening tag and provide extra configuration. The most famous example is the hyperlink:

<a href="https://flowing.dev">Visit FlowingDev</a>

Here, <a> is the tag for an anchor (a link), but it's useless on its own. The href attribute tells the browser where the link should go.

### The DOM Tree: From Text to a Family Tree

When your browser receives an HTML file, it doesn't just read it line-by-line like a novel. It immediately starts parsing the text to build a logical, in-memory representation of the document's structure. This structure is called the Document Object Model, or DOM.

The best way to think of the DOM is as a family tree. The <html> element is the great-ancestor of everything. It has two direct children: <head> (for metadata like the page title) and <body> (for the visible content). The <body> element then has its own children, like headings <h1>, paragraphs <p>, and lists <ul>, which in turn can have their own children.

Consider this simple HTML:

<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>A Main Heading</h1>
    <p>Some text and a <a href="#">link</a>.</p>
  </body>
</html>

The browser turns that text into this logical tree structure:

  html
  ├── head
  │   └── title
  │       └── "My Page"
  └── body
      ├── h1
      │   └── "A Main Heading"
      └── p
          ├── "Some text and a "
          └── a (href="#")
              └── "link"
          └── "."

This tree is everything. It's not the visual page yet, but it's the structured model that the browser uses for the next steps. When JavaScript needs to change something on the page or CSS needs to apply a style, they aren't editing a text file; they are interacting with this live DOM tree.

### The Browser's Rendering Pipeline

Once the DOM tree is built, the browser kicks off a sequence of events to actually draw pixels on your screen. An HTML viewer is essentially a miniature version of this pipeline.

Parsing: As we saw, the browser parses the HTML text to build the DOM tree. At the same time, it does the same for any CSS it finds, building a "CSSOM" (CSS Object Model).
Style Calculation: The browser combines the DOM and CSSOM to create a "Render Tree." This tree includes only the elements that will actually be displayed and knows which CSS styles apply to each one. For example, it figures out that the <h1> node from our DOM should be font-size: 2em and font-weight: bold.
Layout (or "Reflow"): Now the browser becomes a geometrist. It walks the render tree and calculates the exact size and position of every single element. "This <h1> is 500px wide and 40px tall, and it sits 20px from the top of the page." It figures out how text wraps, how margins push elements apart, and where everything goes in the viewport.
Painting: With the layout blueprint complete, the browser can finally act as a painter. It "paints" the pixels for each element—text, colors, borders, images—into layers.
Compositing: Finally, the browser takes all the painted layers and composites them together in the correct order to display the final image on your screen. This step is why some elements can appear to slide over or under others.

This whole pipeline, from receiving the first byte of HTML to painting the final pixel, happens in a fraction of a second.

Real-world stories

Theory is great, but HTML's importance really shines through in the trenches.

### The Case of the Runaway Footer

A junior dev, Sam, was going nuts. He'd spent three hours trying to figure out why the website's footer was appearing halfway up the page, smack in the middle of the main content area. The CSS looked right, the template logic seemed fine. In desperation, he viewed the final, rendered HTML source of the page and pasted it into a viewer. Instantly, the visual rendering showed the exact same broken layout. As he scanned the source code next to it, his eyes caught it: a single, unclosed <div> tag, <div class="sidebar". The browser, in its heroic attempt to not crash, made a guess and decided the rest of the page, including the footer, was supposed to be inside that sidebar.

The lesson: Browsers are incredibly lenient with broken HTML, but their error correction can lead to silent, baffling layout bugs. What you meant to write doesn't matter; what the browser parses is the only thing that counts.

### The Disappearing Email Promotion

A marketing team spent a week designing a gorgeous HTML email for a new product launch. In their browser-based editor, it was perfect—animated GIFs, custom fonts, slick buttons. They sent a test campaign. The reports came back: a disaster. For half their audience (especially those on corporate Outlook), the email was a jumbled mess of text, broken image icons, and plain blue links. They had built it like a modern webpage. Using an HTML viewer to simulate a more basic rendering environment, they realized their mistake. Email clients are not modern browsers; they're like digital time capsules from 2005. Fancy <div> layouts, CSS animations, and web fonts were being ignored or stripped out entirely. They had to rebuild it using old-school, bulletproof <table> layouts.

The lesson: The rendering context is king. HTML that works perfectly in Chrome might completely fall apart in a stricter or older environment like an email client.

### The SEO Heist

An e-commerce site's traffic from Google for their top product, "Artisanal Coffee Grinders," suddenly tanked. The page looked identical to users. An SEO consultant, Maria, was called in. She didn't just look at the page; she looked at its bones. Right-clicking "View Source," she copied the HTML. Her analysis was quick: a recent site redesign had replaced the main page title, which was correctly using an <h1>Artisanal Coffee Grinders</h1> tag, with a generic <span class="big-fancy-title">Artisanal Coffee Grinders</span>. To a human, the text looked the same. To Google's crawler, the page no longer had a clear, primary heading. The most important semantic signal for the page's topic had been erased.

The lesson: HTML is not just for styling; it conveys meaning. Using the right tag for the job (semantic HTML) is critical for accessibility and search engine optimization.

Common mistakes and traps

Div-itis: Using <div> for everything is a classic mistake. Need a button? Use <button>. Need a navigation bar? Use <nav>. Need a list? Use <ul>. Using semantic tags makes your site more accessible to screen readers and more understandable to search engines.
Forgetting alt text: Every <img> tag that conveys information should have an alt attribute describing the image. If the image fails to load, the alt text is shown. More importantly, it's what screen readers announce to visually impaired users. alt="" is for purely decorative images.
Improper nesting: Tags must be closed in the reverse order they were opened. <b><i>Bold and Italic</i></b> is correct. <b><i>Bold and Italic</b></i> is broken. Modern browsers will often render it correctly, but it's technically invalid and can cause unpredictable behavior, especially with complex DOM manipulation.
Using block elements inside inline elements: You shouldn't put a block-level element (like a <div> or <p>) inside an inline element (like a <span> or <a>). While browsers might render it, it violates the HTML standard and can lead to strange layout and styling issues.
Assuming it will look the same everywhere: The beauty and curse of the web is that your HTML is rendered by dozens of different browser engines on thousands of different devices. What looks perfect in your viewer or on Chrome for desktop might look slightly different in Safari on iOS. Always test on key target devices.

Why it belongs on your radar

Whether you're a hardcore backend engineer, a data scientist, or a UI/UX designer, you can't escape HTML. It's the lingua franca of the web.

For Debugging: When your fancy JavaScript framework spits out a weird UI, the buck stops with the HTML it generated. Being able to read and understand the final DOM is a fundamental debugging skill.
For Performance: Bloated, deeply nested HTML leads to slower layout and paint times. Understanding HTML structure is the first step toward building fast, responsive sites.
For Security: Misunderstood HTML can lead to security holes. For example, if you're injecting user-provided data into your HTML without properly sanitizing it, you could be vulnerable to Cross-Site Scripting (XSS) attacks.
For Communication: When a designer hands you a mockup, or you need to explain a frontend bug to a colleague, being able to talk fluently about HTML elements, attributes, and the DOM tree makes the conversation ten times more effective.

In short, if your work touches a web browser in any way, a solid grasp of HTML fundamentals is not optional—it's foundational.

Go deeper

MDN Web Docs: HTML basics - The absolute best place to start for any web developer. Clear, comprehensive, and full of examples.
HTML Living Standard (WHATWG) - The official, canonical specification for HTML. It's dense and highly technical, but it's the ultimate source of truth.
The History of HTML on Wikipedia - A great overview of the evolution of HTML from its academic roots to the HTML5 standard we use today.
W3C Markup Validation Service - Not just a tool, but an education. Running your HTML through a validator is a great way to learn about rules and best practices.