Why HTML Isn't Considered a Programming Language

Why That Argument Misses the Point

I have been writing HTML, on and off, for close to twenty years. I have shipped commercial real estate websites built with hand-written markup, I have built AmplyViewer, an interactive 3D property viewer that lives inside an HTML container on third-party sites, and I run a daily email summary product called AmplyDigest where the entire deliverable is, technically, an HTML document.

I have also lost count of how many times I have read the sentence "HTML is not a programming language." It is almost always presented as a gotcha. The question deserves a better answer than the usual one, because the technical distinction is real, but the way it gets used in conversation is often wrong.

The short technical answer

HTML stands for HyperText Markup Language. The clue is in the name. According to the WHATWG HTML Living Standard, which is the authoritative specification for HTML and is maintained jointly by Apple, Google, Mozilla and Microsoft, HTML is "a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the web." It describes content. It tells the browser that this thing is a heading, this thing is a paragraph, this is a link, this is an image.

A programming language, in the formal sense, is a language that can express algorithms. It has variables you can assign values to. It has control flow, meaning if-statements and loops. It supports functions, recursion, and the ability to take an input, transform it, and produce an output that depends on that transformation.

HTML, on its own, does none of those things. You cannot write an HTML file that adds two numbers. You cannot write an HTML file that loops over a list and decides which items to show based on a condition. You cannot write an HTML file that responds differently depending on what a user types. The moment you want any of that behaviour, you reach for JavaScript, a server-side language, or a templating engine that runs before the HTML is sent.

So as a definitional matter, no, HTML is not a programming language. That part is not really up for debate among people who write code for a living.

The argument that actually misses the point

Here is the thing. Most of the time, when someone says "HTML is not a programming language," they are not making a clean technical statement. They are making a status claim. They are saying that knowing HTML is less impressive, less skilled, or less worthy of pay than knowing a "real" language. That is the framing I have a problem with, and it is the framing the original version of this article quietly accepted.

The way HTML is used in production tells a different story. Writing semantic, accessible, performant HTML is genuinely hard. I see junior developers ship soup of <div> tags every week. I see expensive sites where every heading is an <h1> because someone styled visually rather than structurally. I see real estate listing pages where the property address sits inside a <span> styled to look like a heading, which means screen readers, search engine crawlers, and AI search engines like Perplexity all see it as inline noise instead of a primary entity.

None of that is a programming language problem. It is a problem of not understanding what HTML is for and how the browser, the accessibility tree, and the search index actually consume it. That craft is closer to typography or information architecture than it is to algorithm design. It is also worth paying for.

The famous "HTML is actually Turing complete" rabbit hole

If you have spent any time on Hacker News, you have probably seen the claim that HTML and CSS together are Turing complete. The argument originates from a 2011 demonstration showing that you can simulate Rule 110, an elementary cellular automaton that Stephen Wolfram proved Turing complete, using only HTML, CSS checkboxes, and the :checked pseudo-class.

The honest version of this story is that the proof only works with user input. A human has to keep clicking checkboxes to advance the computation. Once you accept that "HTML plus CSS plus a human pressing buttons" is Turing complete, you have stretched the definition of the system so far that the claim is more of a parlour trick than a serious statement about HTML.

I bring it up not to settle the debate but because it points at something interesting. The boundary between markup and computation is not a wall. It is a wide, fuzzy zone, and modern web tooling lives squarely inside that zone.

Where modern tooling makes the line genuinely blurry

When I build a real estate site for a client, I almost never write plain HTML files anymore. I write Astro components. Astro is a static site framework that uses an HTML-first authoring model with embedded JavaScript expressions, and the output is plain HTML by default. If you have not used it, my guide to the Astro framework walks through the basics.

Here is what an Astro component looks like in practice:

---
const properties = await fetch('/api/listings').then(r => r.json());
const featured = properties.filter(p => p.status === 'featured');
---

<section class="listings">
  {featured.map(property => (
    <article>
      <h2>{property.title}</h2>
      <p>{property.price}</p>
    </article>
  ))}
</section>

That looks like HTML. The browser receives plain HTML. But the file itself has a fetch call, a filter, a map, and conditional rendering. Is the author of that file "programming"? They are clearly doing more than describing content. They are also clearly not writing a backend.

The same blurring happens in Webflow, where the visual editor compiles down to HTML and JavaScript but exposes logic-shaped tools like conditional visibility and CMS bindings. It happens in React's JSX, where HTML-looking syntax is actually a JavaScript expression that returns a virtual DOM tree. It happens in Svelte, where what looks like extra HTML attributes are reactive bindings.

The takeaway is that nobody who builds modern web interfaces is writing pure HTML in isolation. The question "is HTML a programming language" was always slightly off. The more useful question is "what part of the stack are you writing in right now."

What this distinction actually changes in practice

This is where the markup-versus-language debate starts to matter, and matters in a different way than the textbook answer suggests. It matters when you are scoping a project, hiring a developer, or evaluating a quote.

