Email Format Validation with JSON Schema

Q: What does this JSON Schema validate?

## Email Validation with the format Keyword JSON Schema includes a format keyword that can validate common string formats, including email addresses. The "email" format checks compliance with RFC 5321, the standard that governs SMTP mailbox addresses. ### Basic Email Schema json { "type": "string", "format": "email" } This validates that the string follows the local-part@domain structure defined by RFC 5321. It accepts addresses like user@example.com, first.last@sub.domain.org, and user

Validate email addresses in JSON Schema using the format keyword. Understand format assertion behavior, fallback patterns, and RFC 5321 compliance.

String Constraints

JSON Schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "format": "email",
      "maxLength": 254
    },
    "backupEmail": {
      "type": "string",
      "format": "email"
    }
  },
  "required": ["email"]
}

Test Data

{
  "email": "alice@example.com",
  "backupEmail": "alice.backup+tag@mail.example.org"
}

Detailed Explanation

Email Validation with the format Keyword

JSON Schema includes a format keyword that can validate common string formats, including email addresses. The "email" format checks compliance with RFC 5321, the standard that governs SMTP mailbox addresses.

Basic Email Schema

{
  "type": "string",
  "format": "email"
}

This validates that the string follows the local-part@domain structure defined by RFC 5321. It accepts addresses like user@example.com, first.last@sub.domain.org, and user+tag@example.com.

Format Assertion Behavior

An important nuance: by default in Draft 2020-12, the format keyword is an annotation only — it does not cause validation to fail. To enable format validation, the validator must be configured with formatAssertions: true or you must use the format-assertion vocabulary.

If you cannot guarantee format assertions are enabled, add a pattern as a fallback:

{
  "type": "string",
  "format": "email",
  "pattern": "^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$",
  "maxLength": 254
}

The pattern provides basic structural validation even when format assertions are disabled.

How the Example Schema Works

The schema validates a contact form with a primary and optional backup email:

email is required and must be a valid email with at most 254 characters (the maximum length for an email address per RFC 5321).
backupEmail is optional. When present, it must also be a valid email.

The test data passes because both "alice@example.com" and "alice.backup+tag@mail.example.org" are well-formed email addresses.

What format: "email" Does NOT Check

It does not verify the domain has MX records.
It does not send a confirmation email.
It does not check if the mailbox actually exists.
Some validators may accept technically valid but unusual addresses like "quoted string"@example.com.

idn-email Format

For internationalized email addresses (with non-ASCII characters in the domain), use "format": "idn-email" instead. This validates against RFC 6531 and accepts domains with Unicode characters like user@例え.jp.

Use Case

Use email format validation in user registration endpoints, contact forms, newsletter subscription APIs, and any schema where an email address is collected. Combine with maxLength: 254 and a pattern fallback for maximum interoperability across validators.

Try It — JSON Schema Validator

Open full tool →