Writing the rule list
One rule per line, find => replace. If a line contains => more than once the first one is the separator, so a => b => c means "find a, replace it with b => c". Leaving the right-hand side empty deletes every match, which is how you strip a recurring watermark line or a draft marker. A line starting with # is skipped, so you can annotate a list you intend to reuse — which list this is, who it was built for, and why a particular substitution exists.
The second separator option is the one that saves real time. Terminology lists, brand-name changes and translation glossaries usually already live in a spreadsheet as two columns. Copy both columns, switch the separator to tab, and paste: the clipboard already contains tab-separated text, so the rules load as they stand with no reformatting.
Spaces are a decision, not an accident
By default the spaces around each side of a rule are trimmed, so 2025 => 2026 does what it looks like rather than searching for "2025 " with a trailing space and inserting " 2026" with a leading one. Written the other way that mistake is invisible in the rule list and obvious only in the output.
Sometimes the spaces are the point: collapsing double spaces into single, stripping a two-space indent, adding a space after a colon. Switch on the exact-spaces option and every character you typed is taken literally, including the ones at the ends. Leave it on for ordinary rules and most of them will come back as "no match", so switch it on only for the pass that needs it.
Order decides the outcome
Rules apply top to bottom, and each one operates on the text the previous rules produced. Write A => B above B => C and every original A ends up as C, which is occasionally intended and usually an accident. The tool scans the list for that shape and names the two lines involved underneath the result.
The same ordering explains a fair share of the "no match" flags. A rule that would have worked on the original text can find nothing left because a rule above it already rewrote that region. Read the hit counts downward and the point where the intent diverged is usually obvious. The fix is either reordering, or routing one substitution through a placeholder string that nothing else in the list touches.
What literal matching cannot do
There is no whole-word matching, so a rule for art also hits start and partner. Include the surrounding characters — a leading space, a trailing comma — to narrow a short word, or move to the regex tool where \b exists. There is no way to express "three digits in a row" or "trailing whitespace at end of line". The find side cannot contain a newline either, so joining two lines into one is out of reach here; the replacement side can insert newlines if you switch on the escape option.
Non-Latin text is handled the same way as everything else: matching is by code point, so Cyrillic, Arabic, Han, kana and Hangul all substitute correctly, and case-insensitive matching uses the browser's own case rules, which are a no-op for scripts without case. The one thing to watch in any script is invisible variation — a no-break space, a soft hyphen, or a decomposed accent — because a rule typed with the ordinary character will not match text containing the lookalike. The caps are 200,000 characters and 300 rules; beyond either, the tool truncates and says so rather than stalling.
Questions people ask
How do I just delete a word?
Leave the replacement side empty: obsolete phrase =>. The match is removed and nothing is inserted. The rule table marks that side as deliberately empty so you can tell an intentional deletion from a rule you forgot to finish. Deleting a word mid-sentence often leaves a double space behind; add a rule for two spaces to one space, switch on the exact-spaces option, and put it last in the list.
Can I add or remove line breaks?
You can add them. Switch on the escape option and write \\n in the replacement, so a rule like . => .\\n starts a new line after each sentence-ending period. You cannot remove them, because the find side cannot contain a newline — joining lines is a different operation and belongs in the batch line cleaner, which has a join step.
Why does a rule say "no match" when I can see the text?
Three causes, in rough order of frequency. The rule and the text differ by a character you cannot see — a no-break space pasted from a web page, a curly apostrophe where you typed a straight one, a decomposed accent. Case is being matched and the text is capitalised differently. Or a rule above it already rewrote that passage, which the hit counts in the table will show if you read them from the top down.
Can I save a rule list and reuse it?
Not on this page — nothing is stored, and a refresh clears both boxes. Keep frequently used lists in a note or a spreadsheet and paste them back in. Comment lines starting with # are ignored by the parser, so a stored list can carry its own documentation without affecting the result.