Skip to content
⚠️ Staging environment, test only, not production
Sign In
Free Tool · No Signup RequiredRuns entirely in your browser

ESX File Validator

Check a Xactimate .esx file, or pasted estimate XML, before you import it. Get a pass/fail verdict with every issue listed: whether the container opens, whether the document inside it parses, and whether its internal references resolve. A file that reads cleanly here is an import-ready starting point; your own licensed copy of Xactimate is still the only final proof of an import.

Free, no signup, and browser-local: the file you check never leaves your machine.

The checks are format-agnostic: the container opens, the document parses, and its internal references resolve. Everything runs in your browser, nothing is uploaded.

Your pasted XML is saved in this browser only, so you can pick up where you left off. An uploaded file is never saved. Nothing is sent to ESXPress. Clear it when you finish on a shared computer.

What the validator checks

A file that opens and a file that gets rejected can look identical until one of them is loaded. The validator reads the properties that decide whether a file reads at all, so a broken file shows up here instead of in the middle of a claim. Here is what it reads:

  • The file itself: an .esx has to open before anything else can be read.
  • The estimate document inside it, so the reader finds something to read.
  • The document parses as well-formed XML, with no broken markup.
  • Internal references resolve, so every link inside the file points at something the file defines.
  • Ids are unambiguous, so a reference cannot point at two different things at once.

Why some files come back rejected

The most common blocking defect on import is a SEL code carrying a character that Xactimate project files do not allow. Codes are built from A through Z, a through z, 0 through 9, and the four separators #, +, ., and /. When catalog data gets corrupted, an entity character can leak in, and a code like APP|CKIT> or RFG|ARMV>> comes back as "Invalid file format" on import with no clue which line is at fault. That defect lives in the file the producing tool wrote, and the tool that wrote the file is the one that can find it line by line.

A file is rejected before it is read

A file that imports cleanly carries no fixed pricing block of its own. Xactimate prices the file from its own list when it opens, so a totals block written by the producing tool is not something the platform trusts, and certain shapes it does not expect are rejected for the same reason. A converter that writes those blocks hands you a file that fails on import for a reason that has nothing to do with the estimate. Check the file you were handed before it costs you a review cycle; always confirm the money in your own licensed copy before you submit.

Browser-local by design

Validation runs in your browser. The file is not uploaded to ESXPress, and there is no signup and no conversion quota attached to the tool. That is deliberate: the validator is for checking a file you already have, and a file you already have should not have to leave your machine to get a verdict.

Validate first, then reprice

Structural checking and repricing answer different questions. Check the file when you want to know whether it opens and reads cleanly. Read the pricing explainer when the file imports cleanly but the totals move, because that is Xactimate pricing the lines against the list loaded on your machine rather than a defect in the file.

Where to go next

Frequently Asked Questions

What does the ESX validator check?
For .esx uploads it checks the file itself: whether it opens, and whether it carries a readable XML document. For pasted estimate XML it checks that the document parses, that every internal reference resolves to an id the document defines, and that no id is defined twice. It does not read your pricing.
Why does Xactimate reject some ESX files as 'Invalid file format'?
Xactimate rejects ESX files whose SEL codes contain characters outside the charset Xactimate project files use (A-Z a-z 0-9 # + . / -). When catalog data gets corrupted, entity characters can leak into codes, for example APP|CKIT> or RFG|ARMV>>. That is a defect in the file the producing tool wrote, and it is worth checking with the tool that produced it, or in your licensed copy of Xactimate, before you send the file on.
Does the validator check totals in the file?
It does not read your pricing. Xactimate prices the file from its own list when it opens, so the totals you see after import are computed by Xactimate, not by the file. The validator checks that the file opens and that the document structure reads cleanly. Always confirm the money in your own licensed copy before you submit.
Should I run the validator or the reprice check?
They answer different questions. The validator checks a file before you import it: does it open, and does the document inside it read cleanly. The reprice check is about pricing behavior after import: why the same code can total differently by region and price month. Validate first, then read the reprice check when the numbers move.
Can the validator open my .esx file?
No. The validator runs entirely in your browser and checks the file's structure without unpacking the estimate itself. For a deeper check, open the file with your own tooling and paste the document XML, or paste plain XML from tools that export readable XML.
Is the ESX validator free?
Yes. It is a free tool from ESXPress with no signup and no conversion quota. Validation runs entirely in your browser, so your file never leaves your machine.
What is an ESX file?
An ESX file is Xactimate's native project file format: it holds the full estimate, including line items, groups and folders, line codes, quantities, prices, notes, and metadata. Import it into Xactimate and it reprices against the loaded price list.

Want a full PDF scope converted, not just checked?

Drop the whole carrier PDF in ESXPress and get an import-ready .esx in about two minutes, with every line item checked against the SEL dictionary and 1,000+ line items per scope. Always verify the output in your own environment before submission.