A PlainSift practical guide

Extract lines containing “error” from a copied log

Keep or remove log lines containing a literal fragment, without learning regular expressions.

By PlainSift · Examples checked against the tool implementations

When a copied log has too much noise, filtering by a known fragment can make a first inspection easier. Paste the text into Filter lines by text to keep every line containing “error”. The default is case-insensitive, so ERROR, Error, and error all match without a regular expression.

This is a line filter rather than a log parser. It does not recognize severity fields, group stack traces, or understand whether a line describes a real failure. Use a precise fragment from your log format when the word “error” alone would return unrelated status messages.

Start with Filter lines by text

Free, no sign-up. Your pasted text stays in the browser workspace.

Step-by-step instructions

These steps use the default options shown in each tool. Add changes in the order listed.

Filter lines by text
Open Filter lines by text, paste the log excerpt, and keep the default search text “error”, keep-matches mode, and case-insensitive matching. Select Run pipeline.

Review the full output, then use Copy result or Download .txt.

Before and after

Input

INFO service ready
ERROR connection refused
DEBUG retry scheduled
error: request timed out
INFO done

Result

ERROR connection refused
error: request timed out

Only the two lines containing the fragment “error” remain. Their original capitalization and relative order are preserved.

Use a literal fragment that fits the question

If your logger writes levels in brackets, searching for “[ERROR]” can be more useful than searching for “error”. Brackets, periods, asterisks, and backslashes are ordinary characters here. Entering “error|warn” looks for that exact string; it does not mean error OR warn.

Spaces in the search field also count. A trailing space can distinguish a marker followed by a message, but an accidental space can hide matches. Turn on case sensitivity when you need an exact uppercase marker. An empty search term is rejected instead of matching every line.

Remove noise or combine filters carefully

Switch to remove-matches mode to discard lines containing a known noise marker, such as a health-check path. Every retained line stays in its original order. Repeated lines remain repeated, which matters when you are checking how often a failure occurred.

Two consecutive keep filters behave like AND: a line must survive both steps. They do not combine alternative matches. Filtering can also remove the lines following an error, including useful stack frames that lack the search fragment. Keep the source excerpt for context, or use a log viewer with surrounding-line and event-aware search.

Common questions

Does “no errors found” match the default filter?

Yes. Matching is a literal substring check, not a whole-word or severity check. Choose a marker specific to your logging format when you need fewer false positives.

Are pasted logs uploaded for filtering?

The transformation runs in the separate browser workspace. Its text and search field remain in memory rather than being sent to the public page, analytics, or a processing server. Closing or resetting the workspace clears that in-memory text.