If a client asks me to "just add a filter to the property listings page," they usually think of it as a small visual tweak, because the listings are right there on the page in HTML. From a markup standpoint, it does look small. From a programming standpoint, that filter involves data fetching, state management, URL parameter handling, and a render loop. The cost is in the programming, not the markup, and the gap between how it looks and what it actually requires is exactly where most underbid quotes come from.

The same thing happens with forms. Forms are HTML. You can hand-write a contact form in five minutes. But the actual work, which is validating input, handling submission errors, storing leads in a database, preventing spam, sending notification emails, is all programming, and on a real estate site the lead-handling logic is often more important than anything else on the page.

For business owners evaluating web work, this is the practical version of the question. HTML is the visible surface. Programming is everything that makes the surface respond to the world. When someone asks why their "simple website" costs more than they expected, the answer is almost always that the actual work was on the programming side, not the markup side.

Common misconceptions, briefly

People who are not deep in web development tend to hold a few related ideas that are worth correcting in one place:

• HTML is a programming language because it uses code-looking syntax. Tags and angle brackets do not make a programming language. Configuration files, recipes, and grocery lists also have syntax.
• HTML5 added so many features that it crossed over. HTML5 added semantic elements, multimedia tags, and APIs that JavaScript can call, but the markup itself still does not execute logic.
• Forms prove HTML is interactive. Forms describe an input surface. The processing of that input happens in JavaScript or on a server.
• If you write HTML for a living, you are not really a developer. Tell that to any senior frontend engineer who has spent a week getting a complex layout to render identically across browsers, screen readers, and search engine crawlers.

When the markup itself is the hard part

There is a category of project where the HTML is genuinely the hard part, and I run into it constantly in the real estate niche. A property listing page is, on its face, a long-form document. Title, hero image, gallery, description, specifications, agent details, contact form. All of it is content.

The hard part of that page is making the structure machine-readable. Schema.org markup for the property, the address, the price, the agent. Accessible heading hierarchy. Proper landmark regions for assistive technology. Image alt text that actually says what the image shows rather than the filename. OpenGraph and Twitter Card tags so the page previews correctly when shared. These are all HTML problems, and they directly affect search visibility, AI search citations, and lead quality.

That kind of work is markup, not programming. It is also where the money is, because Google's results page, AI Overviews, and tools like Perplexity all consume the markup before they consume anything dynamic. At DignuzDesign I see this on every real estate build: the dynamic features get the client's attention, but the static, well-structured HTML is what drives the qualified traffic in the first place.

Frequently asked questions

Is HTML a programming language or not?

HTML is not a programming language. It is a markup language. The WHATWG specification defines it as a system for describing the structure and semantics of content. It has no concept of variables, loops, conditionals, or functions in the programming sense. Logic on a web page comes from JavaScript, server-side code, or a template engine that processes the HTML before delivery.

Is HTML easier than JavaScript or Python?

The basics of HTML are quicker to learn than the basics of a real programming language, because there is no logic to wrap your head around. Writing good HTML, the kind that is semantic, accessible, and machine-readable, takes longer to master than people expect. If you are starting out, my notes on whether HTML is hard to learn cover the curve in more detail.

Why does it matter whether HTML is a programming language?

Mostly it matters because of how people scope and price web projects. If you assume "it is just HTML" because the visible page is HTML, you will consistently underestimate the cost of anything dynamic. Treating HTML as a separate layer that sits on top of programming, rather than as the same thing, leads to more realistic expectations on both sides of a project.

Can HTML do anything without JavaScript?

HTML on its own can structure content, lay out forms, embed media, and trigger basic browser behaviour like opening a link in a new tab. It can also use modern features like the <details> element for collapsible sections without any script. It cannot validate complex input, fetch data, calculate values, or update the page after it loads.

Should I still learn HTML if I want to become a developer?

Yes, and not as an afterthought. Every web project on every framework ultimately produces HTML. If your HTML output is sloppy, no amount of clever React code will fix the resulting accessibility, SEO, and AI-citability problems. If you want a longer take, I wrote a piece on why learning HTML today still makes sense.

What language should I learn after HTML?

JavaScript is the obvious next step, because it is the only language the browser runs natively. If you are deciding what to invest in beyond that, my breakdown of the best programming languages to learn compares a few common paths.

The takeaway

HTML is not a programming language. That part is settled, and the technical reasoning is straightforward. What is not settled is the way people use that fact to dismiss the skill required to actually do markup well, or to underprice the programming work that sits behind a deceptively simple-looking page.

If you are a developer, treat HTML as a craft that compounds. If you are a business owner evaluating quotes, treat the visible HTML on a page as the smallest part of what you are paying for. And if someone tells you HTML does not count as a real language, ask them to write you a property listing page that ranks, converts, and reads well in a screen reader. The fight is rarely about the definition.