JavaScript Element beforematch Event

Beginner
⏱️ 10 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
DOM event
Instance event

What You’ll Learn

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

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.”

Understanding beforematch

An instance event that answers: “A find-in-page or fragment match is about to reveal this hidden-until-found element.”

  • Requires hidden="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).

📝 Syntax

Use the event name with addEventListener, or set the handler property:

JavaScript
addEventListener("beforematch", (event) => { });

onbeforematch = (event) => { };

Event type

A generic Event.

HTML partner attribute

JavaScript
<div id="secret" hidden="until-found">
  Searchable content lives here.
</div>

🔁 The Reveal Sequence

When find-in-page or a fragment link causes a scroll into a hidden-until-found subtree, the browser does this (from MDN):

  1. Fire a beforematch event on the hidden element.
  2. Remove the hidden attribute from the element.
  3. Scroll to the element.

Your handler runs while the element is still conceptually “about to be shown,” so you can prepare UI before users see the final content.

⚖️ Boolean hidden vs until-found

Topichidden (boolean)hidden="until-found"
Visible in layout?NoNo (until revealed)
Find in page?Typically skippedSearchable
Fragment links?Usually not useful while hiddenCan reveal + scroll
beforematch?Does not applyFires before reveal

⚡ Quick Reference

GoalCode / note
Mark searchable-hiddenhidden="until-found"
Listenel.addEventListener("beforematch", fn)
Handler propertyel.onbeforematch = fn
Trigger (lab)Link to #id or use find in page
Feature-detect"onbeforematch" in document.documentElement
MDN statusBaseline Newly available (Dec 2025)

🔍 At a Glance

Four facts to remember about beforematch.

Event type
Event

Generic event

Partner
until-found

hidden value

Triggers
find / #id

Search or fragment

Baseline
2025

Newly available

Examples Gallery

Examples follow MDN Element: beforematch event. In try-it labs, click the fragment link (or use find in page) to reveal the box.

📚 Getting Started

Register handlers and update content when a match is about to reveal the element.

Example 1 — addEventListener("beforematch")

MDN idea: change the text just before hidden is removed.

JavaScript
const untilFound = document.querySelector("#until-found-box");

untilFound.addEventListener("beforematch", () => {
  untilFound.textContent = "I've been revealed!";
});
Try It Yourself

How It Works

The handler runs first. Then the browser removes hidden and scrolls so the updated text is visible.

Example 2 — onbeforematch Property

Same reveal hook using the event handler property.

JavaScript
const box = document.getElementById("until-found-box");

box.onbeforematch = () => {
  console.log("about to reveal:", box.id);
  box.textContent = "Opened via onbeforematch";
};

// Assigning again replaces the previous onbeforematch handler.
Try It Yourself

How It Works

Prefer addEventListener when you need multiple listeners or easy removal.

📈 Fragment, Prepare & Detect

Trigger with a hash link, prepare UI, and feature-detect support.

Example 3 — Reveal with a Fragment Link

A link to #until-found-box is an easy way to demo the event (as on MDN).

JavaScript
<a href="#until-found-box">Go to hidden content</a>

<div>I'm not hidden</div>
<div id="until-found-box" hidden="until-found">Hidden until found</div>

<script>
  const box = document.querySelector("#until-found-box");
  box.addEventListener("beforematch", () => {
    box.textContent = "I've been revealed!";
  });
</script>
Try It Yourself

How It Works

Fragment navigation targets the id. If the element is hidden until found, the browser runs the reveal sequence—including beforematch.

Example 4 — Prepare UI Before Reveal

Use the event to stamp a timestamp or highlight class before users see the section.

JavaScript
const panel = document.getElementById("faq-panel");
const status = document.getElementById("status");

panel.addEventListener("beforematch", () => {
  panel.classList.add("was-found");
  status.textContent = "Revealed at " + new Date().toLocaleTimeString();
});
Try It Yourself

How It Works

Great for analytics, lazy text, or styling that should apply the moment the section opens via search or deep link—not only via a manual expand button.

Example 5 — Feature Detection

Check for the handler property before relying on beforematch.

JavaScript
function isBeforeMatchAvailable() {
  return "onbeforematch" in document.documentElement;
}

console.log("beforematch available:", isBeforeMatchAvailable());

const box = document.getElementById("until-found-box");
if (isBeforeMatchAvailable()) {
  box.addEventListener("beforematch", () => {
    box.textContent = "Revealed with beforematch support";
  });
} else {
  console.log("Fall back: use a details/summary or expand button");
}
Try It Yourself

How It Works

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.

🚀 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".

🔧 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.

📝 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.
  • Related learning: beforeinput, beforescriptexecute, JavaScript hub.

Baseline Newly Available

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.

New Newly available
Google Chrome Supported · Modern Chromium
Supported
Mozilla Firefox Supported · Recent releases
Supported
Apple Safari Supported · Recent macOS & iOS
Supported
Microsoft Edge Supported · Chromium
Supported
Opera Supported · Modern versions
Supported
Internet Explorer No beforematch / until-found
Unavailable
beforematch Baseline 2025

Bottom line: Use hidden="until-found" with beforematch to prepare UI before searchable content is revealed; test find-in-page and #fragment paths.

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.

Continue with beforescriptexecute, addEventListener(), or the JavaScript hub.

💡 Best Practices

✅ Do

  • Prefer addEventListener("beforematch", ...)
  • Use hidden="until-found" for searchable collapse
  • Give the element a stable id for fragment links
  • Feature-detect and offer a manual expand control
  • Test both find in page and #hash navigation

❌ Don’t

  • Expect beforematch on plain boolean hidden
  • Assume older browsers support until-found
  • 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

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
⏱️ 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.

Next: beforescriptexecute

Learn the deprecated Gecko event that could cancel a script before it ran.

beforescriptexecute →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

5 people found this page helpful