Designing findable content with hidden=until-found

Hidden content that still needs to be discoverable has long been a pain point for designers and developers. The hidden=until-found attribute is a recent addition to HTML intended to bridge the gap between visual concealment and discoverability by find-in-page and fragment navigation.

Rather than relying on hacks or brittle scripting, hidden=until-found provides a standardized way for browsers to keep content out of sight yet targetable. The goal is simple: let users find and jump to text that you intentionally hide until it is needed.

What hidden=until-found does

The HTML standard defines hidden=until-found as an attribute value that keeps an element not rendered but makes its content discoverable by find-in-page and fragment navigation. When a match occurs, the user agent will fire a beforematch event, remove hidden from the element, and then scroll to the revealed content. The WHATWG spec is the canonical source for this behavior.

From a design perspective, hidden=until-found separates visibility from discoverability. Content can remain visually concealed for cleaner layouts while still being reachable via search, links, or anchors. That makes it a natural fit for progressive disclosure patterns.

Because the UI change is coordinated by the browser firing beforematch then revealing the element, authors can hook into that sequence to synchronise their own components rather than relying on guesswork or polling.

How browsers implement it under the hood

Most user agents implement hidden=until-found using content-visibility: hidden rather than display:none. Using content-visibility allows the host element to generate a box and participate in layout while its child content is not rendered. That implementation detail matters for both layout and scripting.

Because the element still occupies layout space, borders, margins, padding and the element box itself can affect the page even while children remain non-rendered. That means layout APIs may report positions and sizes that differ from what rendered children would produce once the element is revealed.

These implementation choices are intentional: by keeping the element in the layout flow, browsers can reliably scroll to or align content when it becomes visible without reflow surprises that a display:none toggle would cause.

The beforematch sequence and developer-facing behavior

The key developer hook is the beforematch event. When find-in-page or fragment navigation targets text inside an element with hidden=until-found, the browser fires beforematch on the element, removes hidden, then scrolls to the match. This lets authors expand accordions, open tabs, or synchronise other UI state in response to an incoming search or link.

Typical usage is to add an event listener for beforematch on the host element or to detect support and attach handlers globally. Because removal of hidden happens before scrolling, your handler can ensure controls are visible and focusable by the time the browser scrolls.

Remember that the sequence is driven by the UA: the event, the attribute removal, and the scroll are ordered so authors have a deterministic point to update state. That solves many of the flaky timing hacks developers used previously to make collapsed content searchable.

Browser support timeline and current availability

Support for hidden=until-found has rolled out across browsers over several years. Chrome and Edge shipped the feature in Chrome 102 in late May 2022. Firefox added support much later in Firefox 139, released May 27, 2025. WebKit enabled support in Safari Technology Preview notes around Sep 17, 2025.

Despite these milestones, baseline availability remains limited while vendor interop and wider rollout finish. The web-platform and Chrome-status trackers list the feature under limited availability and interoperability work continues in some engines.

Adoption in the wild is still small: the Web-Platform/Chrome-status aggregator cites roughly 0.201% of page loads using hidden=until-found. That low usage means authors should plan fallbacks for audiences that do not yet use supporting browsers.

SEO and search-engine behavior

Modern guidance from browser vendors indicates that hidden=until-found content can be targeted and linked by search. Both browsers and Google Search can form links that scroll to revealed fragments inside hidden=until-found content, making such content linkable in search results.

However, SEOs and developers have debated whether hidden content is treated differently by indexers. Current signals suggest that hidden-but-findable content is increasingly accepted, but authors should test how content is indexed and whether search snippets or analytics behavior meet expectations.

Practical advice is to monitor search results and analytics after adding hidden=until-found, and to provide clear markup and fallbacks so essential content remains accessible to both users and crawlers regardless of engine behavior.

Accessibility considerations and recent changes

Early adoption revealed accessibility pitfalls: in some browsers hidden=until-found behaved like ordinary hidden and was inaccessible to assistive technologies. That led to guidance recommending testing with screen readers and possibly providing ARIA fallbacks.

Work in WebKit during 2025 improved behavior by adding auto-expansion for text searches performed via assistive technologies, addressing a key concern for screen reader users. Despite this progress, authors should still test with real assistive tech because behaviour can vary by engine and version.

As with any visibility toggle, ensure that keyboard focus, ARIA attributes, and semantics are handled when an element is revealed. Use the beforematch hook to synchronise ARIA-expanded states or to move focus where appropriate so the revealed content is usable immediately.

Authoring caveats: CSS, layout, and detection

Hidden=until-found requires the element to participate in layout to be revealable: elements using display:none, display:contents, or those that are inline may not be revealed by find-in-page or fragment navigation. Global CSS that forces display values can also override the intended hidden behavior.

Because browsers use content-visibility to implement the feature, layout APIs like getBoundingClientRect may report sizes and positions for a host element even though its children are not rendered. Authors should avoid assumptions that rendered child content dimensions are present until after reveal.

Feature-detection is straightforward: check for onbeforematch support for the most direct signal, for example by testing whether ‘onbeforematch’ in document.. If unsupported, provide sensible fallbacks such as expanding critical sections by default or adding scripted detection to keep content findable.

Common uses, practical caveats, and a checklist for adoption

Common use cases include progressive disclosure patterns like accordions and tabs, large FAQ pages where each answer is hidden until needed, icon-only buttons that include hidden labels, and other scenarios where content should be visually reduced but remain searchable. The Chrome Dev docs even note that hidden=until-found and beforematch can solve collapsed content searchability problems.

Practical caveats include ensuring your element is not display:none, avoiding display:contents for the host, and being mindful of layout space contributed by the host even when children are not rendered. Also watch out for global CSS rules that could unintentionally force display values.

Quick adoption checklist: (1) confirm browser support for your audience; (2) add beforematch handlers to keep UI state in sync; (3) feature-detect and provide fallbacks; (4) test with screen readers and search indexing; (5) avoid relying on display:none on the same element. Use the WHATWG spec, Web Platform Tests, and vendor docs for hands-on verification and examples.

Testing resources and where to follow progress

To verify behaviour and experiment, consult the HTML Standard for the spec, the Web Platform Tests and feature trackers for interoperability status, and the Chrome Dev and MDN docs for examples and caveats. Those resources are actively maintained as implementations evolve.

Implementation tracking and bug tracker pages in WebKit and other engines show the stepwise work that enabled hidden=until-found. If you rely on a particular browser build or need to follow a fix, the bug report pages are the place to watch for commits and test case changes.

Finally, because adoption is not yet universal, include manual testing in your QA matrix: keyboard and screen reader flows, fragment links that should reveal content, and analytics checks to ensure search-driven sessions reach the intended content.

Hidden=until-found is a practical, standards-based tool for making hidden content findable without sacrificing layout or design. It gives authors a reliable browser-driven sequence to reveal content in response to find-in-page and fragment navigation while offering hooks to keep UI state consistent.

Adopting hidden=until-found thoughtfully, mindful of browser support, accessibility, and CSS caveats, lets you deliver cleaner interfaces that remain discoverable. Use feature detection, test broadly, and follow the spec and engine trackers as the feature matures across the web.