Find and Replace Text_
Replacing one thing at a time changes the answer. Swap two words — cat for dog and dog for cat — and applying the rules in order gives you dogs everywhere, because the first rule's output is the second rule's input. Every find-and-replace tool works that way, and it is wrong for the job people most often have.
So this one replaces in a single pass: every rule considered at each position, and nothing a rule produces is ever read again. It also says when your rules would have interfered, and why a search that looks correct matched nothing.
- Input
- Text, and as many find-and-replace pairs as you need. Everything is literal — no pattern syntax, so a full stop means a full stop.
- Output
- The result of applying every rule in one pass, with a count per rule so a pair that matched nothing is visible rather than silent.
- Processing
- One left-to-right scan. At each position the longest matching search wins, so the order the rules are written in only breaks ties.
- Limits
- Literal text only. For patterns, capture groups and backreferences the regex tester is the right tool — this one deliberately has no pattern syntax to get wrong.
- Why the longest rule wins rather than the first
- If one rule searches for "New York" and another for "New York City", the order they happen to be listed in should not decide which applies. The longer match is more specific and is what anybody means, so it takes precedence and the written order is used only when two searches are the same length.
One pass, not one rule after another
Why swapping two words does not work
Ask any editor to replace cat with dog and then dog with cat, and every animal in the document ends up a cat. The first pass converts the cats, the second converts them back along with the original dogs, and nothing warns you. It is not a bug in the editor — sequential replacement genuinely does that — but it is never what anyone wanted, and the usual workaround is to invent a placeholder nobody will type and do three passes instead of two.
A rename list has the same problem, more quietly
Renaming staging to production and production to archive in the same run collapses both into archive. With two rules the mistake is obvious once you look; with fifteen it is not, and the output is plausible enough to ship. Replacing in one pass removes the failure mode rather than asking you to notice it — and this page also says when the two approaches would have differed, so you can see that your rules were interfering.
The search that matches nothing
Text copied out of a word processor, a PDF or a spreadsheet is full of characters that are not the ones you would type. A no-break space is not a space. A curly apostrophe is not an apostrophe. An en dash is not a hyphen, and a zero-width space is nothing at all — and none of them looks any different on screen. This is nearly always the answer to "why does my search not match", so the tool names the ones it finds and offers to convert them to their plain equivalents.
Match case and preserve case are different options
Match case decides what counts as a hit. Preserve case decides what the replacement looks like — write one rule in lower case and colour, Colour and COLOUR all come out correctly capitalised. Most tools offer only the first, which is why a case-insensitive replacement usually flattens everything to however the replacement happened to be typed. Anything genuinely mixed, like cOlOuR, is left alone rather than guessed at.
A dollar sign in the replacement is not always a dollar sign
In JavaScript, $&, $1 and $$ are substitutions inside String.replace, which means a replacement containing a price can silently lose characters — $5.00 is capture group five as far as the engine is concerned. Python's re.sub does the same with backslashes. Everything on this page is literal, and it says so when a replacement contains a sequence that would behave differently in code.
When you want the other tool
This page has no pattern syntax at all, on purpose: a full stop means a full stop and brackets mean brackets, so there is nothing to escape and nothing to get wrong. The moment you need a wildcard, a capture group or a backreference, that is a different job — the regex tester has a replace mode built for exactly it, with the match table and the group numbering that make a pattern debuggable. Literal text here, patterns there.
Add the pairs, paste the text, read the counts
- 01Add a rule for each replacement. They all run together, so a swap or a rename chain works the way you expect.
- 02Paste the text underneath. The result updates as you type.
- 03Check the count beside each rule. A rule that matched nothing is the most useful thing on the page — it means the search text is not what is actually in the document.
- 04Press Fix invisibles if a rule matches nothing and should not. Curly quotes and no-break spaces are the usual culprits.
- 05Turn on Preserve case for a rename that appears in headings and body text alike — one lower-case rule then handles every capitalisation.
Swapping two terms
Two words need to trade places. In any editor this takes three passes and a placeholder nobody will type by accident.
cat → dog dog → cat
The cat chased the dog becomes The dog chased the cat
A rename list that ate itself
Fifteen environment names renamed in one go, and several of them are each other's new names.
staging → production production → archive
One pass keeps them distinct, and the tool says when the two approaches would have differed.
A search that will not match
The text was pasted from a document. The rule is spelled correctly and the count is zero.
Total price
Total price U+00A0, a no-break space. Identical on screen.
A rename across headings and body
The same word appears capitalised, shouted and lower case, and one rule should handle all three.
colour → color
colour → color Colour → Color COLOUR → COLOR
What each option changes
| Option | Effect | When it matters |
|---|---|---|
| One pass (always on) | Every rule is considered at each position and nothing a rule emits is re-read | Swaps and rename chains. It is why this page exists |
| Longest match wins | A longer search beats a shorter one wherever both apply | New York versus New York City — order should not decide it |
| Match case | Only exact-case occurrences count as hits | Renaming a variable without touching the prose around it |
| Preserve case | The replacement takes the capitalisation of what it replaced | A word that appears in headings, body text and shouting |
| Whole words | Both edges must fall on a word boundary | cat without ruining category |
| Literal search | No pattern syntax at all | A full stop means a full stop; nothing needs escaping |
| Literal replacement | $ sequences are inserted exactly as typed | Prices, and anything containing $1 or $& |
Match case and preserve case are independent. Turning off the first and on the second is the usual combination for a rename: find it however it is capitalised, and put it back the same way.
Replacing text without breaking it
- Read the per-rule counts before the output. A zero is information, and it is invisible in every tool that does not show it.
- Suspect the characters before the spelling when a search fails. Copied text is full of no-break spaces and curly quotes that look identical to what you typed.
- Use whole words for anything short. Three-letter searches inside longer words are how a replacement quietly damages a document.
- Do not build a placeholder to work around a swap. That trick exists only because sequential replacement forces it, and a placeholder that appears in the text is its own bug.
- Keep the original until you have read the result. Replacement is not reversible once the text is gone, and a rule that matched more than you expected is easier to see than to undo.
- Reach for the regex tester the moment you need a wildcard. Literal search is a feature here, not a limitation to work around.
Where find and replace goes wrong
Rules applied in order feed each other
One rule's output becomes the next rule's input, so a swap collapses and a rename chain converges on its last value. The result is plausible, silent, and wrong.
A zero-match rule looks like success
Nothing changed, no error appeared, and the document seems fine. Almost always the search text contains a character that is not the one in the document — or a trailing space nobody can see.
Short searches damage longer words
Replacing cat without whole-word matching turns category into dogegory. It is obvious in a small document and invisible in a large one.
Case-insensitive replacement flattens capitalisation
Matching Colour and COLOUR then writing colour into all three places is what most tools do. Preserving the case of what was matched is a separate option and it is usually the one you want.
A dollar sign is a substitution in code
The same replacement text that works here will behave differently in JavaScript or Python, where $1 and \1 mean capture groups. Test the replacement where it will actually run.
Matching, ordering and options
- Algorithm
- A single left-to-right scan. At each position every enabled rule is tested and the longest matching search is applied, after which the scan resumes past the replacement — never inside it.
- Ordering
- By search length, longest first. The order rules are written in is used only to break ties between searches of equal length.
- Matching
- Literal. There is no pattern syntax, so no character needs escaping and none has a second meaning.
- Word boundaries
- A boundary is any position where a letter, digit or underscore does not sit against another one, using Unicode letter and number properties rather than ASCII ranges — so café is one word.
- Case preservation
- All-upper, all-lower and leading-capital are recognised and carried across. Anything genuinely mixed is left as written, because guessing at it produces worse output than not trying.
- Invisibles
- Seventeen characters are recognised as lookalikes — no-break and zero-width spaces, curly quotes, the dashes and the soft hyphen — and can be normalised to their ASCII equivalents in one action.
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Questions about finding and replacing text
How do I swap two words in a document?
Add both rules and apply them together. Doing it in an editor requires three passes and a placeholder, because replacing cat with dog and then dog with cat turns every animal into a cat — the second rule reads the first rule's output. Replacing in a single pass removes the problem rather than working around it.
Why does my find and replace match nothing?
Usually because the text contains a character that is not the one you typed. A no-break space, a curly apostrophe, an en dash and a zero-width space all look identical to their plain equivalents on screen. The count beside each rule shows this immediately, and Fix invisibles converts them.
Can I replace several things at once?
Yes, and that is the point of this page. Every rule runs in the same pass, so rules that would interfere with each other in sequence do not, and a rename list where one name becomes another stays correct.
What is the difference between match case and preserve case?
Match case decides what counts as a hit; preserve case decides what the replacement looks like. With the first off and the second on, one lower-case rule correctly handles colour, Colour and COLOUR — which is what a rename across headings and body text needs.
How do I avoid replacing part of a longer word?
Turn on whole words. It requires a word boundary at both ends of the match, so replacing cat leaves category and catalogue alone. Without it, short searches damage longer words in ways that are easy to miss in a large document.
Does this support regular expressions?
Deliberately not. Everything is literal, so a full stop means a full stop and nothing needs escaping. When you need a wildcard, a capture group or a backreference, the regex tester has a replace mode built for that, with a match table and group numbering.
Why did my replacement lose a dollar sign?
Not here — everything is literal. But in code it will: JavaScript treats $&, $1 and $$ as substitutions inside String.replace, so $5.00 is read as capture group five. Python does the same with backslashes. The page flags a replacement that would behave differently where it runs.
Which rule wins when two searches overlap?
The longer one, wherever both would match. New York City beats New York regardless of which is written first, because the order two rules happen to be listed in should not decide the outcome. Equal-length searches fall back to written order.
Is my text uploaded anywhere?
No. The work is JavaScript running in this tab. Every function it calls is covered by a test that stubs fetch and XMLHttpRequest to throw, so a request that slipped in would break the build rather than reach a server — and you can confirm it for yourself by disconnecting and carrying on.