I run toolz.dev and spend most of my week in WordPress plugin code, Laravel APIs, and React front ends. Find and replace is the single edit I perform more than any other, and yet nine times out of ten I do not want the powerful version of it. I do not want a regular expression. I want to take a piece of text, say every occurrence of a client's old product name, and swap it for the new one, exactly, without a stray character in my search term matching something I never meant to touch. That is what the Find and Replace tool does, and this guide is about why the literal, boring version of find and replace is the one you want most of the time.
TL;DR: This tool does literal find and replace over a block of pasted text. The search term matches exactly as typed, so a full stop matches a full stop and a dollar sign matches a dollar sign, with no escaping and no accidental over-matching. You can add several find-and-replace rules and apply them in one pass, restrict matches to whole words, and turn case sensitivity on or off. It reports how many replacements each rule made. Everything runs in your browser, so nothing you paste is uploaded. When you genuinely need wildcards and capture groups, a regex replacer is the right tool instead.
What is literal find and replace, and why does "literal" matter?
Find and replace is the operation of locating every occurrence of one string and swapping it for another. Every editor has it. What varies is how the tool interprets your search term, and that single design choice decides whether the tool helps you or quietly ruins your text.
There are two schools. A regular-expression replacer treats your search term as a pattern, where certain characters are commands: a dot means "any character," an asterisk means "repeat," a dollar sign means "end of line," and brackets, parentheses, and backslashes all carry special meaning. A literal replacer treats your search term as itself, character for character, with no special meaning attached to anything.
Most of the time, literal is what you want, and here is the concrete reason. Suppose you want to replace the version string 1.0.0 with 2.0.0 in a block of text. In a regex tool, those dots are wildcards, so your search also matches 1x0y0, 1a0b0, and other strings you never intended. You would have to escape the dots as 1\.0\.0 to make it safe, and if you forget, the tool does something subtly wrong and does not warn you. In a literal tool, 1.0.0 means 1.0.0, the dots are dots, and there is nothing to escape and nothing to get wrong. The same is true for a price like $9.99, a file path with backslashes, or a snippet of code with brackets in it. The literal tool handles all of them without you thinking about pattern syntax, because there is no pattern syntax.
When should I use a regex replacer instead?
Literal is the right default, but it is not the right answer to everything, and I would rather tell you where it stops than pretend it does not. Reach for a regex replace tool when the thing you are matching is a shape rather than a fixed string. If you need to match every four-digit year, or every email address, or every line that starts with a hash, or you want to reformat matched text by pulling pieces out of it with capture groups, that is pattern work and a literal tool cannot do it. The regex tester is the place to build and debug that pattern before you run it.
The dividing line is simple. If you can type out exactly what you are looking for, use literal find and replace and save yourself the escaping. If what you are looking for is a category of things that share a shape but not exact characters, use a regex. Most everyday text cleanup is the first kind, which is why the literal tool covers the majority of real jobs and the regex tool covers the rest.
| Situation | Use | Why |
|---|---|---|
| Rename a fixed word or phrase | Literal find and replace | The term is exact; no pattern needed |
A search term containing dots, slashes, or $ |
Literal find and replace | No escaping, no accidental wildcard matches |
| Fix several different terms in one go | Literal find and replace, multiple rules | Each rule is exact and applied in order |
| Match any year, email, or code shape | Regex replace | Only a pattern can describe a category |
| Reorder or reformat matched text | Regex replace | Capture groups pull out and rearrange pieces |
| Match at line starts or word boundaries by rule | Regex replace | Anchors and boundaries are pattern features |
How do multiple rules work?
The feature I lean on most is applying several rules at once. Real cleanup is rarely one swap. When I take over a client's copy, I might need to change a brand name, fix two consistent misspellings, and remove a piece of boilerplate, all in the same block of text. Doing that as four separate passes is tedious and error-prone. The tool lets you add a row for each find-and-replace pair, and it applies them in order, each rule acting on the output of the one before it.
That ordering is worth understanding, because it is a feature, not an accident. Say rule one replaces foo with bar, and rule two replaces bar with baz. Because rule two runs on the result of rule one, text that started as foo ends up as baz. Most of the time your rules are independent and the order does not matter, but when they do interact, the behaviour is predictable: top to bottom, each on the previous result. The tool also shows you a count for each rule, so you can confirm that rule three matched something and is not sitting there doing nothing because of a typo in the search term.
What do whole-word and case options do?
Two options handle the cases where a plain swap is too blunt.
Case sensitivity decides whether Cat, CAT, and cat are the same word or three different ones. It is off by default, because most cleanup wants to catch a term regardless of how it was capitalised. Turn it on when the capitalisation is the whole point: when you want to change one spelling of a name without touching another, or when you are working with code where value and Value are different identifiers.
Whole-word matching decides whether your search term has to stand on its own rather than sit inside a longer word. This is the option that saves you from the classic find-and-replace disaster. If you replace cat with dog without whole-word matching, you also turn category into dogegory and scatter into sdogter. With whole-word matching on, only the standalone word cat is replaced and the longer words are left alone. The tool detects word boundaries using Unicode letters and numbers rather than the ASCII-only definition, so an accented word like café is treated as a single word and its boundaries are found correctly, which a naive implementation using the classic \b boundary would get wrong.
There is a broader point here about how text tools have to respect Unicode, which I get into in the text tools guide: treating text as bytes rather than as user-perceived characters is where a surprising number of tool bugs come from.
How I use it in real work
A few patterns come up again and again. When I paste text out of a PDF or an email, it often arrives with a term written inconsistently, and one literal rule fixes every instance. When I migrate a client's content, I set up a stack of rules for the brand name, the old domain, and a couple of recurring phrases, and run them all at once. When I clean up data before importing it, I use rules to strip out a repeated prefix or a stray marker character, replacing it with nothing, which is just a rule with an empty replacement.
It pairs naturally with the other text tools. I often flatten pasted text with remove line breaks first, then run find and replace on the result. When the job is really about changing the shape of words rather than swapping them, the case converter is the better fit, and when I am de-duplicating a list I reach for the duplicate line remover instead. Knowing which tool is for which job is half the speed, and there is a wider rundown of that in the developer productivity tools guide.
The last thing, and the reason I built these to run in the browser, is privacy. The text you paste into a find-and-replace tool is often a draft, a client's unpublished copy, a transcript, or data you have no business uploading to a random server. Everything this tool does happens in JavaScript on your own machine. Nothing is transmitted, logged, or stored, and you can confirm it by disconnecting from the network and watching the tool keep working.
A worked example: renaming a product across a page
Let me make the multiple-rules idea concrete, because it is the part people underuse. Say a client rebranded from "QuickBooks Lite" to "Ledgerly," moved from oldsite.com to ledgerly.app, and their old copy kept spelling "e-mail" with a hyphen while the new style guide wants "email." That is three independent changes, and I would set them up as three rules in one pass rather than three trips through the tool.
Rule one finds QuickBooks Lite and replaces it with Ledgerly. Rule two finds oldsite.com and replaces it with ledgerly.app; notice that the dots in both domains are literal here, so I do not have to escape anything, whereas a regex tool would treat oldsite.com as matching oldsiteXcom as well. Rule three finds e-mail and replaces it with email. I paste the page, run all three, and the count next to each rule tells me the brand name changed nine times, the domain changed four times, and the hyphen fix hit twice. If rule three showed zero, I would know the copy did not contain the hyphenated spelling and I could drop the rule.
The counts are the quiet hero of this workflow. Without them you are trusting that each rule did its job; with them you get immediate feedback that a search term was right or wrong. A zero where you expected matches is almost always a typo in the find field or a capitalisation mismatch you can fix by toggling case sensitivity.
How does the matching work?
It is worth knowing a little about what happens under the hood, because it explains some behaviour you might otherwise find surprising. The tool scans the text from left to right. At each position it checks whether your search term matches starting there. If it does, and any whole-word condition is satisfied, it writes the replacement and jumps past the matched text. If it does not, it copies one character across and moves on by one. This is why replacement is not recursive within a single rule: when it writes the replacement, it continues scanning after it, not inside it, so replacing aa with a in the string aaa gives you aa rather than collapsing all the way down to a. If you want the collapse, you run the rule twice, which is exactly what a second rule with the same find and replace does.
Case-insensitive matching is done character by character rather than by lower-casing the whole string first. That sounds like an implementation detail, but it matters for correctness: some characters change length when they are lower-cased, and comparing whole lower-cased strings would knock the positions out of alignment and corrupt the output. Comparing one character at a time keeps every index honest. Whole-word boundaries are checked against the characters immediately before and after a match, treating any Unicode letter or number as part of a word, which is what lets accented and non-Latin scripts behave the way you would expect.
None of this is something you have to think about in daily use. But it is the difference between a tool that quietly does the wrong thing on an edge case and one you can trust with a client's copy, and it is the reason I would rather use a purpose-built literal replacer than paste text into a regex box and hope my search term did not contain a special character.
Frequently asked questions
How do I find and replace text without using regex?
Paste your text into the tool, type the exact phrase to find and the exact phrase to replace it with, and run it. The search is literal, so every character you type is matched as itself and nothing needs escaping. Every occurrence is swapped and you get a count of how many changes were made, all in your browser without anything being uploaded.
Can I replace several different words at the same time?
Yes. Add a row for each find-and-replace pair and the tool applies them in sequence, each one acting on the result of the rule before it. This is how you rename a brand, fix two misspellings, and strip a piece of boilerplate in a single pass, and each rule shows its own replacement count so you can see that it matched.
What is the difference between this and a regex replace tool?
This tool matches your search term literally, so a dot matches only a dot and a dollar sign only a dollar sign, with no pattern syntax to learn and no accidental over-matching. A regex replace tool treats the search term as a pattern with wildcards, anchors, and capture groups, which is what you need to match a category of things such as any year or any email address. Use literal when you can type the exact thing you want; use regex when you are matching a shape.
How does whole-word matching stop unwanted replacements?
With whole-word matching on, the search term is only replaced when it stands on its own rather than inside a longer word. Replacing cat then changes cat but leaves category, scatter, and located untouched. The tool uses Unicode-aware boundaries, so accented and non-English words are handled correctly rather than being split at the wrong place.
Will find and replace change my line breaks or spacing?
No. Only the characters you searched for are changed. Line breaks, indentation, spacing, and punctuation around your matches are left exactly as they were. If the replacement is longer or shorter than the original, the surrounding text shifts naturally, but nothing else is reformatted or reflowed.
Is there a limit to how much text I can process?
There is no fixed limit beyond your browser's memory. Because the work happens on your device rather than a server, blocks of hundreds of thousands of characters process almost instantly and there is no upload size cap. For something the size of a whole book you may notice a brief pause, but ordinary documents are effectively instant.
Is my text uploaded or stored anywhere?
No. The text is processed by JavaScript in your browser and is never transmitted, logged, or stored. You can verify this by opening the network tab while you run a replacement, or by disconnecting from the internet, since the tool keeps working offline once the page has loaded. That is the reason to use a client-side tool for drafts, client copy, and anything private.
