Test a regular expression and inspect matches against sample text. Use Regex tester without creating an account. The workbench keeps the source and result together so you can check the output before downloading it.
Regex tester covers developing validation patterns, extracting structured values, and debugging search expressions. Its controls stay on one page, with status and validation messages beside the work area.
Your input and generated result are processed in your browser and are not sent to a PWRKIT processing server. If the input contains sensitive information, follow your organization’s rules for online utilities.
Before using the result, confirm that a JavaScript pattern, flags, and sample text is complete and that matches with positions and captured values matches the destination format. Keep the original until you have checked the output in the application or context where it will be used.
The related developer tools cover the next common tasks without changing your original input.
- 01
Provide a JavaScript pattern, flags, and sample text. The tool checks the input before processing it.
- 02
Adjust the available regex tester settings for the result you need.
- 03
Run Regex tester. If the input is incomplete, the workbench explains what to correct.
- 04
Check matches with positions and captured values, then copy or download the result. Your original input stays unchanged.
- developing validation patterns
- extracting structured values
- debugging search expressions
Is Regex tester free to use?
Yes. Regex tester is available without an account or subscription.
Does Regex tester upload my input?
Regex tester processes your input in your browser. Your entered content and generated result are not sent to a PWRKIT processing server.
Does Regex tester change the original?
No. Regex tester leaves the source untouched. Copy or download the generated result as a separate output.
What should I check after using Regex tester?
Confirm that matches with positions and captured values matches the intended format and context. Keep the original until the result has been verified.
Regex Tester passes the entered pattern to JavaScript's RegExp constructor and runs it against the test text in the browser. Enter only the pattern body, not slash delimiters. For example, use `\bcat\b`, not `/\bcat\b/g`. The selected mode supplies the flags.
The available modes are global `g`, global plus case-insensitive `gi`, and global plus case-insensitive plus multiline `gim`. Every run searches globally, so the result lists all nonoverlapping matches rather than stopping at the first one. Other JavaScript flags such as `s`, `u`, `y`, and `d` are not offered by the current controls.
Regex syntax differs across programming languages and tools. A pattern copied from PCRE, Python, .NET, Java, or a command-line program may use constructs that JavaScript rejects or interprets differently. Validate in the same JavaScript runtime that will run the production code.
The `g` mode preserves case sensitivity and reports all matches. `gi` adds case-insensitive matching, so a pattern such as `cat` can match `cat`, `Cat`, and `CAT` under JavaScript's casing rules. `gim` also changes the meaning of `^` and `$`, allowing them to match at line boundaries within the test text rather than only at the start and end of the entire input.
The multiline flag does not make dot match newline characters. JavaScript's `.` still excludes line terminators without the dotAll `s` flag, and that flag is not selectable here. To span lines in this tester, use an explicit class such as `[\s\S]` when it fits the pattern's intent, then test carefully for excessive matches.
Case-insensitive behavior with international text can be less intuitive than ASCII examples. If a validator has locale-specific casing requirements, regular-expression flags may not express the business rule. Normalize and compare under a clearly chosen locale in application code where necessary.
Each result begins with a match number, the zero-based index, and the complete matched text. JavaScript indexes strings by UTF-16 code units, not by user-perceived characters. Text before a match that contains emoji or some historic scripts can make the reported index differ from a count of visible characters.
If the pattern has capturing parentheses, the result adds a groups line containing capture values in order. Noncapturing groups written as `(?:...)` structure the pattern without adding a numbered capture. Named groups can be valid JavaScript syntax, but this display lists capture values positionally and does not print the group names.
Optional captures that did not participate can appear as empty positions in the comma-separated group display. Commas inside captured text can also make the summary ambiguous. For production extraction, read the match array or named groups directly in code rather than parsing this human-readable output.
Start with representative positive and negative examples in the test text. Write the smallest pattern that finds one intended fragment, then add boundaries and groups. Run after each change. A pattern for an invoice code might begin with `INV-\d+`, then add boundaries if letters or digits must not touch either side.
Include difficult inputs before calling the pattern finished: empty text, extra spaces, line breaks, punctuation, mixed case, Unicode characters, near misses, repeated values, and very long lines. For validation, test both an allowed value and a value that differs by one forbidden character. A pattern that matches the good example says little about what it rejects.
Copy the final pattern into an automated test in the target application. Keep the flags beside it. Test the production operation, such as full-string validation or replacement, because this workbench only reports matches and does not perform replacement or enforce that the whole input matched.
A match somewhere inside the text is not the same as validation of the full value. Pattern `\d+` matches the digits inside `order 123`, while `^\d+$` requires a digits-only string under nonmultiline semantics. In this tester the flags always include `g`, and the `gim` mode makes anchors apply per line, so choose the mode that matches the validation context.
Word boundary `\b` is defined from JavaScript word-character behavior and can surprise on hyphens, apostrophes, and non-Latin scripts. Explicit surrounding conditions or Unicode-aware application logic may fit names and multilingual text better. Do not use an ASCII-focused pattern as a silent policy for who can register or what addresses are valid.
Lookarounds can assert context without consuming it when supported by the target browsers. Lookbehind support in older runtimes may differ. If compatibility matters, check the browser and server matrix rather than assuming a pattern accepted on one current browser works everywhere.
Some regular expressions take extreme time on crafted input because nested or overlapping quantifiers cause heavy backtracking. Patterns resembling `(a+)+$` are a classic warning sign. A quick match on a short friendly sample does not prove safe performance on a long failing string.
Use bounded quantifiers, clearer character classes, and unambiguous separators where possible. Test long near-miss inputs, not only matches. If users control both pattern and text in an application, consider execution limits, a safer engine, or a restricted pattern language. Browser JavaScript does not provide a built-in timeout for one synchronous RegExp execution.
This workbench runs the pattern on the page's main JavaScript context. A pathological expression can make the tab unresponsive. Keep experiments small, save other work first, and move performance testing into a controlled script where the process can be terminated.
A syntax error can come from an unmatched parenthesis or bracket, an invalid escape, a malformed quantifier, or a construct JavaScript does not support. Remember that the input is already a pattern field, so slash delimiters become literal characters or syntax trouble instead of defining flags. Select flags from the menu.
Too many matches often mean the pattern is less constrained than expected. Check greedy quantifiers, missing anchors, dot behavior, and empty alternatives. Too few matches can come from case sensitivity, a boundary assumption, escaping, or line anchors used without multiline mode. Reduce the example until the first unexpected position is clear.
Zero-length matches are possible with anchors, optional groups, and lookarounds. JavaScript's global matching advances safely, but a list of empty results may not be useful for extraction. Decide whether empty matches have meaning in the application and reject or handle them explicitly.
The pattern field accepts RegExp source directly. Application code may add another escaping layer. A JavaScript regex literal `/\d+/g` contains one backslash in its pattern, while a JavaScript string passed to `new RegExp` needs `"\\d+"` so the resulting string contains that backslash.
JSON adds its own string escaping. To transmit a pattern that contains `\d`, the JSON text must escape the backslash. Shells, YAML, environment files, and templating systems each have different quoting rules. Count the layers from the stored text to the RegExp constructor instead of adding slashes until a test passes.
Copy the tester's pattern into the target form carefully. If the destination expects slash delimiters, add them there with the correct flags. If it expects a raw source string, do not add slashes. A pattern serialized inside JSON needs JSON escaping, not regex changes.
Literal user input should not be inserted into a pattern without escaping regex metacharacters. Characters such as `.`, `*`, `+`, `?`, parentheses, brackets, braces, caret, dollar, pipe, and backslash have syntax meaning. Use a well-tested escape helper appropriate to the runtime.
Character classes have their own rules. A hyphen can define a range, a closing bracket can end the class, and a caret at the beginning negates it. Test literal punctuation at the beginning, middle, and end of sample text rather than assuming one escape works in every position.
Backreferences such as `\1` refer to earlier captures and can make later edits fragile when a new capturing group is inserted. Prefer named groups in application code when supported and meaningful, or use noncapturing groups for structure. Update tests whenever group numbering changes.
Keep the production pattern readable. Break a complicated policy into parsing and validation stages when one expression becomes hard to review. Comments are not supported inside ordinary JavaScript regex source, so surrounding code and tests must explain the intended cases.
Unicode requires deliberate tests. Without a selectable `u` flag, code-point escapes and character handling may not behave like a Unicode-aware production expression. Character ranges such as `[A-Z]` cover ASCII letters, not every script. JavaScript property escapes need Unicode mode, which this menu cannot enable. If the application accepts international names, identifiers, or prose, test the pattern in code with the exact production flags and normalization step. Include combining marks, emoji sequences, right-to-left text, and characters outside the basic multilingual plane. Do not silently reject a person or language because an ASCII sample passed.