In-page text find for the browser
Search webpage text like a code editor, with case matching, result navigation, and custom highlights.
Facts worth checking first
- What it does: Search webpage text like a code editor, with case matching, result navigation, and custom highlights.
- Page content, selections, and generation results stay on this device by default and are not uploaded to KnowIt.
- Free once the extension is installed.
Design notes: Text Search
1. Why this tool exists
The browser's built-in find-in-page carries a few limitations that have frustrated developers and heavy users for years:
- Fixed position: The search bar is locked to the top or bottom of the browser window and cannot be moved, so it regularly covers the content you are reading — especially awkward when you need to compare a match against the text around it.
- Limited matching: There is no case-sensitive matching, so it cannot tell React from react, or API from api — distinctions that matter a great deal to developers.
- No advanced patterns: Regular expressions are not supported, which leaves you stuck whenever the target is a complex pattern: every email address on the page, dates in a particular format, several keywords at once.
Together these gaps make native find-in-page a poor fit for development work, document review, technical writing, and anything else that calls for precise text handling. Text Search aims to be a more flexible, more capable in-page search tool that matches how developers already work.
2. Design direction
The UI borrows directly from VS Code's search experience. That is not an arbitrary choice — VS Code's find panel is an efficient interaction pattern validated daily by an enormous number of developers, and its layout, visual hierarchy, and feedback are all worth following. For a tool aimed at developers, reusing a familiar mental model cuts the learning curve to almost nothing.
3. Core principles
1. Movable first
The search bar should not be an appendage bolted onto the page; it should be a panel you position yourself. Drag it wherever it stays out of your line of sight and within easy reach of what you are reading. A search tool should adapt to where your attention goes, rather than making you work around it.
2. Precise matching, case included
For developers and technical writers, case is not a cosmetic difference — it is a semantic one. String is a type, string is a keyword; Apple is a company, apple is a fruit. Supporting case-sensitive matching is, at heart, respecting how precise text is.
3. Leave room for power users
Regular expressions are the sharpest tool in text processing. This version focuses on the two most pressing pain points, movability and case matching, but the matching engine is designed to be extensible, with a clear interface reserved for regex. A tool should start from the simple cases without putting a ceiling on what it can do.
4. Stay light, stay in the flow
Search is frequent, brief, and threaded between reading and editing. The tool should open instantly and close instantly, add no startup cost, and never break your concentration. A lightweight floating panel, rather than something that takes over the page, is what that principle looks like in practice.