What this does
Turns a literal string into a fragment safe to drop into a regular expression pattern without any of its characters being interpreted as regex syntax. If you're building a pattern that needs to match a user-supplied string exactly — a filename, a search term someone typed, anything you don't control — the raw text can't go straight into new RegExp(text): a period matches any character, parentheses start a group, and so on. Escaping neutralizes that.
Two modes, because there are genuinely two different answers
Standard escapes only the 13 characters that actually have syntactic meaning in a regex — ^ $ \ . * + ? ( ) [ ] { } | and the / delimiter. This is the compact, readable output most developers expect, and it matches what Python's re.escape(), PHP's preg_quote(), and most other languages' equivalents produce.
Native reproduces the exact algorithm behind JavaScript's built-in RegExp.escape(), added in ES2026. It's deliberately more aggressive: every punctuator gets escaped, not just regex syntax characters, and the very first character gets a \x escape if it's a digit or ASCII letter. Both exist specifically to prevent a "context escape" — the output accidentally combining with whatever text surrounds it into something that means more than the literal string did. It produces uglier output for exactly that reason. If you need to know precisely what the native method would return — to verify a polyfill, or to match its output exactly in an environment that doesn't have it yet — this mode reproduces it verified against the documented examples.
The verification badge
After escaping, this tool wraps the result in a real RegExp and checks that it matches the original text exactly — not a manual claim, an actual regex compiled and run against your input every time. If that check ever fails, something is wrong with the escaping, not with your input.
FAQ
Do I need this if RegExp.escape() already exists?
Only if your code runs somewhere that doesn't have it yet, or you want the more compact Standard output instead of the intentionally noisier native format. RegExp.escape() shipped in Chrome, Firefox, and Safari in early 2025 and is part of ES2026, but older runtimes and non-JavaScript contexts (a config file, a pattern going into another language) still need this done another way.
Why does the native mode escape so much more than the standard mode?
It's guarding against a broader failure mode than "does this string mean something as regex syntax" — it's guarding against the escaped string combining with code around it in a way its author didn't intend, even when no individual character in the source string was a regex metacharacter. See the TC39 proposal for the full reasoning.
What about escaping a string for a JSON, JavaScript, or SQL string literal instead?
That's a different job — Text Escape handles quotes, backslashes, and control characters for those three specifically. Regex escaping and string-literal escaping solve unrelated problems and neither substitutes for the other; a string that's safe inside a JSON string can still contain regex metacharacters, and vice versa.
Try it yourself
Once you have an escaped fragment, Regex Tester lets you drop it into a full pattern and test it against real text, and Regex Builder helps construct the rest of the pattern around it. Both run entirely in your browser. See How to Escape Special Characters in Regex for the worked example this tool is built around, or String Escaping Explained for how regex escaping relates to escaping for JSON, JavaScript, SQL, and HTML.