FlowingDev

HTML, explained: the digital skeleton of every webpage

Learn the fundamentals of HTML, the standard markup language used to create and structure the content of web pages and applications.

Try the tool: HTML Editor

In one sentence

HTML (HyperText Markup Language) is the standard language for creating the structure and content of documents that get displayed on the World Wide Web.

The problem it solves

Picture the internet before the web as we know it. It was a nerdy wild west of disconnected documents. Academics at CERN might have a research paper on their local system in one format, while a university in another country had related work in a completely different, incompatible format. Sharing and, more importantly, connecting this information was a digital nightmare.

Enter Tim Berners-Lee. In the late 80s and early 90s, he wasn't trying to create a platform for cat videos; he was trying to solve a very real problem for scientists: how do we share and link our documents across different computers and networks in a simple, universal way?

The solution was a trifecta: HTTP (a protocol to request and send documents), URLs (an address for each document), and HTML (a language to write the documents).

HTML's genius was its simplicity. It provided a set of "tags" that anyone could learn, allowing them to mark up a plain text document. This tag would tell a browser, "This bit is a heading," "This is a paragraph," and crucially, "This text here is a hyperlink to that other document over there." That hyperlink capability is the "HT" in HTML, and it's what turned a collection of isolated files into a true "web" of interconnected information. HTML became the browser's lingua franca, the universal blueprint for a webpage.

How it works under the hood

At first glance, HTML looks like plain text with some funny angle brackets. But under the hood, the browser performs a sophisticated parsing process to turn that text into the living, breathing webpage you interact with.

Tags, Elements, and Attributes: The Holy Trinity

HTML's syntax is built on three core concepts. Once you get these, you've got 80% of HTML down.

  • Tag: An instruction wrapped in angle brackets, like <p> or <img>. Most tags come in pairs: an opening tag (<p>) and a closing tag (</p>). The closing tag has a forward slash.
  • Element: The complete package—the opening tag, the content inside, and the closing tag. It's the whole shebang.
  • Attribute: Extra information or settings for an element, placed inside the opening tag. They come in name="value" pairs.

Let's dissect a simple example:

<a href="https://flowing.dev" class="main-link">Visit FlowingDev</a>
  • The tags are <a> and </a>. The a stands for "anchor," and it's used for hyperlinks.
  • The element is the entire line, from <a... to ...</a>.
  • The content is the text "Visit FlowingDev".
  • It has two attributes:
    • href="https://flowing.dev": The "hypertext reference" attribute, which tells the browser where to go when the link is clicked. This is the most important attribute for an <a> tag.
    • class="main-link": A "class" attribute, which is a hook for CSS to style the element or for JavaScript to find it.

The Document Object Model (DOM)

When a browser receives your HTML file, it doesn't just read it line-by-line like a book. It parses the text and builds a logical tree structure in memory called the Document Object Model (DOM).

Think of your HTML source code as the architectural blueprint for a house. The DOM is the actual constructed frame of the house—a tangible structure that you can inspect and modify.

Consider this basic HTML page:

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>A Heading</h1>
    <p>Some text.</p>
  </body>
</html>

The browser sees the nesting of the tags and builds this DOM tree:

  • html
    • head
      • title
        • (text) "My Page"
    • body
      • h1
        • (text) "A Heading"
      • p
        • (text) "Some text."

This tree structure is everything. CSS applies styles to the nodes in this tree. JavaScript can manipulate this tree—adding new nodes (elements), removing old ones, or changing their attributes—which is how modern web pages become dynamic and interactive without needing to reload. The DOM is the bridge between your static HTML and a dynamic app.

Block vs. Inline Elements

Not all elements are created equal. In terms of layout, they fall into two main families.

  • Block-level Elements: These are the big dogs. They are structural. They typically start on a new line and take up the full width available to them, like a paragraph in a book.

    • Examples: <div>, <p>, <h1>-<h6>, <ul>, <li>, <form>, <article>.

  • Inline Elements: These are more subtle. They don't start a new line and only take up as much width as their content needs. They flow along with the text around them.

    • Examples: <a>, <span>, <strong>, <em>, <img>, <input>.

Understanding this distinction is critical for CSS layout. Trying to set a width on an inline element often won't work as you expect, and wondering why two elements are sitting side-by-side when you wanted them stacked is a classic block-vs-inline puzzle.

<div style="background-color: #eee;">
  This div is a block-level element. It takes the full width.
</div>
<div style="background-color: #ddd;">
  This is a second div. It starts on a new line.
</div>
<p>
  Here is a paragraph that contains an 
  <a href="#">inline link</a> and some 
  <strong>inline bold text</strong>. Notice how they all
  stay within the flow of the text.
</p>

Real-world stories

The Misaligned "Buy Now" Button

A junior developer was tasked with adding a product description and a "Buy Now" button. They wrote what seemed logical: <p>Awesome Product! Only $9.99! <button>Buy Now</button></p>. On their big desktop monitor, it looked perfect. The button sat nicely at the end of the sentence. The code was pushed.

