An HTML element is a single structural unit of an HTML document, typically consisting of a start tag, optional attributes, content and an end tag, that tells the browser what a piece of content is: a heading, a paragraph, a link, an image, a form field or a section of the page. In HTML it is the basic building block from which every web page is composed.
When a browser parses a document, each element becomes a node in the DOM tree, the live object model that CSS styles and JavaScript manipulates. Choosing the right element therefore affects meaning, accessibility, default behavior and styling at the same time, not only how the content looks.
Anatomy of an HTML element
A typical element has four parts. The start tag contains the element name in angle brackets, the attributes inside the start tag add properties, the content sits between the tags, and the end tag repeats the name with a slash. Element names are case-insensitive in HTML, but lowercase is the established convention.
| Part | Role | Example in words |
|---|---|---|
| Start tag | Opens the element and names its type | An opening a tag |
| Attributes | Name-value pairs that configure the element | href, class, id, lang |
| Content | Text or nested child elements | The visible link text |
| End tag | Closes the element | A closing a tag with a slash |
The terms tag and element are often used interchangeably, but they are not the same. A tag is a piece of markup syntax; an element is the complete unit that the tags delimit, and after parsing it is an object in the DOM. An element can even exist without written tags, because the parser inserts some elements implicitly, such as html, head, body and tbody.
Normal, void and other element kinds
The HTML Living Standard groups elements into several syntactic kinds, which determine whether they need an end tag and what content they may hold.
| Kind | Characteristic | Examples |
|---|---|---|
| Normal elements | Start tag, content, end tag | p, div, section, button |
| Void elements | Start tag only, no content allowed | img, input, br, meta, link |
| Raw text elements | Content is not parsed as markup | script, style |
| Escapable raw text | Text with character references only | textarea, title |
| Template element | Inert content fragment for scripts | template |
| Foreign elements | Elements from other namespaces | SVG and MathML elements |
For some normal elements the end tag is optional, as with li or p, because the parser closes them automatically. Relying on this is valid but makes markup harder to read, so most style guides write end tags explicitly. A trailing slash on void elements is permitted but has no effect in HTML.
Content categories and nesting rules
Each element belongs to one or more content categories, and each element defines a content model describing which categories may appear inside it. These rules replaced the older and simpler split between block-level and inline elements.
| Category | Meaning | Typical members |
|---|---|---|
| Flow content | Most elements used in the body | p, div, ul, table |
| Phrasing content | Text and inline-level markup | span, em, strong, a |
| Heading content | Section headings | h1 to h6 |
| Sectioning content | Defines outline sections | article, section, nav, aside |
| Interactive content | Elements users can operate | a, button, input, select |
| Metadata content | Document setup and relations | meta, link, title |
Invalid nesting has real consequences. A div placed inside a p causes the parser to close the paragraph early, producing a different DOM than the author intended. Nesting interactive content inside interactive content, such as a button inside a link, is forbidden and confuses both keyboards and assistive technology.
Semantic elements and their practical effect
The choice of element carries meaning that browsers and assistive technologies use. This is the core idea of semantic HTML: a nav element is exposed as a navigation landmark, a button is announced as a button and is focusable and operable with the keyboard, and headings form an outline that screen reader users navigate.
| Need | Semantic element | What a generic div lacks |
|---|---|---|
| Clickable action | button | Focus, keyboard activation, role |
| Navigation to a URL | a with href | Link role, open-in-new-tab, history |
| Main page region | main | Landmark for skip navigation |
| Data grid | table with headers | Row and column relationships |
| Form label | label | Accessible name and larger click target |
Generic elements such as div and span have no inherent meaning and are appropriate only for grouping and styling. Adding ARIA roles to them can describe meaning, but native elements provide behavior for free, which is why they remain the first choice.
Common mistakes with HTML elements
Most element-related defects come from choosing elements for appearance instead of meaning. Browsers tolerate invalid markup silently, so these errors often survive until an accessibility audit or a layout bug exposes them.
- Headings chosen by size: picking
h4because it looks smaller breaks the document outline; style headings with CSS instead. - Div soup: layouts built only from
divelements lose landmarks and semantics. - Clickable non-interactive elements: click handlers on
divproduce controls unreachable by keyboard. - Missing alternative text: an
imgwithout a meaningfulaltattribute is silent for screen reader users. - Tables for layout: using
tableto position content misreports structure to assistive technology.
The short version
An HTML element is one labeled piece of a web page. A web page is written as a series of these labeled pieces. One says this is a heading, the next says this is a paragraph, and another says this is a link.
The label matters more than it seems. It tells the browser what the content is, not only how it looks. That is how a screen reader knows to announce a button, and how a search engine knows which line is the main title.
Where it makes a difference
A web agency inherits an online booking form in which every control is a styled div with a click handler. It looks fine with a mouse, but customers using the keyboard cannot reach the submit control, and a screen reader announces the form as plain unlabeled text.
The developer rebuilds the form with proper elements: label elements tied to each input, a fieldset with a legend for the date options, and a real button with the type set to submit. The visual design stays the same through CSS, and the markup shrinks because native behavior replaces custom scripts.
After the change, the form works fully with the keyboard, screen readers announce every field by its label, and pressing Enter submits the form as users expect. The fix took one afternoon and removed about 80 lines of event-handling code.