Free · Fast · Privacy-first

Regex Pattern Generator, Build and Test Patterns Online

Not sure where to start building a regex? FixTools provides ready-made pattern templates for the most common use cases: email addresses, phone numbers, URLs, ISO dates, IP addresses, postal codes, and more.

⚡

Ready-made templates for common patterns

🔒

Editable, customise any template to fit your needs

✨

Test patterns against real input instantly

⚡

Copy final pattern directly into your code

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Regex Tester to your website

Drop the Regex Tester into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Building Correct Regex Patterns from Templates and First Principles

Generating a regex pattern means creating a formal expression that precisely describes a class of strings: neither so broad that it accepts invalid inputs nor so narrow that it rejects valid edge cases you did not anticipate. For common formats like email addresses, phone numbers, and ISO dates, well-tested community patterns exist and serve as far better starting points than writing from scratch. The risk of writing from scratch is that you underspecify the pattern, accepting invalid inputs, or overspecify it, rejecting valid edge cases that did not occur to you during development. Starting from a template verified against a wide range of real-world data and then narrowing it to your specific requirements is both faster and more reliable.

Pattern generation benefits from understanding how the NFA engine evaluates alternatives. When you write a|b, the engine tries a first at the current position; if a fails, it tries b. This ordered evaluation means the sequence of alternatives matters: more specific alternatives should come before less specific ones to prevent the general case from consuming input before the specific case can match. Quantifier selection is equally important: {n,m} sets explicit bounds, + requires at least one occurrence, and ? makes the preceding token optional. Combining these tools with character classes ([a-z], \d, \w), anchors (^, $, \b), and groups lets you precisely describe almost any string format a web application needs to handle.

For practical pattern building, the most reliable workflow is: gather five to ten examples that must match, gather three to five counterexamples that must not, write the simplest pattern that matches all positive examples, then test it against the negative examples. If any negative example also matches, tighten the character classes by narrowing allowed ranges, add explicit anchors, or introduce negative lookaheads. Repeat until the pattern accepts exactly the inputs you intend and rejects all others. This test-driven approach produces patterns with explicit coverage evidence rather than patterns that pass only the single example you were thinking about when you wrote them.

A pattern template library is only as useful as the constraint discipline applied when adapting it. The most common drift is widening: a developer starts from a strict template, finds one valid input it rejects, broadens a character class to fix that case, then never goes back to retighten the pattern after the broader class accepts unintended inputs. Avoid this by re-running the full counterexample set after every widening change. Another frequent mistake is mixing patterns intended for extraction with patterns intended for validation. An extraction pattern omits ^ and $ so it can find substrings; a validation pattern includes them so the whole string must conform. Picking the wrong template type produces patterns that look correct but match nothing in a search context, or match everything in a validation context. Decide which mode you need before opening the template.

MDN Regular Expressions guide PCRE syntax reference

How to use this tool

💡

Select a common pattern template or start from scratch. Edit the pattern to match your specific requirements and test it against sample data before copying it into your project.

How It Works

Step-by-step guide to regex pattern generator, build and test patterns online:

1
Open Regex Tester
Navigate to the FixTools Regex Tester. The tool opens directly in your browser without any installation or account required. The pattern field, flag selector, and test string area are available immediately for entering your pattern and sample data.
2
Choose a starting pattern
Find a pattern template on the Regex Cheatsheet page that covers your format category, such as date, phone, email, or IP address. Copy it into the pattern field as your starting point. If no template closely matches your format, write the simplest literal that matches one example and build from there.
3
Customise the pattern
Edit the template to match your specific requirements. Common adjustments include adding or removing anchors for whole-string versus substring matching, widening or narrowing character class ranges, changing separator characters from one set to another, and adjusting quantifier bounds to reflect the exact lengths your data can take.
4
Test with sample data
Paste representative samples of your real data and verify that all valid inputs produce match highlights and all invalid inputs do not. Include at least three known-good values and three known-bad values that closely resemble valid inputs. Testing with data you do not control, such as real user submissions, reveals edge cases that contrived examples miss.
5
Copy and use
Once the pattern matches all expected inputs and correctly rejects all invalid ones, copy it from the pattern field and paste it directly into your codebase. If your code stores the pattern as a JavaScript string literal rather than a regex literal, remember to double all backslashes: \d becomes \\d inside a quoted string.

