Test bounded JavaScript regular expressions in a dedicated browser worker. Inspect highlighted full matches, numbered and named captures, zero-width matches, and exact UTF-16 code-unit ranges for g, i, m, s, u, and y behavior. Matching uses a one-second timeout, bounded previews, and explicit zero-width advancement. It uses the browser's native JavaScript RegExp engine rather than PCRE, keeps patterns and test text out of analytics, and does not prove the same expression is safe or compatible in another runtime.
Continue with a related workflow or open the next tool that usually follows this task.
HTML-to-JSX conversion removes repetitive syntax work, but migration quality depends on what happens afterward. This workflow records the original behavior, limits the conversion to one coherent fragment, compares browser-normalized structure, rewrites legacy events and URLs, moves styles and assets into the destination project, and finishes with lint, type, accessibility, responsive, and security checks. The generated JSX is treated as reviewable source, not as a sanitized or complete component.
OpenRelated toolConvert bases, inspect queries, calculate px/rem, transform escapes, and build commit messages in one local workbench.
OpenRelated toolCompare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
OpenRelated toolRemove line-start numbering while preserving inline values, indentation, and exact line endings.
OpenEnter the JavaScript RegExp pattern body without surrounding slash delimiters or source-code quotes.
Select only the g, i, m, s, u, and y flags required by the runtime behavior you need to reproduce.
Paste, type, drop, or load bounded test text; an empty test string is valid when the pattern is not empty.
Run the test explicitly and cancel it if needed; a dedicated worker is automatically terminated after one second.
Check the full-match highlights, zero-width markers, half-open UTF-16 ranges, and numbered or named capture values.
Copy or download the report only while it is current, then retest representative failures and long near-matches in the destination runtime.
Verify line anchors, severity alternatives, repeated matches, and named fields against the actual multiline block before editing a log parser.
Inspect numbered and named capture ranges before using the pattern in JavaScript replace callbacks or structured extraction code.
Compare m and s behavior on copied stack traces, documents, code, and issue text without changing line endings or whitespace first.
Confirm how u affects astral code points and zero-width lookaheads while keeping JavaScript's UTF-16 offset model visible.
Run long failing and near-matching samples in a terminated worker to identify obvious backtracking risk before deeper runtime-specific load testing.
JavaScript string literals and JSON values escape backslashes before the RegExp engine sees them. Paste the pattern body, such as \s+, rather than a quoted source string containing doubled escaping unless doubled backslashes are what you intend to match.
The m flag changes only how ^ and $ treat line boundaries. It does not make dot match line terminators; that is the separate s flag. The g flag controls repeated retrieval rather than multiline anchoring.
Ranges are reported as half-open UTF-16 code-unit offsets, matching JavaScript String and RegExp APIs. An emoji can occupy two code units, and a visible grapheme can contain several code points, so the offsets are not user-perceived character positions.
Nested ambiguous quantifiers and long failing suffixes can trigger catastrophic backtracking. The worker is terminated after one second, but a timeout does not prove that the pattern is safe in a server, editor, or production request path.
A regex match proves only that text fits the chosen pattern. It does not prove that an email exists, a date is valid on the calendar, a URL is safe, or a password is strong. Use a parser and domain validation after pattern screening.
Global and multiline matching finds the ERROR and WARN rows, returns three numbered captures per match, and exposes level and service as named captures. The INFO row is intentionally excluded.
Pattern: ^(?<level>ERROR|WARN)\s+\[(?<service>[^\]]+)\]\s+(.+)$
Flags: gm
Text:
ERROR [billing] Payment failed for order 1042
INFO [api] Request completed
WARN [search] Slow query detectedReturned matches: 2 | Numbered captures: 6 | Named captures: 4 | Zero-width matches: 0The lookahead matches before each emoji without consuming text. With the u flag, the engine advances by one Unicode code point after each zero-width result, producing UTF-16 offsets 0 and 2 instead of looping forever or entering the surrogate pair.
Pattern: (?=😀)
Flags: gu
Text: 😀😀Returned matches: 2 | Ranges: [0, 0), [2, 2) | Zero-width matches: 2The worker constructs the browser's native RegExp with the selected g, i, m, s, u, and y flags. Global controls repeated exec() calls, multiline changes ^ and $ line-boundary behavior, dot-all lets dot include line terminators, Unicode changes code-point-aware pattern behavior, and sticky requires the next match at lastIndex.
Untrusted matching never runs on the page's main thread. A module worker loads the bounded engine, and the page terminates the worker if it has not completed within 1,000 ms. Browsers without Worker support do not fall back to unsafe synchronous execution.
When supported, the engine adds the d flag internally to obtain exact full and capture ranges. Ranges are half-open UTF-16 code-unit offsets, so slicing testText.slice(start, end) reproduces the matched span even when code-point or grapheme counts differ.
Global zero-width results require manual lastIndex advancement because no text was consumed. Without u, advancement is one UTF-16 code unit; with u, a high-surrogate and following low-surrogate pair are advanced together according to JavaScript's Unicode string-index rule.
Patterns are limited to 16 KiB UTF-8, test text to 1 MiB UTF-8, returned matches to 1,000, each value preview to 500 code points, combined returned previews to 100,000 code points, and visual highlighting to the first 50,000 UTF-16 code units. Exact ranges remain available when copied values are shortened.
Input and match contents remain in browser memory and the worker message channel. Success telemetry is deliberately restricted to selected flags, input byte sizes, returned match count, and whether a result or preview limit was reached; raw patterns and text are excluded.
The tool uses the native JavaScript RegExp engine in your browser. Results therefore follow that browser's ECMAScript implementation, including support for lookbehind and named groups only where the browser implements them.
It exposes global g, ignore-case i, multiline m, dot-all s, Unicode u, and sticky y. Match indices use the d capability internally when the browser supports it, without changing which text matches. Unicode Sets v is not advertised by this interface.
Every displayed range is [start, end), measured in UTF-16 code units. This is the same coordinate system used by match.index, RegExp match indices, String.slice(), and most JavaScript string APIs.
A zero-width expression matches a position without consuming text. Global zero-width matching must still advance after each result; with u enabled, this tool advances over a complete surrogate pair so Unicode text cannot trap the loop inside an emoji.
The RegExp is compiled and executed in a dedicated worker. If no result arrives within one second, the page terminates that worker and reports a timeout. This protects the interface, but it is not a proof that the expression is safe under different inputs or runtimes.
The pattern limit is 16 KiB of UTF-8 and the test-text limit is 1 MiB. At most 1,000 matches are returned. Individual copied match and capture previews are capped at 500 code points, the combined returned preview budget is 100,000 code points, and visual highlighting covers the first 50,000 UTF-16 code units.
Pattern compilation and matching happen in the browser worker, and uploaded text files are read locally. Aggregate analytics can record flags, byte counts, returned counts, and limit states, but not the pattern, test text, matched values, or capture contents.
Maintained and tested by SimpleWebUtilsReviewed
Method: To check “Extract ERROR and WARN fields from a copied log”, we used JavaScript Regex Tester with Worker Timeout and Capture Ranges with the guide's exact source data and applied “Establish a minimal flag baseline”. The output had to match the documented result; evidence for “Testing a simplified single line” and “Using g to solve a multiline anchor problem” was reviewed before recording the check.
Expected result: The gm pattern returned two full matches, six numbered captures, four named captures, and no zero-length match; ERROR and WARN were included while INFO stayed out.
Open the tested workflowUse these focused guides when you need a practical workflow before opening the tool.
HTML-to-JSX conversion removes repetitive syntax work, but migration quality depends on what happens afterward. This workflow records the original behavior, limits the conversion to one coherent fragment, compares browser-normalized structure, rewrites legacy events and URLs, moves styles and assets into the destination project, and finishes with lint, type, accessibility, responsive, and security checks. The generated JSX is treated as reviewable source, not as a sanitized or complete component.
Workflow guideHTML-to-Pug conversion removes repetitive tag rewriting, but a dependable migration also needs a source baseline, dependency inventory, active-code redesign, explicit template locals, and tests in the destination application. This workflow converts one coherent view, checks browser normalization and preserved events or URLs, moves page dependencies, adds only the Pug logic the application needs, and verifies the compiled HTML rather than approving a file because its syntax parses.
Workflow guideA multiline regex review needs the original line structure, a known pattern representation, deliberate flags, exact match and capture ranges, and a failing near-match. Run the native expression in an isolated worker, interpret offsets as UTF-16, and verify the final pattern again in the destination runtime before replacement or deployment.
Workflow guideRegex escaping is layered. First identify the source representation, decode only that representation, write the intended raw pattern body, and test it against exact positive and negative text. Then encode the verified body once for the destination JavaScript, JSON, or configuration format instead of adding backslashes by trial and error.
Workflow guideUse this workflow when code viewers, PDFs, transcripts, legal documents, or exported notes add numbers at the start of copied lines. Keep the source, distinguish marked numbering from ambiguous plain integers, compare cleanup evidence, and validate the result before reuse.
Workflow guideUse the explicit Plain gutter format when an IDE, PDF, or documentation viewer copied a leading integer before every stack-trace line. Compare the result with the raw trace, preserve diagnostic values, redact secrets, and only then share it.
Workflow guideText cleanup is safest when it is treated as a sequence of explicit, reversible transformations. Preserve the source, identify line and delimiter boundaries, make one structural change at a time, promote only reviewed output to the next step, and compare the final text with the destination contract before publishing, importing, or sharing it.
Workflow guideA safe bulk-replacement workflow starts with an untouched source and the narrowest matching rule. It proves patterns separately, makes every flag and dollar token explicit, reviews boundary and zero-width diagnostics, compares the exact output, and tests the destination instead of treating a replacement count as correctness.
Continue with another maintained workflow
Convert bases, inspect queries, calculate px/rem, transform escapes, and build commit messages in one local workbench.
Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
Remove line-start numbering while preserving inline values, indentation, and exact line endings.
Number, filter, sort, split, merge, trim, and wrap text locally in one repeatable workspace.
Replace literal or regex matches with Unicode boundaries, capture tokens, exact counts, and Worker limits.