HTML Explained β The Markup Behind Web Pages
HTML, or HyperText Markup Language, describes the structure of a web document. Elements identify paragraphs, links, headings, tables, forms, and other content. A browser parses the markup into a Document Object Model (DOM), then uses that tree with styles and scripts to display and update the page.
For extraction, distinguish three things: the response a server sends, the document a browser or parser constructs, and the content an extractor returns. They may contain different information.
Elements describe a document
Semantic elements give readers and software clues about a region's purpose: <article> denotes a self-contained composition, <nav> a navigation section, and <aside> tangential content. <main> identifies the body's dominant content; <figure> and <figcaption> group a figure with its caption. Headers, footers, and sections describe other parts of a document.1
A page built from generic containers might use this structure:
<div id="header">...</div>
<div id="nav">...</div>
<div id="content">
<div class="post">...</div>
<div class="sidebar">...</div>
</div>
<div id="footer">...</div>
Semantic elements can express the intended roles directly:
<header>...</header>
<nav>...</nav>
<main>
<article>...</article>
<aside>...</aside>
</main>
<footer>...</footer>
Those roles do not determine the visual layout, and the two examples need not render identically without CSS. Nor does an <article> tag prove that its contents are the article you want. Page authors can misuse elements or place several articles in one document, so extractors also inspect surrounding content.
How HTML became a living standard
HTML developed alongside the Web, with compatibility with existing documents shaping later standards.
- 1989β1991: Tim Berners-Lee proposed a linked information system at CERN in March 1989. By the end of 1990, the first browser and server were operating.23 Early βHTML Tagsβ documentation described links, headings, lists, and other markup, including elements such as
<nextid>and<isindex>that are now obsolete.4 - 1995: RFC 1866 documented HTML 2.0, including forms and images. Tables were not part of that specification.5
- 1997: HTML 3.2 became a W3C Recommendation on January 14, adding tables, applets, text flow around images, and presentational markup such as
<font>.6 - 1999: HTML 4.01, published December 24 after HTML 4.0 in 1997, defined Strict, Transitional, and Frameset document types and supported separating presentation into stylesheets.7
- 2000: XHTML 1.0 recast HTML 4 as XML. Its January 26 Recommendation required well-formed XML, lowercase element names, quoted attributes, and explicit closing syntax.8
- 2004 onward: WHATWG began an incremental evolution of HTML while W3C pursued XHTML. W3C resumed HTML work in 2007, and the groups later differed over versioned releases versus continuous maintenance.9
- 2014β2019: W3C published HTML5 as a Recommendation on October 28, 2014. The May 2019 W3C/WHATWG agreement established collaboration around one HTML standard maintained by WHATWG.1011
The HTML Living Standard is the current reference. βHTML5β remains a common label, but implementation details should be checked against the living specification and the browsers involved.1
Parsing produces a tree
HTML parsing has tokenization and tree-construction stages. The tokenizer recognizes text, tags, comments, and attributes; tree construction places the resulting nodes in a document. Both stages have detailed rules for malformed input.12
For example, <p>First<p>Second produces two paragraph elements: starting the second paragraph closes the first. Other malformed structures may acquire implied elements or move to different positions. This error handling is defined by HTML, not an assurance that every malformed document expresses its author's intent.
The Document is the tree's root; <html> is its document element, normally containing <head> and <body>:
document
βββ html
βββ head
β βββ title
β βββ meta
βββ body
βββ header
β βββ nav
βββ main
β βββ article
β β βββ h1
β β βββ p
β βββ aside
βββ footer
Browser scripts can subsequently add, remove, or modify nodes. A parser applied to an HTTP response sees the supplied markup; a browser capture may include those later changes. Select the fetching method accordingly.
What an extractor uses
DOM-based extractors such as Trafilatura inspect elements and text to identify useful content. Their algorithms differ, but common signals include paragraph length, link density, headings, element roles, and the relationship between neighboring blocks.
Navigation and script/style regions can be removed before candidate content is assessed. Semantic markup can help identify regions, while generic <div> containers require other evidence. Selection may combine several blocks or use fallbacks; it is not universally a single highest-scoring subtree.
Extraction is selective. Inspect representative pages for omitted paragraphs, included sidebars, and changes to tables or code. The format guide explains what later conversion to Markdown or plain text may discard.
Cleaned content and captured source
Cleaned HTML contains the content retained by extraction, with supported semantic markup. The crawler capture is the HTML available before that extraction step. Saving both allows you to inspect a result against its input or reprocess it with different settings.
A capture is not a complete web archive. External images, stylesheets, scripts, and later network responses are separate resources. Browser rendering, parser serialization, and consent handling may also have changed the HTML before it was captured.
Request HTML from Markdownee
Markdownee's html-* routes produce readable cleaned HTML from Trafilaturacore's result. The independent minified-html selector requests the compact presentation. Both use outputLayout: minimal for a fragment, standard for a complete document with ordinary metadata, and enhanced for additional allowlisted metadata and crawl information.
| Save format | Processing |
|---|---|
txt-* | Clean content, then walk the structure to produce text |
markdown-* | Clean content, then convert with Turndown and GFM support |
html-* | Clean content, then format readable HTML |
minified-html-* | Clean content, then format compact HTML |
original-* | Save the crawler capture before content extraction |
For the captured input, use --save original-kvs with crawl or --save original-file with CLI crawl-one. When Playwright supplies the page, that input can reflect JavaScript rendering. The Actor exposes dataset/KVS routes; the playground offers an Original raw HTML checkbox. File and stdout destinations belong to the CLI's single-page operation.
Optional --markdown-discovery changes the source. When an origin-published Markdown representation is accepted, its derived HTML passes through cleaning and supplies the output formats. Markdown can use the served body after front-matter handling and the selected layout; when the content check requires a cleaned round trip, it is rendered from cleaned HTML instead. markdownSource.verbatim records the branch. For these records, original is also derived from the served Markdown.
The HTML-to-Markdown article covers conversion approaches. Keep a captured source when later diagnosis or re-extraction matters, and retain the extraction settings alongside your results.
Citations
-
WHATWG: HTML Standard. Retrieved April 14, 2026 β© β©2
-
CERN: A short history of the Web. Retrieved April 14, 2026 β©
-
W3C: The original proposal of the WWW, HTMLized. Retrieved April 14, 2026 β©
-
IETF RFC 1866: Hypertext Markup Language - 2.0. Retrieved April 14, 2026 β©
-
W3C: HTML 3.2 Reference Specification. Retrieved April 14, 2026 β©
-
W3C: HTML 4.01 Specification. Retrieved April 14, 2026 β©
-
W3C: XHTML 1.0: The Extensible HyperText Markup Language. Retrieved April 14, 2026 β©
-
W3C: HTML5 β A vocabulary and associated APIs for HTML and XHTML. Retrieved April 14, 2026 β©
-
W3C: Memorandum of Understanding Between W3C and WHATWG. Retrieved April 14, 2026 β©
-
WHATWG: HTML Standard β Parsing HTML documents. Retrieved April 14, 2026 β©
Updated: September 7, 2026