Skip to content
Runs in browserNothing is uploaded

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 — free
Input
0
Replacements
0
Characters
Result

What 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. 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. 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. 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. 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

Text: Report due 2026-03-14 and review on 2026-04-02. Find: (\d{4})-(\d{2})-(\d{2}) [regex mode] Replace: $3/$2/$1
Report due 14/03/2026 and review on 02/04/2026. Replacements: 2

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

Text: The cat scattered the category of cats. Find: cat [whole words on] Replace: dog
The dog scattered the category of cats. Replacements: 1

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.