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.
<?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>
<?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
<?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:element name="order">
<xs:complexType>
<xs:sequence>
<xs:element name="customer" type="xs:string"/>
<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>
Where this bites most
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.