Days later, analytics showed a dip in mobile conversion. A senior dev investigated and pulled up the page on a phone. The text "Awesome Product! Only $9.99!" wrapped onto a second line, and the "Buy Now" button wrapped right along with it, ending up awkwardly indented under the start of the sentence. It looked broken. The junior dev had put a block-like element (button often behaves like one) inside a paragraph, creating unpredictable wrapping behavior.

The fix was simple: separate structure from content. The text went in its own <p> tag, and the button went in its own <div>. Now, the paragraph could wrap all it wanted, and the button, as a distinct block, would always appear cleanly underneath it, no matter the screen size.

The lesson: Understanding the HTML box model and the block/inline distinction is non-negotiable for creating layouts that are predictable and don't break on different devices.

The Un-crawlable Blog

A startup launched a sleek new blog powered by a cutting-edge JavaScript framework. It was fast, animated, and felt like a native app. The entire site's HTML source was effectively just <div id="app"></div> and a massive <script> tag that built the page in the user's browser. They were proud of their tech.

Six months later, they had a problem: zero organic traffic from Google. They were invisible. When a search engine crawler visited their site, it didn't see beautiful articles and headings; it saw an empty <div>. While Google's crawler has gotten better at executing JavaScript, it's an extra, expensive step, and it's not foolproof. The blog wasn't communicating its structure or content in the crawler's native tongue: plain, semantic HTML.

The team had to re-architect their site to use Server-Side Rendering (SSR), where the server generates the full HTML for each page before sending it to the browser. The moment they deployed the change, their pages started getting indexed properly.

The lesson: Semantic HTML (<article>, <h1>, <p>) isn't just a suggestion; it's how you communicate the meaning and hierarchy of your content to search engines and other automated tools.

The Accessibility Nightmare

A company rolled out a new internal dashboard. To get the pixel-perfect look the designers wanted, the developers used <div> elements for absolutely everything. A <div> with a border-radius and a JavaScript onClick event became a button. Another <div> with an onClick event became a link.

The dashboard was unusable for an employee who relied on a screen reader. The screen reader announced "group" for every interactive element, offering no clue as to whether it was a button, a link, or something else. Furthermore, since <div>s aren't focusable by default, navigating with the Tab key was impossible.

An accessibility consultant was brought in and was horrified. The fix involved a tedious but essential refactor: replacing <div onClick="..."> with <button>, <a>, and other appropriate, semantic elements. These native tags come with a huge amount of accessibility functionality built-in for free—keyboard focus, proper role announcements, and more.

The lesson: Use the right HTML tag for the job. You're not just telling the browser how to draw something; you're telling assistive technologies what it is.

Common mistakes and traps

  • "Div-itis." The rampant overuse of <div> and <span> when more specific, semantic tags like <nav>, <main>, <article>, <aside>, or <button> would better describe the content's purpose.
  • Forgetting accessibility basics. Missing alt attributes on <img> tags is a classic. This leaves visually impaired users with no information about the image. Similarly, using <b> for bolding instead of <strong> (which indicates importance) can be a missed semantic opportunity.
  • Improper tag nesting. You can't just put any tag inside any other tag. A common error is wrapping a block-level element (like a <div>) inside an inline element (like an <a>). While browsers will try their best to render it, the resulting DOM can be a mess and lead to bizarre behavior.
  • Ignoring the <head>. The <head> section is vital. Forgetting to set the character encoding (<meta charset="UTF-8">) can lead to garbled text. Forgetting the viewport meta tag (<meta name="viewport" content="width=device-width, initial-scale=1.0">) is the number one reason mobile sites look zoomed-out and tiny.
  • Assuming a closed vocabulary. HTML is a living language. New tags and attributes are added over time (e.g., <main>, <picture>). Relying on patterns from 2010 means you're missing out on more robust and semantic ways to structure your documents.

Why it belongs on your radar

If you touch the web in any professional capacity, HTML is not optional.

  • For front-end developers, it's the bedrock. Frameworks like React, Vue, and Svelte are powerful, but they all ultimately spit out HTML. Understanding the target output makes you a vastly more effective developer.
  • For back-end developers, you're often generating snippets of HTML, building APIs that will be consumed by HTML front-ends, or working with templating engines that produce HTML. Knowing its rules prevents you from shipping broken or un-semantic markup.
  • For UI/UX designers, understanding the basic building blocks of HTML (div, span, p, h1) helps you create designs that are practical to build and map cleanly to the web's native components.
  • For SEO specialists and content managers, a solid grasp of HTML (especially headings, title tags, and meta descriptions) is fundamental to your craft.

HTML is the most durable, backward-compatible, and universal language of the digital age. A webpage written in 1995 will still render today. It's the one skill that has remained essential through every hype cycle and framework war, and it's not going anywhere.

Go deeper

Theory done. Time to get your hands dirty — 100% in your browser.

Try the tool: HTML Editor