Real-world examples

Common situations where this approach makes a real difference:

Generating a date validation pattern for a specific format

A developer needs to validate dates in DD/MM/YYYY format from a form input. Starting from a generic date template that uses hyphens, they adjust the separator character to a forward slash, verify that the day and month range groups correctly use alternation to handle leading zeros for single-digit values, and test the pattern against valid dates like 01/12/2024 and against invalid strings like 32/13/2024 and 1/1/24. The final anchored pattern is production-ready in under five minutes and handles all tested edge cases.

Building a postcode pattern for a specific country

A UK-focused application needs to validate British postcodes across multiple area formats such as SW1A 1AA, M1 1AE, and B1 1BB. The developer starts from a generic alphanumeric template, reviews the UK postcode format specification to understand the positional rules for letters and digits, and progressively constrains the character classes and length bounds until the pattern accepts all documented valid UK area formats and rejects non-UK postal codes. Testing against a set of real postcodes from the Royal Mail open dataset confirms coverage before the pattern is deployed.

Creating a pattern to extract version numbers from release notes

A CI script needs to extract semantic version strings such as 1.2.3 and 10.0.0-beta.1 from release note documents. The developer builds a pattern from the semver specification using \d+ for each numeric component, optional pre-release suffix handling with a non-capturing group, and word boundary anchors to prevent matching version-like digit sequences embedded inside longer numeric strings. Testing against a variety of real release note excerpts confirms the pattern captures version strings correctly without picking up unrelated numbers.

Adapting a community pattern for an internal ID format

An internal system uses a custom identifier format consisting of three uppercase letters, a hyphen, and six digits such as INV-001234. The developer finds a generic alphanumeric ID template, removes the lowercase range from the letter character class, fixes the letter component to exactly three characters using {3}, and adjusts the digit component to exactly six characters. Testing confirms the pattern rejects IDs with wrong segment lengths, lowercase letters, or additional characters, and accepts the full range of valid internal identifiers.

Pro tips

Get better results with these expert suggestions:

Use character classes instead of alternation for single characters

Write [aeiou] rather than (a|e|i|o|u). Character classes are more concise, faster for the engine to evaluate because they are implemented as a simple membership test rather than an ordered branch evaluation, and easier for colleagues to read and extend. Reserve alternation for cases involving multi-character alternatives or structurally different sub-patterns that cannot be expressed as a character range or set.

Test your negative case set as carefully as your positive cases

A pattern that accepts all valid inputs but also accepts some invalid ones is often a more serious problem than a pattern that rejects a few edge-case valid inputs. Build a list of at least three invalid strings that closely resemble valid inputs, such as strings that are one character too short, strings with a wrong separator, or strings with digits where letters are expected. Confirm the pattern rejects all of them before treating the pattern as complete.

Use non-capturing groups for alternation structure

When you need parentheses to group alternatives for quantification but do not need to extract the matched value, use (?:...) instead of (...). A capturing group increments the group index and adds an entry to the match results array even if you never read its value. Keeping capture groups reserved for values you actually need makes match result processing code cleaner and prevents confusion when group indices shift as the pattern evolves.

Pin the complexity to the known constraints of your data

If you know a field is always between 3 and 20 characters, use {3,20} rather than +. If you know a separator is always a hyphen, match a literal hyphen rather than a broad class like [-\s.]. Encoding the actual known constraints of your data into the pattern makes it faster for the engine to evaluate, easier for colleagues to understand during code review, and more likely to catch data quality problems that fall outside expected bounds.

FAQ

Frequently asked questions

Start with the simplest possible match for your target: a literal string if one exists, or a minimal character class and quantifier if the format varies. Confirm the starting pattern matches at least one example. Then progressively replace fixed characters with character classes, add quantifiers, group related tokens, and introduce anchors until your pattern matches all valid inputs and rejects invalid ones. Test after every change so you always have a working baseline to return to. This incremental approach prevents the common situation where a large pattern is written in one go and fails in ways that are hard to trace.

