The Document Object Model (DOM) is a platform- and language-neutral interface that represents documents as a tree of nodes and defines how programs access and manipulate that structure. It underpins dynamic behavior on the web, enabling scripts to read, modify, and react to changes in HTML, SVG, and XML documents across web browsers and other environments.
Last updated November 15, 2025
The Document Object Model (DOM) is a platform- and language-neutral interface for representing and interacting with structured documents as node trees, defining events, aborting activities, and related primitives, as specified in the Living Standard maintained by the WHATWG. According to the Web developer reference maintained by MDN, the DOM exposes a document as a logical tree of nodes so that scripts can change structure, style, and content programmatically, especially in the context of JavaScript running in a Web browser.
Origins and standardization
The first W3C Recommendation for the DOM (DOM Level 1) was published on October 1, 1998, establishing a language-agnostic API for navigating and modifying HTML and XML documents, as recorded in the W3C’s publication history for the specification. W3C Standards History. DOM Level 2 Core advanced to W3C Recommendation on November 13, 2000, introducing namespaces, range/traversal modules, and an events model, per the W3C technical reports and status pages. W3C TR DOM Level 2 Core and W3C Level 2 Core history. DOM Level 3 Core reached Recommendation status in 2004 and was later retired as the platform consolidated around newer drafts, according to W3C’s history page. W3C Level 3 Core history. Since the 2010s the specification work moved to a single living standard under the WHATWG, with W3C publishing periodic “snapshot” Recommendations of that work, including Recommendations dated November 3, 2020 and September 28, 2021, as noted by W3C’s publication history and a 2021 W3C blog post describing the joint process. W3C DOM publication history and W3C blog (2021).
Data model and core interfaces
The DOM represents documents as a tree of nodes, exposing interfaces such as Node, Document, Element, Text, Comment, and DocumentFragment, with consistent traversal, insertion, and mutation behaviors defined normatively in the DOM Standard. WHATWG DOM Standard. Developer documentation reiterates this model and explains that each branch ends in a node object whose properties and methods enable structural edits, style changes, and content manipulation, which is foundational to dynamic pages written with HTML and XML. MDN: Document Object Model. In addition to tree structure, the DOM defines collections such as NodeList and HTMLCollection and clarifies how live versus static lists behave, as reflected in contemporary references and guidance for web authors. MDN: Document Object Model and WHATWG DOM Standard.
Event model and dispatch
The event system centers on EventTarget, which provides addEventListener, removeEventListener, and dispatchEvent for any object that receives events, and this interface is defined in the DOM specification and documented for developers. WHATWG DOM Standard and MDN: EventTarget. The W3C UI Events specification describes keyboard, mouse, and other UI event types that build on the DOM’s event infrastructure and clarifies their processing model for user agents. W3C UI Events. Explanatory resources outline the capture, target, and bubble phases of event propagation in the DOM tree, which sites use to coordinate interaction handling across nested elements. W3C UI Events and MDN: Event.
Query, traversal, and mutation
Element discovery commonly uses the Selectors API methods querySelector and querySelectorAll, which were standardized at W3C as Selectors API Level 1 and later merged into the DOM Living Standard; W3C documents mark the 2013 Recommendation and its supersession by DOM snapshots aligned with WHATWG. W3C Selectors API Level 1 and W3C history for Selectors API. Developer-facing documentation shows how these methods apply CSS selectors to return elements efficiently. MDN: Selection and traversal on the DOM tree and MDN: Document.querySelector. For structural and text-range operations, the DOM defines traversal APIs and Range, historically specified in DOM Level 2 Traversal and Range (Recommendation 13 November 2000), which remain relevant concepts even as modern definitions are consolidated into the living standard. W3C DOM Level 2 Traversal and Range and W3C history page. For observing changes, MutationObserver provides a performant callback mechanism to watch for subtree modifications without polling, as documented for developers and referenced by specifications. MDN: MutationObserver and WHATWG DOM Standard.
Aborting activities and asynchronous control
Modern DOM includes primitives for aborting ongoing activities, notably AbortController and AbortSignal, which allow APIs to cancel asynchronous work and propagate an abort reason consistently across listeners and promise rejections. WHATWG DOM Standard. Developer references describe how these are used with fetch and other operations to stop work in response to user actions or timeouts. MDN: AbortController and MDN: AbortController.abort.
Language bindings and implementation
DOM’s APIs are defined in terms of Web IDL so that bindings to ECMAScript and other languages are precise and interoperable across engines, with the Web IDL Living Standard providing the IDL syntax and conversion rules that specifications reference. WHATWG Web IDL. Beyond browsers, many platforms expose the W3C DOM interfaces for XML processing, such as the org.w3c.dom packages in the Java SE platform that implement Level 2/3 Core and related modules for server-side or desktop processing of XML documents. Oracle Java SE 18 org.w3c.dom and Oracle Java SE 11 org.w3c.dom. These language bindings reflect the DOM’s design goal of being platform- and language-neutral while remaining compatible with web runtime expectations. WHATWG Web IDL and WHATWG DOM Standard.
Relationship to HTML, CSS, and related models
The DOM is the structural foundation upon which the HTML specification’s processing model and scripting APIs operate, with the modern HTML Living Standard integrating tightly with DOM concepts defined by WHATWG and mirrored in W3C review drafts and snapshots. W3C blog (2021) and WHATWG DOM Standard. Styling is handled via the separate CSS Object Model, which provides APIs for reading and writing CSS values and for view-related geometry, complementing but not replacing the DOM’s structural role. MDN: CSSOM and MDN: CSSOM view. Authoring resources further emphasize that DOM operations frequently coordinate with CSSOM for layout, scrolling, and style computation tasks in user agents. MDN: CSSOM view API and MDN: CSSOM.
Governance and evolution
The WHATWG maintains the DOM as a continuously updated Living Standard with dependencies on shared low-level primitives defined in the Infra Standard, ensuring consistent terminology and algorithmic conventions across platform specifications. WHATWG DOM Standard and WHATWG Infra. W3C and WHATWG collaborate so that the W3C publishes periodic, patent-reviewed snapshots of the DOM, providing a stable reference point aligned to the living specification and its test suites for broader standards governance. W3C DOM publication history and W3C blog (2021).
The Document Object Model (DOM) is a platform- and language-neutral interface that represents documents as a tree of nodes and defines how programs access and manipulate that structure. It underpins dynamic behavior on the web, enabling scripts to read, modify, and react to changes in HTML, SVG, and XML documents across web browsers and other environments.
Last updated November 15, 2025
The Document Object Model (DOM) is a platform- and language-neutral interface for representing and interacting with structured documents as node trees, defining events, aborting activities, and related primitives, as specified in the Living Standard maintained by the WHATWG. According to the Web developer reference maintained by MDN, the DOM exposes a document as a logical tree of nodes so that scripts can change structure, style, and content programmatically, especially in the context of JavaScript running in a Web browser.
Origins and standardization
The first W3C Recommendation for the DOM (DOM Level 1) was published on October 1, 1998, establishing a language-agnostic API for navigating and modifying HTML and XML documents, as recorded in the W3C’s publication history for the specification. W3C Standards History. DOM Level 2 Core advanced to W3C Recommendation on November 13, 2000, introducing namespaces, range/traversal modules, and an events model, per the W3C technical reports and status pages. W3C TR DOM Level 2 Core and W3C Level 2 Core history. DOM Level 3 Core reached Recommendation status in 2004 and was later retired as the platform consolidated around newer drafts, according to W3C’s history page. W3C Level 3 Core history. Since the 2010s the specification work moved to a single living standard under the WHATWG, with W3C publishing periodic “snapshot” Recommendations of that work, including Recommendations dated November 3, 2020 and September 28, 2021, as noted by W3C’s publication history and a 2021 W3C blog post describing the joint process. W3C DOM publication history and W3C blog (2021).
Data model and core interfaces
The DOM represents documents as a tree of nodes, exposing interfaces such as Node, Document, Element, Text, Comment, and DocumentFragment, with consistent traversal, insertion, and mutation behaviors defined normatively in the DOM Standard. WHATWG DOM Standard. Developer documentation reiterates this model and explains that each branch ends in a node object whose properties and methods enable structural edits, style changes, and content manipulation, which is foundational to dynamic pages written with HTML and XML. MDN: Document Object Model. In addition to tree structure, the DOM defines collections such as NodeList and HTMLCollection and clarifies how live versus static lists behave, as reflected in contemporary references and guidance for web authors. MDN: Document Object Model and WHATWG DOM Standard.
Event model and dispatch
The event system centers on EventTarget, which provides addEventListener, removeEventListener, and dispatchEvent for any object that receives events, and this interface is defined in the DOM specification and documented for developers. WHATWG DOM Standard and MDN: EventTarget. The W3C UI Events specification describes keyboard, mouse, and other UI event types that build on the DOM’s event infrastructure and clarifies their processing model for user agents. W3C UI Events. Explanatory resources outline the capture, target, and bubble phases of event propagation in the DOM tree, which sites use to coordinate interaction handling across nested elements. W3C UI Events and MDN: Event.
Query, traversal, and mutation
Element discovery commonly uses the Selectors API methods querySelector and querySelectorAll, which were standardized at W3C as Selectors API Level 1 and later merged into the DOM Living Standard; W3C documents mark the 2013 Recommendation and its supersession by DOM snapshots aligned with WHATWG. W3C Selectors API Level 1 and W3C history for Selectors API. Developer-facing documentation shows how these methods apply CSS selectors to return elements efficiently. MDN: Selection and traversal on the DOM tree and MDN: Document.querySelector. For structural and text-range operations, the DOM defines traversal APIs and Range, historically specified in DOM Level 2 Traversal and Range (Recommendation 13 November 2000), which remain relevant concepts even as modern definitions are consolidated into the living standard. W3C DOM Level 2 Traversal and Range and W3C history page. For observing changes, MutationObserver provides a performant callback mechanism to watch for subtree modifications without polling, as documented for developers and referenced by specifications. MDN: MutationObserver and WHATWG DOM Standard.
Aborting activities and asynchronous control
Modern DOM includes primitives for aborting ongoing activities, notably AbortController and AbortSignal, which allow APIs to cancel asynchronous work and propagate an abort reason consistently across listeners and promise rejections. WHATWG DOM Standard. Developer references describe how these are used with fetch and other operations to stop work in response to user actions or timeouts. MDN: AbortController and MDN: AbortController.abort.
Language bindings and implementation
DOM’s APIs are defined in terms of Web IDL so that bindings to ECMAScript and other languages are precise and interoperable across engines, with the Web IDL Living Standard providing the IDL syntax and conversion rules that specifications reference. WHATWG Web IDL. Beyond browsers, many platforms expose the W3C DOM interfaces for XML processing, such as the org.w3c.dom packages in the Java SE platform that implement Level 2/3 Core and related modules for server-side or desktop processing of XML documents. Oracle Java SE 18 org.w3c.dom and Oracle Java SE 11 org.w3c.dom. These language bindings reflect the DOM’s design goal of being platform- and language-neutral while remaining compatible with web runtime expectations. WHATWG Web IDL and WHATWG DOM Standard.
Relationship to HTML, CSS, and related models
The DOM is the structural foundation upon which the HTML specification’s processing model and scripting APIs operate, with the modern HTML Living Standard integrating tightly with DOM concepts defined by WHATWG and mirrored in W3C review drafts and snapshots. W3C blog (2021) and WHATWG DOM Standard. Styling is handled via the separate CSS Object Model, which provides APIs for reading and writing CSS values and for view-related geometry, complementing but not replacing the DOM’s structural role. MDN: CSSOM and MDN: CSSOM view. Authoring resources further emphasize that DOM operations frequently coordinate with CSSOM for layout, scrolling, and style computation tasks in user agents. MDN: CSSOM view API and MDN: CSSOM.
Governance and evolution
The WHATWG maintains the DOM as a continuously updated Living Standard with dependencies on shared low-level primitives defined in the Infra Standard, ensuring consistent terminology and algorithmic conventions across platform specifications. WHATWG DOM Standard and WHATWG Infra. W3C and WHATWG collaborate so that the W3C publishes periodic, patent-reviewed snapshots of the DOM, providing a stable reference point aligned to the living specification and its test suites for broader standards governance. W3C DOM publication history and W3C blog (2021).
