すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
上部の入力欄でパターンを編集します。先頭と末尾のスラッシュは不要で、表示はラッパーが付けてくれます。フラグチップ（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++）、原子グループ（(?>...)）、一部の Unicode プロパティ変種への非対応です。ブラウザや Node のコードを書くときは JS フレーバーのリファレンスを参照してください。
g がない場合、regex メソッドは最初のマッチで止まります。exec・match・replace のいずれも 1 件しか返しません。g を付けると文字列全体を走査します。「なぜ他のマッチが取れない？」という質問の大半は g フラグの付け忘れが原因です。
u フラグを有効にしてください。これで \w や文字クラス、\p{...} の Unicode プロパティエスケープが正しく動きます。例: ハングルなら \p{Script=Hangul}、ひらがななら \p{Script=Hiragana}、絵文字なら \p{Emoji_Presentation}。u がないとこれらのエスケープはエラーになるか、想定外の挙動になります。
量指定子の後ろに ? を付けます。.*? は可能な限り少なく、.+? は最低 1 文字以上で最短にマッチします。貪欲量指定子（.*・.+）はできるだけ長く取るため、区切り付きブロックを扱うときの「広く取りすぎる」バグの原因になります。
理論上は可能で、RFC 5322 に準拠した正規表現は存在しますが、厳密なものは数百文字に及び、それでも端のケースで誤検出します。検証目的なら「@ が 1 つあって両側が空でない」程度を許容し、確認メールで本物か確かめるのが現実的です。抽出目的（上記の例のような用途）であればもっと簡単なパターンで十分です。
正規表現はテキスト中のパターンを記述するための小さな言語です。エンジンはパターンを読み込んで状態機械を構築し、入力を 1 文字ずつ進めながらマシンを継続できるか判定します。初心者がよくつまずく概念が 2 つあります。1 つは貪欲と非貪欲の違いです。量指定子は既定で最も長くマッチしようとするため、HTML タグや引用符付き文字列などの区切り付きコンテンツでは想定外に広くマッチしがちです。もう 1 つはバックトラックです。経路が失敗するとエンジンは巻き戻して別経路を試すため、病的なパターン（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 とは細部で異なる場合があります。