모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
상단 입력에서 패턴을 편집합니다. 앞뒤 슬래시는 필요 없고 표시는 래퍼가 자동으로 붙입니다. 플래그 칩(g·i·m·s·u·y)을 토글하면 각 플래그가 동작에 미치는 영향을 확인할 수 있습니다. 아래 테스트 문자열에는 매치가 인라인으로 하이라이트되고, 캡처 그룹과 명명 그룹은 하단 패널에 위치 정보와 함께 표시됩니다.
파서는 브라우저의 정규식 엔진 자체이므로 문법과 동작이 런타임의 `new RegExp(...)`와 정확히 일치합니다. JavaScript와 TypeScript의 동작을 정확히 미리 볼 수 있지만, Python·Go·Java·PCRE 패턴 테스트에는 적합하지 않습니다. 이들은 JS에 없는 기능(일부 후방 탐색 변종·소유 한정자·원자 그룹 등)을 가지고 있습니다.
pattern: \b([\w.+-]+)@([\w-]+\.[\w.-]+)\b flags: gi text: Contact alice@example.com or BOB@test.org. Also: charlie@nope, dave@work.io.
3 matches #1 alice@example.com group1=alice group2=example.com #2 BOB@test.org group1=BOB group2=test.org #3 dave@work.io group1=dave group2=work.io
g플래그로 첫 1건에서 멈추지 않고 모두 반환하며, i플래그로 대·소문자를 무시합니다. "charlie@nope"은 호스트 부분에 점이 없어 제외됩니다.
pattern: (?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2}) flags: g
text: started 2024-01-15, deployed 2024-06-30, retired 2025-01-013 matches #1 2024-01-15 y=2024 m=01 d=15 #2 2024-06-30 y=2024 m=06 d=30 #3 2025-01-01 y=2025 m=01 d=01
명명 그룹 (?<name>...)은 번호 그룹보다 읽기 좋고, 실제 코드에서는 match[1] 대신 match.groups.y로 접근할 수 있습니다.
pattern: ^ERROR.* flags: gm text: INFO starting ERROR file not found WARN retrying ERROR timeout
2 matches #1 ERROR file not found #2 ERROR timeout
m 없이는 ^가 입력 전체의 맨 앞에서만 매치됩니다. m을 켜면 각 줄의 시작에 매치되며, 로그 파싱에는 거의 항상 이 동작이 필요합니다.
pattern: <pre>(.*?)</pre> flags: gs text: <pre>line one line two</pre> trailing
1 match #1 <pre>line one\nline two</pre> group1=line one\nline two
일반적으로 .는 줄바꿈에 매치되지 않습니다. s플래그를 켜면 .가 \n을 포함한 모든 문자에 매치되어 줄바꿈을 가로지르는 캡처가 가능합니다. .* 뒤의 ?로 비탐욕 매치를 만들어 첫 </pre>에서 멈춥니다.
플레이버가 다릅니다. JavaScript정규식은 Python의 re, Java의 java.util.regex, PCRE와 비슷하지만 동일하지는 않습니다. 자주 부딪히는 차이는 소유 한정자(a++), 원자 그룹((?>...)), 일부 유니코드 속성 변종 미지원입니다. 브라우저나 Node코드를 작성할 때는 JS플레이버 레퍼런스를 참고하세요.
g가 없으면 regex메서드는 첫 매치에서 멈춥니다. exec·match·replace 모두 1건만 돌려줍니다. g를 켜면 문자열 전체를 훑습니다. "왜 다른 매치는 안 잡히지?" 질문의 대부분은 g플래그 누락이 원인입니다.
u플래그를 켜세요. \w나 문자 클래스, \p{...} 유니코드 속성 이스케이프가 올바로 동작합니다. 예: 한글 음절은 \p{Script=Hangul}, 히라가나는 \p{Script=Hiragana}, 이모지는 \p{Emoji_Presentation}. u 없이는 이 이스케이프들이 에러를 내거나 예상과 다르게 동작합니다.
한정자 뒤에 ?를 붙입니다. .*?는 가능한 한 적게, .+?는 최소 1글자 이상으로 가장 짧게 매치합니다. 탐욕 한정자(.*·.+)는 최대한 길게 가져가므로 구분자가 있는 블록을 다룰 때 "너무 넓게 잡혔다" 버그의 주된 원인입니다.
이론적으로는 가능하며 RFC 5322 준수 정규식도 존재하지만, 엄격한 패턴은 수백 글자에 달하고 그래도 경계 케이스에서 오인식합니다. 검증 목적이라면 "@ 하나가 있고 양쪽이 비어 있지 않다" 정도만 허용한 뒤 확인 메일로 진위를 확인하는 게 현실적입니다. 추출 목적(위 예시 같은 용도)이라면 더 간단한 패턴으로 충분합니다.
정규식은 텍스트의 패턴을 기술하기 위한 작은 언어입니다. 엔진은 패턴을 읽어 상태 기계를 만들고, 입력을 한 글자씩 진행하며 기계가 계속 진행 가능한지를 판정합니다. 초보자가 자주 막히는 개념이 둘 있습니다. 첫째, 탐욕과 비탐욕입니다. 한정자는 기본적으로 가장 길게 매치하려 하므로 HTML태그나 따옴표가 들어간 문자열 같은 구분자 콘텐츠에서는 의도보다 넓게 잡히기 쉽습니다. 둘째, 백트래킹입니다. 어떤 경로가 실패하면 엔진은 되돌려 다른 경로를 시도하므로 병적인 패턴(a+a+b에 aaaaaaaac)은 수십억 단계로 폭증할 수 있습니다. "정규식 서비스 거부"로 알려진 ReDoS버그가 정확히 이 현상입니다.
JavaScript정규식은 플레이버 지형에서 중간 위치에 있습니다. POSIX BRE/ERE보다 강력하지만 PCRE보다는 가볍습니다. ECMAScript 2018에서 후방 탐색과 명명 그룹이 추가되었고, ES2022에서 d플래그(매치 위치), ES2024에서 v플래그(집합 표기)가 추가되었습니다. 다른 언어에서 넘어온 사람이 가장 당황하는 부분은 가변 길이 후방 탐색(JS는 최근까지 제약), 소유 한정자, 재귀 패턴의 부재이며, 셋 다 JS에 네이티브 기능으로 존재하지 않습니다.
Contact alice@example.com or BOB@test.org. Also: charlie@nope, dave@work.io.
JavaScript 플레이버 (ECMAScript). PCRE / Python과는 일부 세부에서 차이가 있습니다.