Find and Replace

About Find and Replace Tool

The Find and Replace tool is a powerful text search and replacement utility with advanced features including regular expression support, case-sensitive and case-insensitive search, whole word matching, preserve case option for smart replacement, and both batch (replace all) and step-by-step (replace next) replacement modes. The tool highlights matches in the output for easy verification and provides real-time statistics including match count, replacements made, and current position. Perfect for text editing, data cleanup, code refactoring, content migration, and batch text processing tasks.

How do I use regex in find-and-replace and what are the most useful patterns?

Enable the "Use regular expressions" option and your search becomes a pattern, not a literal string. Essential patterns: \d+ matches any run of digits, \s+ matches any whitespace run, \w+ matches word characters, .+ matches anything (greedy), [A-Za-z]+ matches letters only, ^foo matches "foo" at line start, foo$ at line end. Capture groups with parentheses let you reuse the match: (\w+)@(\w+) captures username and domain, and $1 / $2 in the replacement field references them. Backreferences let you swap: (\w+) (\w+) replaced with $2 $1 swaps adjacent words. Always test on a small sample first — regex bugs are silent and can corrupt entire documents. Use the highlight feature to verify matches before clicking Replace All.

What's the difference between greedy, lazy, and possessive regex quantifiers?

Greedy quantifiers (*, +, ?, {n,m}) match as much as possible, then backtrack until the rest of the pattern fits. So <.+> on "<a><b>" matches the entire "<a><b>" because .+ greedily consumes everything between the first < and last >. Lazy quantifiers (*?, +?, ??, {n,m}?) match as little as possible: <.+?> on the same input matches just "<a>." Lazy is what you usually want when extracting tags or content between delimiters. Possessive quantifiers (*+, ++) match greedily and refuse to backtrack — they fail rather than retry, which prevents catastrophic regex backtracking on malicious input. JavaScript regex does not support possessive quantifiers natively; use atomic groups (?>...) where available. Most editors and this tool use ECMAScript regex syntax with greedy and lazy support.

How does "preserve case" decide what casing to use for the replacement?

Preserve case is a heuristic that inspects the original match and applies the same case pattern to the replacement. The rules in this tool are: if the matched text is all lowercase ("hello"), keep the replacement as you typed it ("hi"). If all uppercase ("HELLO"), uppercase the replacement ("HI"). If only the first letter is capitalized ("Hello"), capitalize the replacement ("Hi"). Mixed case ("hELLo") usually falls back to the typed form. This is useful for renaming variables across documentation, swapping product names that appear in titles and body text, or replacing terms while preserving sentence-start capitalization. It only applies to plain-text searches, not regex — for regex, use case-aware capture groups and conditional replacement patterns in your scripting language.

What does "match whole word only" actually do and when should I use it?

Match whole word only wraps your search pattern with word boundary anchors (\b on both sides). A word boundary is the zero-width position between a word character (letter, digit, underscore) and a non-word character (space, punctuation, end of string). So searching for "cat" with whole-word on matches "cat" in "The cat ran" but skips "category," "scatter," and "cats." Use this when replacing variable names in code ("i" should not match "is"), product names in copy ("Pro" should not match "Processor"), or short common words. Caveat: in languages where word boundaries are not whitespace-based (Vietnamese compound syllables, Chinese, Japanese), \b may not behave as expected. For those scripts, build explicit positive/negative lookarounds instead.

How do I do a batch find-and-replace across many lines or sections of a document?

Use Replace All for the simple case — one search, one replacement, applied everywhere. For sequential transformations (find A replace with B, then find C replace with D, then find E replace with F), do them one at a time and verify each step. Beware order-of-operations bugs: if you replace "cat" with "dog" and then "dog" with "mouse," the original cats become mice, which you probably did not intend. For complex multi-step rewrites, paste the result of each step into a fresh field rather than chaining in place. For truly batch jobs across many files, this in-browser tool is fine for one document at a time; for hundreds of files, use sed (Unix), PowerShell, or VS Code's multi-file search-and-replace.

How can I use regex with capture groups to reformat data like dates, phone numbers, or names?

