Styling Ctrl+F Results with ::search-text

For years, styling browser find-in-page highlights with CSS was simply not possible. The browser owned that UI entirely. You could customize ::selection for mouse-selected text, but the moment a user pressed Ctrl+F, your stylesheet had no say. That’s starting to change — at least in Chromium-based browsers.

The ::search-text pseudo-element is a new, experimental CSS feature that lets you style the highlights produced by the browser’s native find-in-page function. Here’s what it does, how it works, and what to realistically expect from it right now.

What ::search-text Actually Does

When a user triggers Ctrl+F (or Cmd+F on macOS) and types a query, the browser highlights matching text on the page. Historically, those highlights were painted entirely by the browser’s user-agent layer — outside the reach of any author stylesheet.

::search-text is a CSS highlight pseudo-element, part of the same family as ::selection, ::target-text, and ::spelling-error. It targets the text fragments the browser marks during a find-in-page session, giving you a hook to apply custom styles.

Basic Usage

The syntax is straightforward:

::search-text {
  background-color: oklch(85% 0.2 90);
  color: black;
}

You can also target the currently active match — the one the browser is focused on as you cycle through results — using the :current state:

::search-text:current {
  background-color: oklch(70% 0.25 60);
  color: white;
}

This distinction matters for UX. Without :current, every match looks identical. With it, you can visually differentiate the focused result from the rest, which is exactly how browsers style it natively.

What Styles Are Actually Supported

::search-text follows the same constraints as other CSS highlight pseudo-elements. You’re limited to a specific subset of paint-related properties:

• color
• background-color
• text-decoration (and related sub-properties)
• text-shadow

Layout properties like padding, margin, border, or font-size have no effect. The highlight layer is painted on top of existing content — it doesn’t reflow anything.

How It Differs from the CSS Custom Highlight API

It’s worth clarifying the distinction here, since both involve CSS highlight pseudo-elements.

The CSS Custom Highlight API lets you define your own named highlights via JavaScript using Range objects and CSS.highlights.set(). You then style them with ::highlight(your-name). It’s powerful, but it requires JavaScript, and you control which text gets highlighted.

::search-text is different: the browser controls what gets highlighted (whatever matches the find-in-page query), and you only control the visual style. No JavaScript needed. No knowledge of the search query required.

Browser Support: Experimental and Chromium-Only

This is the part that matters most for production decisions. As of early 2026, ::search-text is only available in Chromium-based browsers from version 144 onward — Chrome and Edge on desktop. Firefox and Safari do not support it yet. You can track current support on Can I use.

Treat this as a progressive enhancement. Browsers that don’t support ::search-text will simply ignore the rule and fall back to their default highlight styling. That’s fine — the feature degrades gracefully.

/* Only applies in supporting Chromium browsers */
::search-text {
  background-color: #ffe066;
  color: #111;
}

::search-text:current {
  background-color: #f5a623;
  color: white;
}

Feature queries like @supports selector(::search-text) are not required for safe fallback, but can be useful if you want to scope styles or communicate support more explicitly.

Worth Adding Now

::search-text won’t replace the browser’s default behavior for most users today. But for teams building polished reading experiences — documentation sites, content-heavy apps, design systems — it’s a low-cost, zero-JavaScript way to bring find-in-page highlights in line with your visual language, at least for users on modern Chromium browsers.

Add it to your stylesheet, pair it with :current for active-match differentiation, and keep an eye on Firefox and Safari support as the spec matures.

Conclusion

The ::search-text pseudo-element closes a small but long-standing gap in CSS by letting authors style browser find-in-page results. While support is currently confined to Chromium browsers, the API is simple, requires no JavaScript, and degrades cleanly in unsupported environments. For sites where reading experience matters, it’s a straightforward addition that brings native browser UI a step closer to your design system.

FAQs

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..