도구 가이드
Developer 무료 회원가입 불필요

Regex Library

Searchable library of 50+ common regular expression patterns with live tester.

도구를 불러오는 중…

이 도구에 대해

Browse a curated catalog of over 50 ready-to-use regular expression patterns covering email addresses, URLs, phone numbers, IP addresses, dates, credit cards, hex colors, UUIDs, postal codes, and more. Each entry includes the pattern, a plain-English description, and copy-to-clipboard. The built-in live tester lets you paste any text and instantly see all matches highlighted inline so you can validate the pattern before dropping it into your code.

사용 방법

  1. 1 Search or browse the pattern catalog by name or category.
  2. 2 Click a pattern card to load it into the live tester.
  3. 3 Paste or type your sample text in the test area.
  4. 4 Matched portions are highlighted immediately.
  5. 5 Click the copy button to copy the pattern to your clipboard.

What a regular expression actually matches

A regular expression is a compact grammar for describing sets of strings. Instead of asking "is this exactly equal to that," a regex asks "does this text contain a substring that fits this shape." The shape is built from literal characters plus metacharacters: \d means any digit, + means one or more of the preceding item, [a-z] means any one lowercase letter, {2,4} means between two and four repetitions, and anchors like ^ and $ pin the match to the start or end of a line. This library collects 50+ patterns that are already correctly assembled for common tasks — email addresses, URLs, phone numbers, IP addresses, dates, credit cards, hex colours, UUIDs, postal codes, and more — so you can copy a tested pattern instead of writing one from scratch.

Why the flags matter as much as the pattern

A regex is only half a specification; the flags are the other half. Each pattern here ships with the flags it was designed for:

  • i — case-insensitive, so #FF5733 and #ff5733 both match a hex-colour pattern.
  • g — global, meaning "find every match," not just the first. Without it, a search stops at the first hit.
  • m — multiline, which makes ^ and $ match the start and end of each line rather than the whole string.
  • s — dotall, letting . match newlines too; the HTML-comment pattern uses it so a comment can span several lines.

A correct pattern with the wrong flags gives wrong results — for example, an email-extraction pattern without g finds only the first address in a paragraph. That is why each card shows its flags explicitly, and why the live tester always applies g internally when counting matches so the total reflects every occurrence.

How the live tester works

Click any pattern card and it loads into the tester's pattern and flags fields; paste sample text and matches are highlighted inline as you type. Under the hood the tester compiles your pattern with the browser's native RegExp engine, runs match() across your text, reports the count, and wraps each hit in a highlight. If the pattern is malformed, you get the engine's exact error message instead of a silent failure — useful when you're editing a pattern by hand. Because it uses the JavaScript engine, what you see is exactly how the regex will behave in RegExp, String.match, replace, and similar calls in real code. Everything runs locally; no text leaves your browser.

A worked example

Load the IPv4 Address pattern, \b(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.(?:…)\.(?:…)\.(?:…)\b, and paste Servers: 192.168.1.1, 10.0.0.255, and 999.1.1.1. The tester highlights the first two but not 999.1.1.1 — and that's the point of the pattern's design. Each octet is constrained: 25[0-5] matches 250–255, 2[0-4]\d matches 200–249, and [01]?\d\d? matches 0–199. Since 999 fits none of those, it's correctly rejected. A naive pattern like \d+\.\d+\.\d+\.\d+ would have wrongly accepted it. Seeing the difference live is what turns a copied pattern into one you actually trust.

Patterns that look right but aren't always

  • Email. No reasonable regex fully validates an email address per the RFC; these patterns catch the overwhelmingly common forms, but the only definitive test is sending a confirmation message.
  • Phone numbers. The US pattern accepts several common formats, but real phone validation is locale-specific. The international E.164 pattern is stricter but assumes the number is already normalised.
  • Credit cards. The card patterns verify the prefix and length of a number, not its checksum. A string can match the Visa pattern and still fail the Luhn check, so treat these as format filters, not validators.
  • Base64. The Base64 pattern can match an empty string because every part is optional — useful to know if you're counting matches.

Practical tips

When you copy a pattern into your own code, copy the flags too — they're shown right beside each pattern. Test against your real data, including the edge cases you expect to reject, not just the ones you expect to accept; the IPv4 example above shows why. Use the category filter to narrow a long list to "Network," "Finance," or "Date/Time" when you know the domain. And remember that JavaScript regex differs slightly from Python or PCRE in features like lookbehind support and named groups; most patterns here are portable, but verify in your target language before shipping. The search box matches on pattern name, description, and category, so a query like date surfaces every dated pattern at once.

자주 묻는 질문

{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}