Guide ยท 8 min read

Regex Cheat Sheet for Sysadmins and Developers

Core syntax, real-world patterns for IT work, and the mistakes โ€” greedy matching, unescaped dots, catastrophic backtracking โ€” that trip people up most.

Why Regex Is Worth Knowing

Regular expressions let you search, validate and extract text by pattern instead of exact match โ€” parsing log files, validating form input, filtering firewall logs by IP, or bulk-renaming files. A handful of building blocks cover the vast majority of real-world use, and this page is a working reference for exactly those.

Core Syntax Reference

  • ^ โ€” start of string/line
  • $ โ€” end of string/line
  • . โ€” any single character (except newline)
  • \d โ€” any digit (0-9); \D โ€” any non-digit
  • \w โ€” any word character (letters, digits, underscore); \W โ€” the opposite
  • \s โ€” any whitespace character; \S โ€” the opposite
  • * โ€” zero or more of the previous token; + โ€” one or more; ? โ€” zero or one
  • {n,m} โ€” between n and m repetitions; {n} โ€” exactly n
  • [abc] โ€” any one of a, b or c; [^abc] โ€” any character except a, b or c; [a-z] โ€” a range
  • () โ€” a capturing group; (?:) โ€” a non-capturing group
  • | โ€” alternation (this OR that)
  • (?=...) โ€” positive lookahead; (?!...) โ€” negative lookahead

Practical Patterns for IT Work

Matching an IPv4 address (simple version, doesn't reject invalid octets over 255):

\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b

Extracting a timestamp from a log line like 2026-09-15 14:32:07 ERROR disk full:

^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})

A reasonable email pattern for basic validation (not a full RFC 5322 implementation, but fine for most sanity checks):

^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$

Matching a Windows file path:

^[a-zA-Z]:\\(?:[^\\/:*?"<>|\r\n]+\\)*[^\\/:*?"<>|\r\n]*$

Test and refine any of these live with the Regex Tester โ€” it highlights matches and captured groups as you type, including a built-in library of common patterns.

Common Mistakes

  • Forgetting to escape special characters. A literal dot in an IP address needs to be written \. โ€” an unescaped . matches any character, which is why 192.168.1.1 would also incorrectly match something like 192a168a1a1.
  • Greedy vs. lazy matching. By default, * and + are greedy โ€” they match as much as possible. Adding ? after them (e.g. .*?) makes them lazy, matching as little as possible. This matters a lot when extracting content between two delimiters in a line that contains the delimiter more than once.
  • Catastrophic backtracking. Patterns with nested repetition (like (a+)+) can cause the regex engine to try an exponential number of combinations on certain inputs, effectively hanging. Keep nested quantifiers simple and specific where possible.
  • Not anchoring the pattern. Without ^ and $, a pattern can match a substring anywhere in the text rather than the whole string, which is rarely what you want for validation.

Tools For This Guide

Frequently Asked Questions

What's the difference between greedy and lazy matching?
A greedy quantifier (*, +) matches as much text as possible before backtracking if needed. A lazy quantifier (*?, +?) matches as little as possible. This matters when a delimiter appears more than once in the text you're parsing โ€” greedy matching can grab far more than intended.
Why does my IP address pattern also match invalid addresses like 999.999.999.999?
A simple pattern like \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} only checks digit count, not the valid 0-255 range per octet. A fully strict IPv4 pattern is much longer and uses alternation to constrain each octet โ€” usually not worth the complexity unless you specifically need to reject out-of-range values.
What is catastrophic backtracking?
It happens when a regex pattern has ambiguous nested repetition (like (a+)+b matched against a string with many a's and no trailing b), causing the engine to try an enormous number of matching paths before failing. This can make a pattern hang on certain inputs โ€” avoid nesting quantifiers unless necessary.
Is regex the right tool for parsing structured data like JSON or XML?
Generally no โ€” use a proper parser for structured formats, since regex struggles with nested structures. Regex is best for line-based text, log parsing, simple validation and extracting patterns from otherwise unstructured text.

Test Your Regex Live

Live match highlighting, group capture, and a built-in library of common patterns to start from.