Writing regex on a touchscreen sounds like a terrible idea until the day you are on a train, debugging an export from a customer database, and you need to pull every email address out of a 4000-line CSV. Suddenly the on-screen regex tester is not optional.
These are the five patterns I have ended up using most often from a phone. None are the "RFC-compliant" version. Real-world patterns are usually loose, and that is fine.
1. Extract every email address
[\w.+-]+@[\w.-]+\.[a-zA-Z]{2,}This catches almost any sensibly-formatted email. The first character class allows letters, digits, underscore, dot, plus sign, and hyphen, which covers [email protected] style addresses. The TLD is constrained to 2 or more letters, which keeps us from matching things like [email protected].
What it will not catch: addresses with quoted local parts ("weird name"@example.com) or Unicode TLDs. In 99% of real-world data you will never see either, so do not bother making the pattern more complex.
The gotcha: turn on the global flag so you get all matches, not just the first. On iOS most tools do this by default, but if a pattern only ever returns one result, that is what to check.
2. Extract URLs
https?://[^\s)>"]+Match http or https, then any character until we hit whitespace, a closing parenthesis, a closing angle bracket, or a double quote. The trailing exclusions catch the most common ways a URL gets enclosed in surrounding punctuation.
The classic mistake here is to use https?://\S+ and end up matching the trailing comma or period in a sentence. The exclusion list above is short enough to remember and broad enough for real text.
3. Find ISO dates and timestamps
\b\d{4}-\d{2}-\d{2}(?:T\d{2}:\d{2}:\d{2}(?:\.\d+)?Z?)?\bThis finds 2026-04-12, 2026-04-12T14:30:45, and 2026-04-12T14:30:45.123Z all at once. The non-capturing groups make the time portion optional, and the milliseconds and Z suffix are also optional.
I use this constantly when grepping logs on a phone. Combined with a replace step, you can turn ISO timestamps into a more readable format, or just clean noise out of a log line.
4. Phone numbers (loose)
\+?\d[\d\s().-]{8,}\dStart with an optional +, then a digit, then 8 or more "phone characters" (digits, spaces, parentheses, dots, hyphens), then a digit. This catches:
+44 20 1234 5678(555) 123-45671.555.123.456700 33 1 23 45 67 89
It also catches some false positives, like long ISBNs or product SKUs that happen to look phoneish. For pulling phone numbers out of human-written text, the false positive rate is low enough to be useful.
Do not try to write a strict phone regex. Real phone numbers come in too many shapes, and the libraries that parse them properly (Google\'s libphonenumber) are giant for a reason.
5. Lines that contain X (filter mode)
^.*ERROR.*$Combined with the multiline flag (m), this finds every line in a log file that contains the word ERROR. Replace ERROR with whatever pattern you actually want to match - a SKU, a username, a transaction ID.
This is a "use regex as a filter" pattern. In a regex tester, you can use replace mode with a replacement of "" to delete every line that does not match, or invert the match to delete matching lines.
This single technique replaces a surprising number of one-off scripts I used to write on the command line.
The replace patterns
Half of regex utility on a phone is the replace half. A few patterns I use a lot:
| Pattern | Replace with | What it does |
|---|---|---|
[ \t]+$ (with m flag) | (empty) | Strip trailing whitespace from every line. |
\n{3,} | \n\n | Collapse multiple blank lines into one. |
(\d{4})-(\d{2})-(\d{2}) | $3/$2/$1 | Reformat ISO dates to DD/MM/YYYY. |
"([^"]+)" | $1 | Unwrap quoted strings. |
The two flags worth knowing
ifor case-insensitive. Always on for human-written text.mfor multiline, when^and$need to match line boundaries instead of just the start and end of the whole text.
Most other flags are situational. If a pattern is not matching what you expect, check these two first.
One genuinely useful habit
When a pattern misbehaves, simplify it until it does behave, then add the parts back one at a time. If https?://[^\s)>"]+\.com finds nothing, drop the \.com and see if the rest works. If it does, the issue is in the bit you removed. Sounds obvious; almost nobody does it.