Find and Replace Text Online
Every editor has find and replace; this one is for text that is not in an editor. Paste from an email, a spreadsheet cell, a PDF, or a log, make the substitution — as plain text or as a regular expression with capture groups — and copy the result back out. The replacement count updates live, which is how you catch a pattern that matched forty times when you expected four.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Plain-text mode that treats every character literally, including $ and dots
- Regular-expression mode with capture-group references like $1 and $<name>
- Whole-word matching that understands accented and non-Latin letters
- Live count of how many replacements were made
How to use Find and Replace
- 1
Paste your text
Anything works — prose, CSV rows, log lines. The tool edits a copy in the output box, so the text you pasted stays untouched above it.
- 2
Type what to find
In plain-text mode, exactly what you type is what is found. Switch to regular-expression mode when you need patterns — digits, optional parts, alternatives — rather than fixed strings.
- 3
Type the replacement
In regex mode, $1 and $2 insert whatever the first and second parenthesised groups captured, which lets you reorder text rather than merely swap it.
- 4
Check the count before copying
The Replacements figure is the fastest sanity check there is. A count far above what you expected means the pattern is broader than you thought — inspect the output before using it.
How it works
Both modes compile down to the same thing: a regular expression executed by
the browser's own engine. In plain-text mode, your search string is first
escaped so that characters like ., $, and ( lose their special meanings — the
pattern that runs matches exactly the characters you typed. In regex mode your
pattern is passed through untouched, and the replacement string keeps its full
substitution grammar: $1 for groups, $& for the whole match, $<name> for
named groups.
The whole-word option does not use the textbook \b boundary. \b defines a word
as ASCII letters, digits, and underscore, which makes it wrong for most of the
world's text — it would happily match "cafe" inside "café" because é looks
like a boundary to it. Instead the tool wraps the search in Unicode-aware
lookarounds, so a word is bounded by anything that is not a letter, digit, or
underscore in any script.
Counting is a separate pass from replacing. The engine reports every match first, then performs the substitution natively — so the count you see and the substitution semantics you get are both exactly the platform's, with no approximation layered in between.
Choosing between the two modes
Plain text is the right default. It cannot surprise you: what you type is what changes, and nothing else. Reach for regular expressions when the thing you want to change is a shape rather than a string — every date, every price, every trailing "(draft)" whatever precedes it. The moment you find yourself running plain replacements repeatedly with tiny variations, that repetition is usually one regex.
When you'd use this
Fixing a name misspelled forty times in a document that only exists as an email. Reordering date formats before a spreadsheet import, as in the first example. Stripping a prefix from every line of a log excerpt. Renaming a variable in a code snippet where "whole words only" keeps count from becoming counter. Doing any of these on a machine where you cannot install anything.
Read the count before you take the output
The match count is the check that makes a bulk replacement safe, and it costs nothing to look at.
A replacement is one action affecting an unknown number of places, and the failure is silent in both directions. Too many matches and you have changed something you did not mean to; too few and the job is half done and looks finished. Neither announces itself, because you are reading the output for the places you expected to change.
So form an expectation first. If you believe a name appears about forty times and the count says 41, that is worth ten seconds — perhaps it appears in a URL or an email address you did not think of. If it says 200, stop: the search is matching inside longer words, and whole-word mode is probably what you wanted. If it says 3, the text may use a different spelling or a non-breaking space where you typed a plain one.
The count is also how you test a regex safely. Write the pattern, look at the number, and only then run it. A pattern that matches everything usually reports a count that is obviously wrong before it has done any damage.
Order matters when you run several replacements
Chained replacements are not independent, and the second one sees the output of the first.
Swap A for B and then B for C, and everything that was originally A
is now C too — the second pass cannot tell your new Bs from the ones that
were already there. This is the standard way a two-step rename produces a result
nobody wanted, and it is easy to miss because each step is individually correct.
The usual fix is to make the intermediate value one that cannot occur in the
text. Replace A with a marker no document would contain, do the other
substitutions, then replace the marker last. Ugly, and reliable.
Where possible, do it in one pass instead. A regex alternation with a single replacement handles cases the chain gets wrong, because each position in the text is considered once and only once.
And with plain-text replacements, the more specific one goes first. Replacing a short string before a longer one that contains it means the longer one no longer exists by the time its turn comes.
Examples
Reordering dates with capture groups
Each parenthesised group captures one part of the date, and the replacement reassembles them in day/month/year order. This is the trick plain find and replace cannot do at all — the text being inserted is built from the text that was found.
Whole words leave lookalikes alone
Without the whole-word option this replacement would also hit "scattered", "category", and "cats", producing sdogtered and dogegory. Substring accidents like these are the most common way a quick replace quietly ruins a document, and the count dropping from 4 to 1 shows the guard working.
Frequently asked questions
What do $1 and $2 in the replacement mean?
They refer to capture groups — the parts of the pattern wrapped in parentheses. If the pattern is (\d{4})-(\d{2}), then $1 is whatever the four digits matched and $2 the two. $& inserts the entire match, and named groups written as (?<year>\d{4}) can be inserted with $<year>. These references only have meaning in regular-expression mode.
Why did "$1" get inserted literally instead of a capture group?
You are in plain-text mode, where every character — including the dollar sign — means itself. That is deliberate: someone replacing prices in a document must be able to insert "$5" without triggering group references. Switch the mode selector to regular expression and $1 will resolve to the first captured group instead.
Why is whole-word matching grayed out in regex mode?
Because in a regular expression you state the boundaries yourself, and a hidden wrapper would silently change what your pattern means. Add \b on either side for ASCII words, or the stricter lookarounds (?<![\p{L}\p{N}_]) and (?![\p{L}\p{N}_]) if your text contains accented or non-Latin letters, which \b does not treat as word characters.
Can a replacement span multiple lines?
Yes, in regex mode. A dot never matches a newline, but a pattern like [\s\S]*? does, and \n matches a line break directly — so "end\n\nbegin" style joins are expressible. Be careful with greedy multi-line patterns: .* variants that cross lines can swallow far more than intended, which the replacement count will reveal immediately.
Is my text sent to a server to run the replacement?
No — the matching engine is the one built into your browser's JavaScript runtime, running in this tab. That is also why it is fast: there is no round trip, so the result recomputes on every keystroke. Watch your browser's Network tab while you type and you will see the text you are editing appear in no request at all.
Further reading
- Windows Line Endings Cost 1.8% on Disk and Three Bytes CompressedEvery line of a Windows text file ends with two characters where a Unix one ends with one. It is the oldest formatting difference in computing and it is worth a measurement, because the size argument turns out to be the least important thing about it.
- We Sent a CSV Through a Spreadsheet and Watched What DiedOpen a CSV in a spreadsheet, change nothing, save it again, and the file that comes out is not the file that went in. This is well known for postcodes and product codes with leading zeros. We ran a deliberately awkward CSV through the round trip to find out exactly which fields survive and which do not.
- The Three Invisible Bytes at the Start of Your CSVYour CSV has a column called `id`. Your code looks for a column called `id`. It is not there. Print the header and it says `id`. The problem is three bytes at the very start of the file that no editor displays, that Excel on Windows once needed, and that half the software in the world now has to work around.