The FixTools Regex Cheatsheet page lists tested patterns for email addresses, phone numbers, URLs, ISO dates, UUIDs, IP addresses, and many other common formats, each with an explanation of the pattern components and a link to open it directly in the tester. The MDN Regular Expressions guide also includes practical examples for common validation tasks. For highly specialised formats like IBAN account numbers or VIN codes, search for the format specification document and build the pattern from the documented structure.

Use ^ and $ when you need to validate an entire string from start to finish: for example, confirming that a form field contains only a valid phone number and nothing else. Omit anchors when you want to search for a pattern anywhere within a longer string: for example, finding all email addresses within a block of text. Using anchors in a search context will cause the pattern to match nothing unless the entire string happens to conform to the pattern, which is a common source of confusion when adapting a validation pattern for an extraction task.

Aim to match the real constraints of your data as precisely as you can determine them. Overly strict patterns reject valid inputs and frustrate users or break pipelines. Overly loose patterns accept invalid data and create downstream problems. Test with a diverse set of valid samples including unusual but legitimate edge cases, and a set of specifically invalid samples including strings that are almost valid. For user-facing form validation, lean slightly toward leniency when the constraint is ambiguous, since a confirmation or downstream validation step can catch edge cases that the regex cannot.

The Regex Tester does not generate patterns from natural language descriptions. Use the Regex Cheatsheet templates as starting points and adapt them to your requirements by modifying character classes, quantifiers, and anchors in the tester. For AI-assisted pattern generation, you can describe your format to a language model and then paste the result into the tester to verify it against real data samples before trusting it. The tester serves as the verification step regardless of how the initial pattern was created.

They are functionally equivalent in ASCII contexts. \w is a shorthand character class that expands to [a-zA-Z0-9_] in standard mode. In JavaScript with the u (unicode) flag enabled, \w still matches only the same ASCII word characters and does not expand to include non-ASCII letters or digits from other scripts. If you need to match Unicode letters from any language script, use the Unicode property escape \p{Letter} with the u flag instead. For matching Unicode digits across scripts, use \p{Decimal_Number}.

Use the * quantifier for zero or more repetitions or the + quantifier for one or more. These quantifiers apply to the immediately preceding token or group. If you want to capture each individual repetition rather than the entire repeated span as a single match, you need to use a loop in your code. In JavaScript, String.prototype.matchAll() with the g flag iterates over all non-overlapping matches in the string, giving you one match object per occurrence. A single regex match object can only record the last value matched by a repeated capturing group, not every value.

Wrap optional single characters in a ? quantifier and optional groups in (?:...)?. For example, to make an international dialing prefix optional in a phone number pattern, write (\+\d{1,3}\s?)? at the start of the pattern. Test the pattern with inputs that include the optional section and inputs that omit it to confirm both cases produce the correct match. Also confirm that making the section optional does not accidentally allow the pattern to match strings that should be rejected because the required sections are absent.

The recurring set across most web applications is: ISO 8601 dates and timestamps, semantic version strings, UUID v4 identifiers, HTTPS URLs, internal ID formats with a letter prefix and digits, base64 strings, hex colour codes, JWT structures with three dot-separated segments, IP addresses (both v4 and v6), and credit card primary account numbers grouped in fours. Each has a battle-tested community pattern that you can adopt as a starting point and customise. Avoid the temptation to write these from scratch every time, because the edge cases (year 2000 leading zero in dates, semver pre-release suffixes, IPv6 compressed notation) are non-obvious and have already been worked out in the canonical templates that thousands of developers have validated.

If your inputs may contain non-ASCII text, enable the u flag and use Unicode property escapes instead of literal ranges. \p{Letter} covers letters from any script; \p{Decimal_Number} covers digits from any script; \p{Script=Greek} covers letters from a specific script. Without the u flag, character classes like [a-z] are confined to ASCII, so user names in Greek, Cyrillic, Arabic, or CJK scripts silently fail to match what looks like a reasonable letter pattern. Test your pattern against representative samples from every script your application supports. If you need to limit input to a specific subset of scripts, combine property escapes with set difference using the v flag: [\p{Letter}--\p{Script=Hebrew}] in a v-flag regex.