Keep or remove matching lines

Describe the selection before touching the text

Write down what qualifies as a match. “Lines starting with WARN” is a different rule from “lines mentioning WARN anywhere.” With a log or list, those rules can produce different results even though they use the same search text. Pick the mode that mirrors the reason you want to keep or remove each row. If you can name a line that should not match, include it in your initial test.

Paste a small representative block first. Include an expected match, a near match and a row that definitely belongs outside the result. This gives you a faster check than scrolling through hundreds of lines after an incorrect rule has already been applied. Keep the original separately if filtering is part of an audit, a support investigation or a cleanup you may need to explain.

The filter keeps or removes entire physical lines. It does not edit a matched word in place, split a table into columns or interpret a regular expression. Use Find and replace for a literal correction inside a line. Use a table-aware workflow if a record can extend across multiple physical lines or if matching depends on a particular column rather than the full text.

Compare Starts with and Contains on a realistic sample

Paste these lines. Enter WARN under Text to match and choose Starts with, then Keep matching lines. The first and third lines should be kept. The second contains the same letters farther in, and the last is lowercase.

WARN Retry queued
    INFO Previous status was WARN
    WARN Owner missing
    warn Test note

Switch to Contains. The second line now matches too, which may be useful if you are looking for any mention of the label, but is wrong if you only want actual warning rows. If you clear Match case, the last line also matches. Use that option when the source legitimately uses capitalization variants and the letters' case does not carry meaning. Leave it on when uppercase and lowercase distinguish different values or roles.

A prefix match can still be broader than intended. Searching for WARN at the start can also catch WARNING or WARNINGS. If the source uses a consistent delimiter after the label, include that delimiter in the search text. For example, search for WARN followed by a space if that marks a complete severity token. Try the rule on a negative example before processing the full input.

Match a suffix or an entire value when precision matters

Use Ends with when the distinguishing part is at the end. A list of filenames can be filtered for the literal suffix .txt, with case matching chosen according to the naming convention. A filename that ends with .txt followed by an extra space may not match. If whitespace is accidental, use a separate copy and inspect the possible side effects of trimming before filtering again.

Use Whole line to keep or remove an exact value rather than a similar one. For example, filter the exact identifier SKU-17 without selecting SKU-170 or a sentence that mentions SKU-17. Whole line does not automatically strip a bullet, prefix, indentation or trailing spaces. If the data has a leading marker, decide whether to include it in the match or to clean a deliberately chosen list first.

Search punctuation literally. A period does not stand for any character, and an asterisk does not mean “anything after this.” If you need more than one condition, run simple passes on a working copy and label the output of each. For example, first keep lines that start with a project prefix, then keep lines that end in a known suffix. Use the original each time if the two results are separate categories rather than an intersection.

Check whether you want to keep the matches or their complement

Keep matching lines is useful when you want a focused extract for review. Remove matching lines is useful when you know that a particular class of row should be excluded. The search rule can be the same in both operations, but the output has opposite meaning. Verify the selected action before copying a result with a plausible-looking number of lines.

Try the keep action first if you are about to discard rows. Look at what your rule would remove before switching the action. For example, a search intended to remove a repeated page header may also select a legitimate line that begins with the same words. Narrowing the match to a complete line or a more specific prefix can preserve that data without changing the rest of the workflow.

An empty search intentionally leaves the input unchanged. That is useful when you are setting up the tool, but it should not be interpreted as proof that the input contains no matches. Verify that a real search value appears in the field, and check the status counts. If the output will be used for a bulk operation elsewhere, treat it as a proposal for review rather than as authority to make those changes.

Check spaces, blank rows and multiline records

The tool operates on the lines you pasted, not the way the textarea wraps them visually. A long log message that wraps on a narrow screen can still be one line. Conversely, copied text from a PDF can include hard breaks inside sentences. If the goal is to find lines with real semantic boundaries, verify that the pasted data uses those boundaries before applying a filter.

Spaces and invisible characters are part of the line unless you deliberately change them first. A line with a leading tab will not start with the same literal letters as a line with no indentation. If two lines look similar but only one matches, paste them into the character inspector to find a hidden difference. Leave intended indentation intact and adjust the rule where that indentation is meaningful.

Do not filter arbitrary physical lines of a CSV file containing quoted multiline cells. Removing a piece of a cell can break the quoting and shift later records. Instead use the CSV and TSV converter for a sample or open the structured file in an importer that can filter complete records. Choose the column and evaluate values there, rather than treating a quoted multiline table as a plain list.

Verify results and keep enough evidence to repeat the filter

Check the match and kept counts, then inspect the first and last selected rows. Compare a line you expected to keep and one you expected to discard against the original. In a long log, the earliest and latest matching times can help establish that you copied the intended range. If the outcome is unexpected, change just one setting and rerun the small sample.

If the output still contains repeated rows, decide whether those repeats describe separate events or redundant items. Only use Remove duplicate lines if one occurrence is enough. If order is meaningful, preserve it. For a list of addresses extracted from a note, use Extract links and emails first, then filter the extracted one-item-per-line result for the domain or suffix you actually need.

For a handoff, write down the matching mode, the search text, whether case mattered and whether you kept or removed matches. Make the direction explicit, such as “Kept lines starting with WARN and a space.” Save the filtered result separately from the unedited source. The guide to preparing lists and tables can help decide whether to apply a line filter, compare sets of values or work with structured records instead.

Check a filter that depends on a literal boundary

A list can use a delimiter as part of each line: for example, project labels written as BUILD: or BUILDING:. If your target is the first category, include the colon in a Starts with rule. Searching for only BUILD will also keep the second category. Conversely, Whole line with BUILD: would not select an entry that has a description after the label. The choice is about where the boundary lies, not how familiar the search term looks.

If a literal separator is a tab and cannot be entered conveniently, inspect the source and decide whether to use a distinctive text prefix or a table-aware filter. Do not convert every tab to a space unless you have confirmed that none of them separate actual columns.