Online Tool Store
· 3 min read
How to Delete Every Line Containing a Word
Manesh Jayawardhana
CIO & Co-founder
Eighteen hundred lines of application log, and the fourteen you care about are buried under DEBUG output. Or an exported list where every third line is a header repeated by whatever generated it. Either way you want to throw away lines by what’s in them, not by where they are.
On a machine with a terminal this is grep -v. On a locked-down laptop, a phone, or in the middle of writing an email, it isn’t.
What line filtering actually does
Two operations, and they’re mirror images.
Remove matching lines keeps everything that doesn’t contain your term. This is the log-cleanup case — drop the noise, keep the rest.
Keep only matching lines discards everything else. This is the extraction case — pull out every line mentioning one order number, or every ERROR.
The subtlety is in what counts as a match. Substring matching finds your term inside longer words: filtering on “error” also removes lines containing “errors”, “terror” and “error_count”. Sometimes that’s what you want. Often it removes considerably more than you intended, and you don’t notice because the removed lines are gone.
Why people get stuck here
- No terminal available. The tool that does this natively isn’t always reachable.
- Over-matching. Substring matches catch words you didn’t mean, silently.
- Case. Log levels are usually uppercase and prose usually isn’t, so case sensitivity matters more than people expect.
- Sensitive content. Logs contain internal hostnames, user identifiers and occasionally credentials, which rules out pasting them into an unknown service.
What good filtering looks like
Counts before and after
You should see how many lines went in, how many came out, and therefore how many matched. A filter that removes 900 lines when you expected 40 has told you something important — but only if it reports the number.
Whole-word matching available
Matching on word boundaries stops “error” from catching “terror”. It’s not always the right choice, and it should be a choice rather than a hidden default either way.
Local processing
Log files are exactly the content you shouldn’t paste into a service that uploads it. Browser-only processing is the difference between a convenient tool and an incident.
| You want | Action | Watch for |
|---|---|---|
| Drop DEBUG noise | Remove matching | Case sensitivity |
| Extract one order | Keep matching | Substring over-matching |
| Strip repeated headers | Remove matching | Header text appearing in data |
Common mistakes to avoid
- Filtering on a short term like “id” and removing half the file.
- Forgetting case sensitivity when filtering log levels.
- Running the filter and copying the result without checking the line counts.
- Pasting production logs into a tool that uploads them.
- Filtering out the lines around an error — the context above and below is usually what explains it.
How to do it with Remove Lines Containing Text
The Remove Lines Containing Text tool filters in the browser, so nothing is transmitted.
- Paste the lines, log output, or exported list.
- Enter the word or phrase to match.
- Choose remove or keep, and set case sensitivity and whole-word matching.
- Check the before and after counts before copying the result out.
Other text processing tools that keep content local are in the tools directory.
Frequently asked questions
Does it support regular expressions?
Plain substring matching covers most cases and avoids the surprises regex brings. For genuine pattern matching, a regex-capable editor or grep is the better tool.
Why did it remove more lines than expected?
Substring matching finds the word inside longer words too. Whole-word matching stops “error” from also matching “errors” and “terror”.
Is my text uploaded?
No. Filtering happens in the page, which matters when the text is a log file containing internal hostnames or user data.
Final thought
Read the line counts before you copy the output. A filter that silently removed three times what you expected looks exactly like one that worked.