ಹುಡುಕಿ & ಬದಲಾಯಿಸಿ

Find and replace text online — with regex or plain text

This find and replace tool swaps text across a whole document in one click. Paste your content, enter what to find and what to replace it with, and every match changes at once — with a live count and highlighting so you can see exactly what will be affected before you commit.

Use it as a simple plain-text replacer, or switch on regex for pattern-based edits. It runs online and entirely in your browser, so there's nothing to install and your text never leaves your device — ideal for cleaning up exported data, code, CSV files, logs or any repetitive edit. Works equally well on iPhone, Android, and desktop.

Regex find and replace with capture groups

Turn on Regex to treat the Find box as a full JavaScript regular expression, with the i, m and s flags one chip-tap away (g is always on so every match is replaced). Patterns like \\d{4} or \\b[A-Z]\\w+ let you match by shape, not just exact words.

Where this regex find and replace online tool stands out is capture groups: wrap part of the pattern in parentheses and reuse it in the replacement with $1, $2 or $&. Find (\\d{4})-(\\d{2})-(\\d{2}) and replace with $3/$2/$1 to reformat ISO dates, or capture (\\w+)@(\\w+) to rewrite email addresses. Invalid patterns show a clear inline error instead of failing silently.

Multiple find and replace at once

Most online replacers only handle one pair at a time. Switch to Multiple rules mode to queue a list of find→replace pairs that apply in order, top to bottom — true multiple find and replace online. The result of each rule feeds into the next, so you can chain a whole clean-up in a single click.

Each rule has its own Regex, Match-case and Whole-word toggles, and an enable checkbox so you can switch a step off without deleting it. It's useful for standardising terminology, fixing several recurring typos, or running a repeatable batch find and replace over pasted text. This beats doing it one substitution at a time in Word or Google Docs.

Precise matching: case, whole word, line breaks and tabs

In plain-text mode, Match case distinguishes 'Apple' from 'apple', and Whole word matches a term only when it stands alone — so replacing 'cat' won't touch 'category' or 'scatter'. Turn on Interpret \\n \\t to use \\n for a line break, \\t for a tab and \\\\ for a backslash in either box.

That makes awkward jobs easy: find , and replace with \\n to split a comma list onto separate lines, or find \\t and replace with a space to flatten tab-indented text. Leave the Replace box empty to simply remove a word or character everywhere it appears.

How this compares to Word, Google Docs, Notepad++, and VS Code

Microsoft Word has Find & Replace with wildcard support, but the syntax differs from standard regex (you write <cat> for whole word in Word wildcards, not \\bcat\\b), and it only works on documents inside Word. Google Docs added basic regex in 2019 but still doesn't support capture groups in replacements — you can't do a date reformat with $1/$2/$3 in Docs. Notepad++ has excellent regex support but requires a Windows install and only works with files on disk.

VS Code is the most capable of the lot — full regex with capture groups and multi-file find-replace — but it's overkill if you just need to clean up some pasted text without opening a project folder. This tool fills that gap: paste any text, run regex with capture groups, queue multiple rules, and copy the result in seconds, on any device, with nothing to install and nothing uploaded.

Private, instant and free

Every replacement — from a one-word fix to a full document — happens locally in your browser, so even sensitive text such as source code, contracts or logs stays on your device. There's no sign-up, no upload and no cost. The tool works offline after first load, so you can use it on a plane or a flaky connection.

Bookmark this find and replace tool for the next time you need to reshape text fast. Whether you're cleaning exported CSV data, reformatting a block of code, standardising terminology across a document, or stripping unwanted characters from a log file — it handles all of it in your browser, for free.

Regex deep dive: anchors, character classes, quantifiers and backreferences

Anchors pin a pattern to a position rather than a character. ^ matches the start of a line and $ matches the end, so the pattern ^\s+ targets only leading whitespace and \s+$ targets only trailing whitespace — use the latter with an empty replacement to trim every line without touching internal spacing. Character classes match any one character from a set: [a-z] is any lowercase letter, [0-9] is any digit, and the shorthand \w (word character: letters, digits, underscore), \d (digit) and \s (whitespace) cover the most common cases. Negate a class with ^ inside the brackets — [^\d] matches any non-digit.

Quantifiers control how many times the preceding element must match. * means zero or more, + means one or more, ? means zero or one, and {n,m} means between n and m times — so \d{2,4} matches two-, three- or four-digit numbers. By default quantifiers are greedy: .+ will consume as much text as possible before backtracking. Add ? to make them lazy: .+? matches as little as possible. This distinction matters when stripping HTML tags — <.+> greedily swallows everything from the first < to the last > on a line, while <.+?> (or the more precise <[^>]+>) matches each individual tag. Use <[^>]+> replaced with nothing to strip all HTML tags from a block of markup.

Capture groups wrap a sub-pattern in parentheses and save what they match so it can be reused in the replacement string. Find (\w+)\s+\1 to detect repeated adjacent words like "the the" (the \1 backreference matches the same text the first group captured). To swap two words, find (foo)(bar) and replace with $2$1 — the dollar-sign syntax in the replacement is $1, $2, etc. Real-world patterns: find ^(\+?\d[\d\s\-().]{7,})$ to match phone numbers in various formats and replace with a normalised form; find https?://[^\s"'>]+ to extract all URLs; find \s+$ to catch trailing whitespace on every line. These patterns handle tasks that would otherwise require a custom script.

