Live demo (works without JavaScript):
Sample (case-insensitive): Sample input — paste anything and watch the result update.
Sample input — paste anything and watch the result update.Sample input — paste anything and watch the result update.Written by Jane Smith · Reviewed by Alex Chen · July 22, 2026
Find specific text and replace it with something else. Supports case-insensitive and regex modes.
The tool walks the input looking for one search term and replaces every occurrence with the replacement text. It runs in three configurations: literal case-sensitive, literal case-insensitive, and full regular expression. The output lands in a second box, so the original stays visible for comparison. Replacement happens entirely in the page, and the source text is never uploaded.
With Case sensitive checked and regex mode off, the page splits the input at each exact occurrence of the search string and rejoins the pieces with the replacement between them, so "cat" touches nothing but the letters c, a, t in that order. Unchecking Case sensitive switches to a scan that compares the text and the search term after lowercasing both, which lets "CAT", "Cat", and "cat" match the same pattern while preserving the original casing everywhere else. Turning on Use regular expression builds a JavaScript RegExp from the search term and applies it globally, which unlocks character classes, quantifiers, and capture groups.
The case rule is easy to prove. With the input "The Cat sat on the mat." and a search for "cat" in case-sensitive mode, nothing changes, because the only candidate starts with a capital C. Switch the mode off and the same search produces "The dog sat on the mat." in one pass.
Suppose a spreadsheet exports dates as month/day/year and a database expects year-month-day. Enable regex mode and search for:
(\d{2})/(\d{2})/(\d{4})
with a replacement of:
$3-$1-$2
On the value "12/25/2026" the pattern captures "12" as group one, "25" as group two, and "2026" as group three, and the replacement reorders them to "2026-12-25". The dollar-number syntax pulls captured groups back into the output, so a single pass converts every row in the column.
A list of "first@domain" addresses can be flipped to "domain@first" with the pattern:
(\w+)@(\w+)
and the replacement:
$2@$1
Running that against "lisa@example.com, john@test.org" yields "example@lisa.com, test@john.org". The pattern grabs the username and the domain label before the dot, and the replacement swaps them, leaving the top-level domains untouched. This is the same mechanism the date example uses, which is what makes capture groups the most useful feature regex mode offers.
A malformed pattern, such as an unclosed parenthesis, throws an error that the page reports in a toast instead of guessing. The replacement field follows JavaScript's replace rules, so a literal dollar sign in the output has to be escaped. Regex matching is line-agnostic by default, meaning a pattern like ^Start anchors to the very beginning of the whole text rather than the start of every line. Nothing persists between runs: each click starts from the input box as it currently reads.
Quantifiers like the plus and the star reach as far as they can by default. On the input "<b>bold</b> and <i>italic</i>", the pattern "<.+>" does not stop at the first closing bracket; it swallows everything from the first < to the last >, returning one match that spans the whole string. Adding a question mark, "<.+?>", flips the quantifier to lazy mode, and the same input yields four small matches, one per tag. When a pattern seems to erase too much, the lazy variant or a narrower character class is usually the fix.
Metacharacters need a backslash to be taken literally. Searching for "v5\.0" and replacing with "v6.0" turns "v5.0 is out" into "v6.0 is out", because the escaped period matches the literal dot instead of any character. Lookahead checks what follows without consuming it: the pattern "red(?= car)" on "red car and red bus" matches only the first "red", since only that one is followed by a space and the word "car".
The dot refuses to cross a newline, because the tool builds its expression with no dot-all flag. A pattern meant to span lines needs an explicit whitespace class such as "red\s+green" or the bracket trick "red[\s\S]+green" instead of "red.green".
The page copies the input through unchanged and reports no replacements, so an empty search never wipes the text.
Regex mode handles it: wrap the term in word boundaries, such as \bcat\b, so the pattern skips "catalog" and "scatter".
Dollar sequences are only interpreted as capture groups when regex mode is on. In literal mode, split-and-rejoin treats "$1" as plain text and inserts it verbatim.
No. The source box is read-only during replacement, and the result goes to the output box, so a mistake never destroys the starting text.
Not a dedicated one. Because the input stays untouched, undoing is as simple as copying the source box back and starting over.
Replacement runs synchronously in one pass, so a few hundred thousand characters finish quickly, though the page can freeze briefly on inputs in the megabyte range.
A greedy quantifier probably stretched the match to its final possible point. Adding a question mark to make it lazy, or tightening the character class, usually confines the result to what was intended.
Replace-all shines for mechanical cleanup: standardizing spellings, stripping repeated tokens, reordering fixed formats. It is the wrong tool when every match needs a human decision, when the pattern is easier to express by hand than in a regular expression, or when the document lives in a collaborative editor where tracked changes matter. For one-off edits, most text editors do the same job; the tool earns its place when the text is already in the browser and the transformation is scriptable.