How do I fix "The value is not accepted by the pattern"?

Read the pattern in the message and compare it to the value character by character; the mismatch is usually length or case. Trim values before serializing — trailing whitespace is invisible and fails patterns constantly. Drop ^ and $ from XSD patterns; they are anchored implicitly and the characters are taken literally. If the format genuinely changed, revise the pattern rather than loosening it to .*, which removes the check entirely.

XSD validation error

The value is not accepted by the pattern

The value does not match the regular expression the schema constrains it with — the usual guard on SKUs, references, IBANs and postcodes.

Element 'code': [facet 'pattern'] The value 'widget' is not accepted by the pattern '[A-Z]{2}-\d{4}'. (line 7)

What it means

An xs:pattern restriction is a regular expression the whole value must match end to end. There are no implicit anchors to forget and no partial credit: matching most of the pattern is not matching it.

XSD regular expressions are their own dialect. They are close to Perl's but not identical — no ^ or $ anchors, and \d and character classes behave subtly differently — so a pattern copied from application code may not mean quite the same thing here.

What usually causes it

An identifier format that drifted — a longer numeric part, a lowercase prefix, a different separator.
Whitespace around the value, which xs:string preserves and the pattern then rejects.
A pattern written with ^ and $ anchors, which are literal characters in XSD and match nothing.
A placeholder or test value that does not follow the production format.

How to fix it

Read the pattern in the message and compare it to the value character by character; the mismatch is usually length or case.
Trim values before serializing — trailing whitespace is invisible and fails patterns constantly.
Drop ^ and $ from XSD patterns; they are anchored implicitly and the characters are taken literally.
If the format genuinely changed, revise the pattern rather than loosening it to .*, which removes the check entirely.

The same error elsewhere

libxml2 words these plainly. Xerces numbers them, and those cvc- codes are what most people end up searching for.

Xerces (Java)
cvc-pattern-valid: Value 'widget' is not facet-valid with respect to pattern '[A-Z]{2}-\d{4}' for type 'sku'.
.NET System.Xml
The 'code' element is invalid - The value 'widget' is invalid according to its datatype 'sku' - The Pattern constraint failed.

Before and after

Both documents below are well-formed XML — that is the point. The test suite re-checks them against the real validator on every build: the first is confirmed to produce the exact message above, the second to validate cleanly.

Fails validation

<?xml version="1.0" encoding="UTF-8"?>
<order id="A-1">
  <customer>Ada</customer>
  <issued>2026-01-31</issued>
  <state>open</state>
  <line>
    <code>widget</code>
    <qty>2</qty>
  </line>
</order>

Validates

<?xml version="1.0" encoding="UTF-8"?>
<order id="A-1">
  <customer>Ada</customer>
  <issued>2026-01-31</issued>
  <state>open</state>
  <line>
    <code>AB-1234</code>
    <qty>2</qty>
  </line>
</order>

The schema both are checked against

order.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:simpleType name="status">
    <xs:restriction base="xs:string">
      <xs:enumeration value="open"/>
      <xs:enumeration value="closed"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="sku">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Z]{2}-\d{4}"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="shortLabel">
    <xs:restriction base="xs:string">
      <xs:minLength value="3"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:element name="order">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="customer" type="xs:string"/>
        <xs:element name="middleName" type="xs:string" minOccurs="0"/>
        <xs:element name="nickname" type="shortLabel" minOccurs="0"/>
        <xs:element name="issued" type="xs:date"/>
        <xs:element name="state" type="status"/>
        <xs:element name="line" minOccurs="1" maxOccurs="2">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="code" type="sku"/>
              <xs:element name="qty" type="xs:positiveInteger"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="id" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

Check your own document ← All schema errors

Where this bites most

The terms behind it

Each of these is defined in one sentence and then demonstrated against the parser.

FacetA constraint that narrows a simple type: a length, a range, a regular expression, a list of permitted values.

Other schema errors

Get started

Bring order to the XML your team can't afford to ignore.

Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.

Get started free Sign in