Case-sensitive, case-insensitive, and case-preserving replacement

Most word processors default to case-insensitive search because users typically want to find a word regardless of how it was capitalised. Code editors, by contrast, default to case-sensitive matching, because useState and usestate are genuinely different identifiers. Understanding which mode your tool is in prevents the classic bug of inadvertently renaming a constant while only intending to update comments. The i flag in a regex engine enables case-insensitive matching — the pattern /colour/i matches "colour", "Colour", "COLOUR" and every mixed-case variant.

Smart case (popularised by Vim and adopted by VS Code) offers a middle ground: the search is case-insensitive when the query string is entirely lowercase, and becomes case-sensitive the moment it contains any uppercase letter. Typing colour finds all variants; typing Colour finds only the capitalised form. This lets fast typists work in lowercase by default without ever flipping a toggle. VS Code's Find in Files inherits this behaviour when "Match Case" is off but a capital appears in the search term.

Case-preserving replacement goes further: a single replace command changes "colour" → "color", "Colour" → "Color", and "COLOUR" → "COLOR" simultaneously, preserving the capitalisation pattern of each individual match. VS Code implements this using special escape sequences in the replacement string — \u uppercases the next character, \l lowercases it, \U uppercases the entire following group, and \L lowercases it. So replacing colour (match case off) with \u\Lcolor correctly preserves title-case matches. For most everyday jobs the simpler approach is to run two or three separate replacements (one for all-caps, one for title-case, one for lowercase), which is exactly what the Multiple rules mode in this tool enables.

Project-wide find and replace across files

Single-file replacement is only half the story — renaming a variable across an entire codebase or updating a brand name across thousands of documents requires project-wide search and replace. The Unix toolchain covers this: grep -rn "old_text" . finds every occurrence recursively and shows line numbers, while the replacement itself is handled by sed: sed -i 's/old/new/g' $(grep -rl "old" .) rewrites every matching file in place. ripgrep (rg) is the modern, faster alternative — rg "old" --files-with-matches | xargs sed -i 's/old/new/g' combines its high-speed search with sed's substitution. For Windows users without a shell, VS Code's Find in Files (Ctrl+Shift+H) offers the same capability through a GUI, including full regex with capture groups and a preview of all changes before they are written.

Version control is non-negotiable before any mass replacement. Stage all current changes first so the entire diff from the find/replace is isolated in one reviewable commit. git diff after the operation shows exactly which lines changed across which files — without that safety net, a poorly scoped pattern can silently corrupt dozens of files. The classic disaster is replacing a short, common substring like id or type without word boundaries: the pattern matches inside longer identifiers, breaking variable names and function calls in files you never intended to touch. Always test the pattern against a single file or a small sample before running it across the whole project.

The dry-run principle is therefore standard practice: run the search pass first (grep or ripgrep) and review every matching line before writing a single byte. Some tools make this explicit — sed's --dry-run is not universal, but most IDEs show a full preview diff. For structured formats such as JSON, XML and HTML, raw text find/replace is almost always the wrong tool: a pattern that targets a value can accidentally match a key with the same text, or hit an attribute name inside a tag. The correct approach is to parse first, target with a path expression, then serialize — jq '.users[].name = "updated"' for JSON, xmlstarlet ed for XML, and SQL's UPDATE … SET … WHERE for database records. Reserve text-level find/replace for unstructured or semi-structured content where a parser would be overkill.

A brief history of text search

The grep command — short for Global Regular Expression Print — was written by Ken Thompson in 1973 for Unix. Thompson extracted the g/re/p command from the ed line editor (which itself expressed a global substitution as g/regex/s/old/new/) and packaged it as a standalone tool. Alfred Aho extended it in 1975 with egrep (which added alternation | and grouping ()) and fgrep (which searched for fixed strings without regex overhead), establishing the three-way split between full-regex, extended-regex and literal-string search that many tools still mirror today.

Two landmark algorithms arrived in 1977 that underpin nearly every search tool in use today. The Boyer-Moore algorithm (Robert Boyer and J Strother Moore) pre-processes the search pattern to build two heuristic tables — the bad-character table and the good-suffix table — that allow the search to skip over large sections of the input text instead of examining every character. For long patterns searched in long text, this achieves sub-linear time in practice, meaning the algorithm scans fewer characters than are in the document. The Knuth-Morris-Pratt algorithm (Donald Knuth, Vaughan Pratt and James Morris, also 1977) approaches the problem differently: it pre-computes a failure function from the pattern itself so that when a mismatch occurs it can resume from the longest prefix of the pattern that is also a suffix of the text scanned so far, guaranteeing linear time O(n + m) with no backtracking.

Modern editors combine these ideas with additional tricks to handle millions of lines without perceptible lag. Ripgrep, the fastest widely used search tool, applies SIMD (single-instruction, multiple-data) CPU instructions to scan 16 or 32 bytes simultaneously, uses a literal optimiser to extract fixed byte sequences from a regex and run a Boyer-Moore-Horspool pass before the full regex engine fires, and respects .gitignore rules to skip irrelevant files. VS Code's search builds a trigram index over the workspace so that searches for rare three-character sequences resolve with a single index lookup rather than a full file scan. The result — near-instantaneous search across a repository of millions of lines — is the product of almost fifty years of incremental algorithmic refinement tracing back directly to Thompson's 1973 grep.