Loading Find and Replace Tool…
Type something to find.
In plain text mode nothing you type is treated as a pattern: 1.5 matches “1.5” and not “165”, and a replacement of $100 inserts exactly that. Both are silent traps in tools that pass your text straight to a regular expression.
Renaming a product across a press release, swapping a placeholder for a real figure, correcting a surname spelled three ways in a long report. Paste the document, say what to find and what to put in its place, and the tool reports how many matches it found and which lines they fall on before you take the result away.
The options are the ones that decide whether a replacement is right or ruinous: match case, whole words only, regular expressions, reading \n and \t in the boxes as a line break and a tab, and replacing only the first match instead of all of them.
"Cat cat CAT", finding "cat" and replacing with "dog", gives 3 matches and "dog dog dog". Switch match case on and the same run gives 1 match and "Cat dog CAT", because only the middle word is spelled the way the search was typed.
"cat catalogue cat" with whole words only gives 2 matches and "dog catalogue dog". The word in the middle is left alone, which is the entire difference between a rename and a mess.
A regular expression of (\w+), (\w+) replaced with $2 $1 turns "Smith, John" into "John Smith" — a column of surname-first names reordered in one pass.
Both produce a wrong document that looks exactly like a right one, which is why they are worth stating.
In plain text mode the search string is escaped before it is used, so searching for "1.5" matches "1.5" and nothing else. An unescaped search is a pattern rather than a literal, and in a pattern "." means any character, so the same search would otherwise also match "165". A tool that skips this step quietly edits numbers nobody ever looked at.
In plain text mode every "$" in the replacement is escaped as well. String.replace reads "$&", "$1" and "$$" in a replacement as instructions rather than as text, so replacing a word with the literal "$100" inserts something else entirely anywhere that escaping has been left out.
In regular expression mode those substitutions are deliberately left working, because they are the reason to be in that mode. $1 and $2 are how a captured group gets moved, and escaping them away would remove the feature along with the bug.
A pattern that is capable of matching nothing does not hang the tool. Running x* over "abc" and replacing with a hyphen produces "-a-b-c-" and reports 4 matches, which is the correct answer for a pattern that matches an empty string at every position including the end of the text.
An invalid expression is reported as an error rather than silently ignored. Handing back the text unchanged with a match count of zero would look identical to a search that simply found nothing.
Whenever the search term also appears inside longer words. Renaming "id" without it matches inside "video" and "identity" too, and that damage is scattered through the document rather than concentrated somewhere you can see it.
In regular expression mode a dollar followed by a digit or an ampersand is a back-reference, so it gets consumed instead of printed. Write $$ for a literal dollar there, or use plain text mode, where the escaping is handled for you.
Turn on the setting that reads escape sequences in the boxes, then type \n wherever the break belongs. The same setting reads \t as a tab, the other character that cannot simply be typed into a single-line field.
Because a count on its own never tells you whether the matches are the ones you meant. Seeing that a search hit lines 4, 9 and 210 is often enough to notice that the last one is a quotation you should not touch.