Shadow DOM
What is Shadow DOM?
Shadow DOM is a web platform feature that attaches an isolated DOM tree to an HTML element. It lets web components keep internal HTML and CSS separate from the page. In MDN’s Shadow DOM guide, the element is the shadow host, its container is the shadow root, and its markup is the shadow tree. The shadow boundary separates it from the page. Developer tools often show an open root as #shadow-root.
How Shadow DOM works
A component appears as one page element while containing its own interface.
- A developer attaches a shadow root to a host, such as a custom date picker.
- The component adds internal markup, controls, and CSS to the shadow tree.
- The browser renders the host and shadow tree together.
- Slots place page-supplied content in component locations.
- An open root is available through the host’s shadowRoot property. A closed root hides that property but is not a security or privacy barrier.
Shadow DOM vs. the regular DOM
Both are browser-rendered HTML structures, but they serve different needs.
| Area | Regular DOM | Shadow DOM |
|---|---|---|
| CSS scope | Page styles can broadly apply. | Internal styles are largely isolated. |
| JavaScript access | Page scripts can query elements directly. | Access follows the shadow boundary and root mode. |
| Reuse | Requires naming conventions. | Supports self-contained components. |
| Content composition | Uses normal parent and child elements. | Uses slots for supplied outside content. |
| Best fit | Page layouts and simple features. | Widgets, design systems, and embeddable controls. |
Benefits of Shadow DOM
Isolation helps components work reliably in different locations.
- It prevents many CSS naming conflicts with the host page.
- It keeps internal markup predictable for maintainers.
- It makes widgets safer to embed across products.
- It supports reusable date pickers, checkout widgets, and media controls.
Practical limits of Shadow DOM
Shadow DOM improves encapsulation, not invisibility or independence.
- Global CSS cannot easily style internal elements, so theming needs APIs such as CSS custom properties.
- Events may be retargeted across the boundary, affecting code that checks event targets.
- Automation tools, including Selenium, must enter open shadow roots to find internal elements.
- Closed roots can complicate debugging, testing, and integration.
- Rendered content remains inspectable, so Shadow DOM is not a security boundary.
Accessibility, SEO, and testing considerations
Components still need semantic HTML, accessible names, keyboard behavior, and focus management. Search visibility depends on crawlable rendered content and page quality, not Shadow DOM alone. Test keyboard journeys and locate elements across shadow boundaries rather than relying on page-wide selectors.
When a shadow root is worth using
Choose Shadow DOM when isolation solves a reuse problem.
- Use it for design-system components shared across pages or teams.
- Use it for third-party widgets on pages with unknown CSS.
- Use it when internal markup and styles must remain stable.
- Prefer ordinary DOM and scoped CSS for simple, page-specific layouts.
Shadow DOM in apps built with Emergent
When building interfaces with an AI app builder, component isolation can keep complex screens consistent. Emergent can help teams create full-stack products, while its AI web app builder supports reusable interface patterns.
on Emergent today

