Grep patterns, explained and testable
Grep is the forty-year-old answer to an eternal problem: show me the lines that match. Exact strings, prefixes, suffixes, or full regular expressions — one pattern over a wall of log output and the signal pops out of the noise.
The gap between the pattern in your head and the pattern that works is where time dies. Testing against real sample text with live highlighting, context lines and invert-match shows instantly whether the pattern catches what you meant — before you run it against a gigabyte of production logs.
Open the free Grep Pattern Tester — no signup, runs entirely in your browser.
How to use it
- Paste the text you want to search — logs, CSV dumps, code, anything.
- Type an exact string or a regex pattern and pick a match mode.
- Tune case sensitivity, whole-word, invert and context lines; matches highlight live.
Why this one
- Match modes: contains, prefix, suffix, exact line, or full JavaScript regex.
- Context lines before and after each match, like grep -B and -A.
- Invert match to show everything except the pattern — the -v workflow.
- Case-insensitive, whole-word, multiline and dotall options one toggle away.
Frequently asked questions
What is the difference between grep and regex?
Grep is the tool; regular expressions are the pattern language it speaks. Basic grep searches literal text, but its real power comes from regex patterns like ^ERROR|WARN$.
How do I show lines that do NOT match?
That is invert match — grep -v on the command line, a toggle here. It is the fastest way to strip noise: exclude every health-check line and the interesting logs remain.
What are context lines for?
A match alone rarely tells the story. Context lines show the lines surrounding each hit — like grep -B 3 -A 3 — so you see the stack trace above the error, not just the error.