The beforematch event fires on an element in the hidden until found state just before the browser reveals it—when find-in-page or a fragment link matches that content. Learn hidden="until-found", addEventListener vs onbeforematch, the reveal sequence, and five try-it labs.
01
Kind
Instance event
02
Type
Generic Event
03
When
Before reveal
04
Handler
onbeforematch
05
Needs
hidden="until-found"
06
Status
Baseline newly available
Fundamentals
Introduction
Sometimes you want content to stay collapsed until the user searches for it or jumps to its id. HTML supports that with hidden="until-found". The element is not shown in the page layout, but the browser can still find its text and navigate to it.
Right before the browser removes hidden and scrolls into view, beforematch fires. That is your chance to update text, load data, or log that the section was revealed by search or a deep link.
💡
Beginner tip
Ordinary hidden (boolean) hides content from find-in-page. Use hidden="until-found" when you want “collapsed but searchable.”
Concept
Understanding beforematch
An instance event that answers: “A find-in-page or fragment match is about to reveal this hidden-until-found element.”
Requireshidden="until-found" on the element (or an ancestor subtree case the browser scrolls to).
Triggers from find in page or fragment navigation (#id links).
Event type — a plain Event (no special fields).
Order — fire beforematch → remove hidden → scroll.
Baseline Newly available on MDN (since December 2025).
Foundation
📝 Syntax
Use the event name with addEventListener, or set the handler property:
If until-found is unsupported, hidden may behave like a plain boolean hide—content stays hidden and will not open via find-in-page. Always plan a fallback expand control for older browsers.
Applications
🚀 Common Use Cases
FAQ or docs sections that stay collapsed but remain searchable.
Updating copy or loading details the moment a deep link opens a panel.
Analytics when users discover content via find in page.
Highlighting a section that was revealed by fragment navigation.
Progressive enhancement on top of hidden="until-found".
Under the Hood
🔧 How It Works
1
Content is hidden until found
Element uses hidden="until-found" and stays off-layout.
State
2
User finds or deep-links
Find in page matches text, or a #id fragment targets it.
Trigger
3
beforematch fires
Your listener can update text, classes, or load data.
Event
4
✓
hidden removed + scroll
The element becomes visible and the viewport moves to it.
Important
📝 Notes
MDN: Baseline Newly available (since December 2025).
Not Deprecated, Experimental, or Non-standard — no status banner required.
Without until-found support, hidden may act as a plain boolean hide.
Event type is a generic Event—no InputEvent-style fields.
beforematch is marked Baseline Newly available on MDN (since December 2025). Logos use the shared browser-image-sprite.png sprite from this project. Feature-detect and keep a manual expand fallback for older browsers.
✓ Baseline · Newly available
Element beforematch
Works across the latest desktop and mobile browsers for hidden-until-found reveal via find in page and fragment navigation.
NewNewly available
Google ChromeSupported · Modern Chromium
Supported
Mozilla FirefoxSupported · Recent releases
Supported
Apple SafariSupported · Recent macOS & iOS
Supported
Microsoft EdgeSupported · Chromium
Supported
OperaSupported · Modern versions
Supported
Internet ExplorerNo beforematch / until-found
Unavailable
beforematchBaseline 2025
Bottom line: Use hidden="until-found" with beforematch to prepare UI before searchable content is revealed; test find-in-page and #fragment paths.
Wrap Up
Conclusion
beforematch is the “about to reveal searchable-hidden content” signal. Pair it with hidden="until-found", listen with addEventListener, and prepare your UI before the browser removes hidden and scrolls.
Rely on special event properties—it is a generic Event
Skip accessibility: still provide a clear way to open content
Overwrite onbeforematch if you need multiple listeners
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about beforematch
Searchable-hidden content is about to open—prepare, then the browser reveals it.
5
Core concepts
🔎01
until-found
hidden partner
HTML
⏱️02
Before reveal
then unhide + scroll
Order
📄03
Generic Event
no special fields
API
🔗04
find / #id
common triggers
Trigger
🎯05
Baseline 2025
newly available
Compat
❓ Frequently Asked Questions
An element receives beforematch when it is in the hidden until found state and the browser is about to reveal its content because the user found it via find in page or fragment navigation.
No. MDN marks Element beforematch as Baseline Newly available (since December 2025). It is not Deprecated, Experimental, or Non-standard.
A generic Event. There are no special beforematch-only properties beyond the usual Event interface.
Set the HTML hidden attribute to until-found (hidden="until-found"). The element stays visually hidden but remains searchable and reachable by fragment links. When a match scrolls to it, the browser fires beforematch, removes hidden, then scrolls.
First beforematch fires on the hidden element, then the browser removes the hidden attribute, then it scrolls to the element.
A practical check is: "onbeforematch" in document.documentElement (or HTMLElement.prototype). Also verify hidden="until-found" behavior in your target browsers.
Did you know?
If a browser does not understand hidden="until-found", it may treat hidden as the older boolean attribute—so the element stays hidden and find-in-page will not reveal it. Always ship a visible control as a fallback.