JSON Regex Generator

About This Tool

The generator reads each field of a JSON object, infers what kind of value it holds, and emits an anchored regex for it. The output is ECMA 262 — the dialect JSON Schema's pattern keyword uses — so patterns paste straight into a schema or into JavaScript. Everything runs in your browser; no JSON is sent to a server. Free, no account required.

What the JSON Regex Generator Does

Give it one JSON object and it returns a field-by-field map of regex patterns — the tedious half of writing a JSON Schema by hand.

One Pattern per Field

Paste a sample object — typically one representative API response — and each key comes back with its own pattern. A value like "user@example.com" is recognised as an email and gets the email pattern; "2024-01-01" gets an ISO 8601 date pattern; numbers get ^\\d+$ or a decimal pattern; booleans get ^(true|false)$. Recognised formats are email, phone, URL and ISO date.

Strict Mode for Unrecognised Strings

When a string matches none of the known formats, the default output is a permissive length range. Tick Strict mode and you get an escaped exact-value match instead — useful for enum-like fields such as status codes or currency symbols, where the set of valid values is fixed. The generator reads top-level keys, so flatten or run nested objects separately.

Reference Patterns You Can Copy

For field types the generator cannot infer from a single sample — UUID, semantic version, hex colour, Base64, URL-safe slug — the pattern reference table further down this page lists tested, anchored regexes to copy by hand.

Using Regex in JSON Schema

Generated patterns integrate directly into JSON Schema validation via the pattern keyword.

The pattern Keyword

Add "pattern": "your-regex-here" to any string type field in your JSON Schema. The value must match the regex (using ECMA 262 dialect) for the schema validation to pass. The pattern must match the complete string, not just a substring.

Testing Your Patterns

Always test regex patterns against both valid examples (which should match) and invalid examples (which should not) before deploying. Edge cases like empty strings, unicode characters, and boundary values often reveal pattern issues.

Ready-to-Use Regex Patterns for Common JSON Fields

Copy these tested regex patterns directly into your JSON Schema pattern keyword. All patterns use ECMA 262 regex dialect, compatible with JSON Schema validators and JavaScript.

Complete JSON Schema Example with Regex Validation

Here is a real-world JSON Schema that uses pattern to validate multiple fields in a user registration object. Copy and adapt it for your own API.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "User Registration",
  "type": "object",
  "required": [
    "email",
    "username",
    "birthDate"
  ],
  "properties": {
    "email": {
      "type": "string",
      "pattern": "^[a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,}$",
      "description": "Valid email address"
    },
    "username": {
      "type": "string",
      "pattern": "^[a-z0-9_]{3,20}$",
      "description": "3-20 lowercase alphanumeric characters or underscores"
    },
    "birthDate": {
      "type": "string",
      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      "description": "ISO 8601 date (YYYY-MM-DD)"
    },
    "website": {
      "type": "string",
      "pattern": "^https?://.+",
      "description": "Optional URL starting with http or https"
    },
    "phoneNumber": {
      "type": "string",
      "pattern": "^\\+[1-9]\\d{1,14}$",
      "description": "E.164 international phone number"
    }
  }
}

Key Rules When Using pattern in JSON Schema

• The pattern keyword uses ECMA 262 regex (same as JavaScript). Avoid PCRE-only features like lookbehind assertions.
• Patterns are not anchored by default — a pattern of \d{4} will match "hello1234world". Always anchor with ^ and $ to require a full match.
• Backslashes in JSON strings must be double-escaped: write \\d in JSON to represent the regex \d.
• The pattern keyword only applies to values of type string. It is ignored for other types.
• Always test your pattern against at least 5 valid and 5 invalid examples before using in production.

Regex in JSON vs Regex in JSON Schema

JSON has no regular expression type. Its six value types are string, number, object, array, boolean and null, so a regex can only ever live in a JSON document as an ordinary string. Nothing in the JSON specification will match it against anything.

Matching happens one layer up, and there are only two places it can happen:

• In JSON Schema, through the pattern, patternProperties and propertyNames keywords. The validator applies the regex for you at validation time.
• In your own code, after parsing — JSON.parse then test the field, or query with a path expression first. Running a regex over the raw JSON text instead is the classic mistake: whitespace, key order, unicode escapes and nesting all vary without changing the data, so text-level patterns break on valid input.

So a search for “JSON regex” almost always resolves to one of these two, and in practice usually the first.

Matching JSON Keys with Regex, Not Just Values

The pattern keyword only ever looks at a string value. When the key names themselves are dynamic — feature flags, locale codes, tenant IDs, metric names — you need two different keywords.

patternProperties

Applies a subschema to every property whose name matches the regex. Here any key shaped like a locale code must hold a non-empty string, and additionalProperties: false rejects keys that match nothing:

{
  "type": "object",
  "patternProperties": {
    "^[a-z]{2}(-[A-Z]{2})?$": { "type": "string", "minLength": 1 }
  },
  "additionalProperties": false
}

That accepts {"en": "Hello", "en-GB": "Hello"} and rejects {"english": "Hello"}. Note that patternProperties regexes are deliberately unanchored in the same way as pattern, and a key matching two of them must satisfy both subschemas.

propertyNames

Constrains the key names without saying anything about the values — useful for enforcing a naming convention across a whole object:

{
  "type": "object",
  "propertyNames": { "pattern": "^[a-z][a-zA-Z0-9]*$" }
}

Every key is validated as if it were a string against that subschema, so this object rejects snake_case and PascalCase keys while allowing camelCase.

Why a JSON Schema Pattern Silently Fails

Four failure modes account for nearly every “my pattern does not work” report, and none of them raise an error — the validator simply passes data it should have rejected.

Once a pattern is in place, run real payloads through the JSON Schema validator — or a whole directory of them through the batch validator — to confirm it rejects what it should.