# Using the validator Source: https://xmlvalid.com/docs > Everything the validator does, what it can't do, and how to read its results. Not sure what a message means? See [XML error messages explained](https://xmlvalid.com/errors) and [business rules explained](https://xmlvalid.com/rules). Validating from scripts or CI? See [CI and the command line](https://xmlvalid.com/docs/ci) and the [API reference](https://xmlvalid.com/docs/api). ## Quick start - Open the [validator](https://xmlvalid.com/validate) and paste a document, drop a file, or fetch one by URL. - Optionally expand **Validate against a schema** and add an XSD, DTD or RelaxNG schema. - Press **Validate**, or ⌘ ↵ / Ctrl ↵. Without a schema the document is only checked for well-formedness: matching tags, quoted attributes, a single root element, valid characters and so on. ## Opening documents **Paste** Type or paste into the editor. Problems are marked in the gutter, and clicking an error jumps to its line. **Upload** Drop a file or choose one. Files up to 5 MB open in the editor; larger files are streamed from disk without being displayed, so a 1 GB document doesn't freeze the page. **Several documents** Choose several files, a folder or a `.zip` archive on the **Upload** tab, up to 1,000 documents. They are validated one after another against the same schema, still in your browser, and listed with their outcome and first problem; click one to see up to 100 of its problems. The list can be exported as CSV or JSON, or as a report (below). From a folder or an archive, only files with XML extensions (`.xml`, `.atom`, `.gpx`, `.svg`…) and PDF invoices are taken; with no schema chosen, each PDF invoice is checked against the profile it names. **An EPUB book** An `.epub` on the **Upload** tab is checked file by file, each against its own schema from the catalog: `META-INF/container.xml`, the package document (EPUB 3 with epubcheck's Schematron rules, or EPUB 2), the NCX, and the XHTML, SVG and SMIL files of the manifest for well-formedness. The `mimetype` file and manifest entries missing from the archive are reported too. It is no replacement for epubcheck: CSS, fonts, links between files, media types and the content rules of XHTML are not checked. **A PDF invoice** A Factur-X, ZUGFeRD or XRechnung PDF on the **Upload** tab opens the XML invoice attached to it (`factur-x.xml`, `zugferd-invoice.xml`, `xrechnung.xml`), taken out in your browser, and picks the catalog profile its specification identifier (BT-24) names, unless you set a schema of your own. An invoice that states a French billing mode (BT-23, such as S1 or B1) gets the French profile for its syntax instead, which adds the French e-invoicing rules. An e-invoice opened as an XML file, uploaded or by URL, gets its catalog profile the same way (and by its document element and namespace for national formats such as FatturaPA, KSeF or CFDI), unless you chose a schema; a note above the editor says which. The PDF around it is checked against what Factur-X and ZUGFeRD ask: the attachment's name, relationship and MIME type, its place in the catalog's `/AF`, and XMP metadata that declares PDF/A-3 and names the attachment and the same profile; these findings are listed as `PDF-…` at the document level. Full PDF/A conformance (fonts, colour profiles, structure) is not checked: use a PDF/A validator such as veraPDF. Encrypted PDFs, PDFs over 100 MB and ZUGFeRD 1.0 are not supported. The [API](https://xmlvalid.com/docs/api) takes the PDF as well, uploaded, inside a `.zip` or by URL, and so do URL monitors. **URL** Most servers don't allow other sites to download their files directly, so the document is relayed through our server (it isn't stored) and then validated in your browser. Only public `http://` and `https://` addresses on standard ports work. UTF-8, UTF-16 and the ISO-8859 family are read directly. Other encodings your browser knows (windows-1251, windows-1252, KOI8-R, Shift\_JIS, GBK and so on) are converted to UTF-8 on the fly as the file streams through, which is somewhat slower; line numbers stay the same. Compressed (`.gz`) files need to be unpacked first. ## Schemas There is no type to choose: the language is recognised from the schema itself: an XSD by its `xs:schema` root, RelaxNG by its namespace (or, for the compact syntax, by its declarations and definitions), a DTD by its declarations. **XSD** W3C XML Schema 1.0. XSD 1.1 is not supported: when a schema uses it (assertions, type alternatives, open content, `xs:override`, its new built-in types, or `vc:minVersion="1.1"`), the result says so and lists where. **DTD** An external DTD file, applied to the document as if it were declared in its DOCTYPE. **RNG** RelaxNG in the XML syntax (`.rng`) or the compact syntax (`.rnc`). A compact schema, and any `.rnc` files it includes, is translated to the XML syntax in your browser before validation; annotations and Schematron rules embedded in it are ignored. **DOCTYPE** The **DOCTYPE** tab validates against the DTD declared inside the document itself (its internal subset). ### The schema catalog The [catalog](https://xmlvalid.com/schemas) has official schemas ready to use (e-invoices from UBL and CII to Factur-X, KSeF, CFDI and NF-e, Peppol ordering, ISO 20022 payment messages, HL7 CDA and FHIR, tax audit files, sitemaps, developer formats such as Maven, Jakarta EE and SAML, and publishing formats such as DocBook, DITA, JATS and TEI) with all their include files. Choose one on the **Catalog** tab of the schema panel, or open its page and press **Validate with this schema**. Each page also says what the schema does not check. ### Business rules (Schematron) E-invoices have to pass more than their schema: EN 16931 and the formats built on it add business rules (mandatory fields, code lists, totals that add up) written in Schematron. The catalog's EN 16931, Peppol BIS Billing 3.0, XRechnung and Factur-X entries run those rules (so do the EPUB package entries, with epubcheck's rules) after the schema check, in your browser, with the rule files as their publishers release them. Each finding names its rule, such as `BR-CO-15`, and the line of the element it points at; the rule's id links to [its page](https://xmlvalid.com/rules), with what it checks and, for the common ones, how to fix it. The rules run only when the document matches the schema, as in the KoSIT validator, and only on documents up to 50 MB, since they need the whole document in memory; a note says when they were left out. Your own rules go under **Business rules (Schematron)**, with or without a schema: an ISO Schematron file, with the files it includes (choose them together, or their folder), up to 1 MB, query binding `xslt2` or `xslt3` (XPath 1.0 rules usually work as well). A browser can run Schematron but not compile it, so the `.sch` file is compiled on our server and the compiled rules are kept for a week; the document is still checked in your browser. Includes (`sch:include`, `sch:extends`, `xsl:include`) must point at files you chose; compile-time XSLT (`use-when`, static parameters) is not supported. Through the [API](https://xmlvalid.com/docs/api) and the command-line client the same rules go as `rules_file` or `--rules` (the client finds the files a schema includes and sends them along). On Pro, rules you use all the time can be kept with a [saved schema](https://xmlvalid.com/dashboard/schemas): they then run wherever it is used, in the validator, the API and URL monitors. ### Schemas that span several files When a schema uses `xs:include`, `xs:import`, `xs:redefine` or RelaxNG's `include`/`externalRef` (`include`/`external` in the compact syntax), choose all of its files at once on the **Upload** tab and mark the entry point as **main**. Files chosen together sit side by side, so references such as `schemaLocation="common.xsd"` resolve by file name. If the schema refers to other folders (`../common/types.xsd`), choose the whole folder instead: its layout is kept and relative paths resolve as they do on disk. **No network access** The validator never downloads anything a schema or document refers to. A `schemaLocation` pointing at an http(s) URL won't be fetched; upload that file alongside the others instead. ## Reading results Each problem has a position, a level and the parser's message: **fatal** The document is not well-formed. The parser recovers and keeps going, so every such error is listed, but schema rules are not checked after the first one: the structure past that point is a guess. **error** The document is well-formed but breaks the schema. Validation continues, so every error is found. **warning** Something worth knowing that doesn't make the document invalid. The line is always given; the column is shown when the parser reports one (XML Schema errors only carry a line). Up to 1,000 errors and 1,000 warnings are listed in full, and all of them are counted. **Report** downloads the result as a single HTML page to send to a colleague or a supplier: the verdict, the schema, and every listed problem with its line, the business rule's page and the explanation of the message. Open it and use **Save as PDF** for a PDF. It is made in your browser, like the result itself. On the [Pro plan](https://xmlvalid.com/pricing), **Share link** stores the same report on our server and gives you a link anyone can open for 30 days, so there is no file to attach. The report holds the verdict and the findings, whose messages can quote values from the document; the document itself is not uploaded. Your links are listed, and can be deleted, under **Report links** in the dashboard. **Export JSON** downloads the result: the document and schema names, statistics, and every listed problem with its `line`, `column`, `level`, `type`, `code` and `message`. ## Limits - Without an account: documents up to **50 MB**. - With a free account: up to **1 GB**. - Memory use stays around 20 MB whatever the size, so large files work on ordinary laptops. How fast it goes depends on the machine, the schema and how dense the markup is; on a recent laptop a 1 GB file takes seconds rather than minutes. - Fetching by URL is limited to 30 downloads a minute. ## Privacy Files you open or paste are validated by a WebAssembly build of our engine inside your browser tab, and are not sent to us. Documents fetched by URL pass through our server on the way to your browser and aren't kept. Details are in the [privacy policy](https://xmlvalid.com/privacy-policy). ## FAQ ### Why are there no schema errors after a fatal one? A *fatal* error means the document isn't well-formed XML. The validator keeps reading and lists the other well-formedness errors, but once the structure is broken it can only guess what was meant, so schema errors past that point would be noise. Fix the fatal errors and validate again to see them. ### My document is valid in another tool but not here The engine is built on libxml2, which is used by a great many XML toolchains. If results still differ, send the smallest document and schema that show it to . ### Which browsers are supported? Any current version of Chrome, Edge, Firefox or Safari. The validator needs JavaScript and WebAssembly.