Capture groups parenthesize parts of the match for reuse in the replacement. To convert US dates MM/DD/YYYY to ISO YYYY-MM-DD: find (\d{2})/(\d{2})/(\d{4}) and replace with $3-$1-$2. To swap "Last, First" to "First Last": find (\w+), (\w+) replace with $2 $1. To standardize phone formats from any digit grouping to (XXX) XXX-XXXX: find (\d{3})\D*(\d{3})\D*(\d{4}) replace with ($1) $2-$3. Named groups (?<name>pattern) are clearer for complex patterns: (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2}) referenced as $<year>, $<month>, $<day>. Always test on a few samples before running on the full document — anchors (^, $, \b) help avoid partial matches that produce garbled output.

What are common regex pitfalls that destroy text and how do I avoid them?

Five classics: (1) Forgetting to escape regex metacharacters — searching for "." matches any character; you need \. for a literal period. (2) Greedy matching across line breaks — .* on "<a>foo</a><b>bar</b>" without lazy modifier matches the whole string. (3) Catastrophic backtracking — patterns like (a+)+ on "aaaab" can take exponential time; use atomic groups or possessive quantifiers. (4) Anchoring confusion — ^ matches start of string by default, start of line only with multiline mode. (5) Replacing inside replacements — if you swap "old" → "new old" the tool only replaces once per match position, but unbounded recursive substitutions in some engines can hang. Always: test on sample text, use the highlight feature to preview, keep a backup of original text, and replace one step at a time when transformations chain.

How does find-and-replace work for code refactoring vs. natural-language text?

Code refactoring needs syntactic awareness that plain regex cannot provide. "Replace "foo" with "bar"" in code can wrongly hit strings, comments, and identifiers that happen to contain "foo." For code, prefer language-aware tools: VS Code's symbol rename (F2), IntelliJ refactor, jscodeshift for JavaScript, libcst for Python. They parse the AST and rename only actual identifiers, leaving strings and comments intact. Natural-language find-and-replace is more forgiving but has its own traps: case-insensitive substitution can mangle proper nouns ("Apple" becoming "apple"), pluralization may leave orphaned suffixes ("cats" after replacing "cat" with "dog" becomes "dogs" only if you set up the rule that way), and word boundaries may misfire across hyphens. Use this tool for prose, drafts, and one-off transforms; reach for AST-based refactoring tools for production code changes.

How does Multi-rule batch replace work?

Enable "Multi-rule batch replace" to apply a whole ruleset in one auditable pass instead of running replacements one at a time. A textarea appears where you enter one rule per line as find => replace (you can also separate the two sides with a Tab). For example: colour => color, then U.S.A. => USA, then => (collapse double spaces). Rules run top to bottom in order, so order matters — put earlier normalizations before rules that depend on them, and avoid loops like cat => dog then dog => mouse unless you intend cats to become mice. Every option above (regex, case sensitivity, whole word, multiline, preserve case) applies to all rules, so regex rules can use capture groups too. Blank lines and lines starting with # are skipped, so you can comment and group your rules. After Replace All, the toast reports how many rules matched and the total replacement count. This is the fastest way to do glossary normalization, content migration, and CSV/log cleanup that used to require chaining many manual passes.

Why do $1 and $2 backreferences now insert the captured text correctly?

Capture-group backreferences work in the replacement field for both Replace All and Replace Next. Wrap parts of your pattern in parentheses and reference them with $1, $2, $3 (or $<name> for named groups) in the Replace With field. Worked examples: to convert US dates MM/DD/YYYY to ISO, find (\d{2})/(\d{2})/(\d{4}) and replace with $3-$1-$2 so 06/15/2024 becomes 2024-06-15. To swap "Last, First" to "First Last", find (\w+), (\w+) replace with $2 $1. To reformat dashed dates to slashes, find (\d{4})-(\d{2})-(\d{2}) replace with $3/$1 yielding 02/2024-style output. Named groups: find (?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2}) replace with $<d>/$<m>/$<y>. Note these tokens expand only when "Use regular expressions" is enabled; in plain-text mode $1 is treated as literal characters. Use the highlight preview to confirm your groups capture what you expect before clicking Replace All.

Example Find and Replace Operations