Ask an estimator what happens to their scope PDF after they drop it into a conversion tool and you get a shrug. That shrug is expensive, because scope files carry the full picture of a claim: names, policy numbers, addresses, and the itemized damage a carrier has already accepted. This article walks both paths in ESXPress and what each path does with your data, and the honest difference between the two.
There are two paths, and they are not the same
ESXPress ships two distinct ways to work with a scope. The browser ESX validator runs entirely in your browser. You upload an .esx file or paste estimate XML, and the checks execute on your machine; the page states it plainly: no signup, no quota, no upload to server, and your data stays on your machine. The free tools, including the repricing checker, are built on the same principle.
The full conversion, the one that rebuilds the project tree and unlocks the completeness review, is a different animal. That job needs the matching dictionary and the completeness engine, so the PDF is processed by the application rather than by your browser. Uploaded source PDFs are stored on the application server's disk, and the PostgreSQL database hosting account and conversion metadata runs on Supabase.
Knowing which path you are on is the difference between a zero-upload workflow and a server-processed one. Nothing in this article is about hiding that; it is about state it precisely.
What the server path has around your data
Every connection is TLS 1.2 or 1.3, with TLS 1.0 and 1.1 disabled at the origin and HSTS enabled including subdomains. Passwords are bcrypt-hashed with cost factor 12 so they are never stored in plaintext, never logged, and never sent without encryption. Session auth uses JWT signed with HS256, lives only in browser storage, and rides in an Authorization header. All state-changing endpoints require a per-session CSRF token validated server-side, and a Content Security Policy limits what scripts the page can run. Anonymous API traffic is rate limited at 60 requests per minute.
On the storage side, ESX output files use the ESX container format's standard wrapping, which is required for Xactimate import compatibility. That wrapping is a format requirement, not an additional at-rest control; the security page says so in so many words. W-9 tax identifiers are separately encrypted at rest with Fernet (AES-128-CBC) using a key held in environment configuration. Database storage encryption is handled at the Supabase layer.
PII versus files, and the question everyone asks
Privacy comparisons in this space tend to collapse into one claim: whose server touches the PDF. Competitor Antero Trail markets itself on tokenizing PII before any AI sees it, hosted on SOC 2 certified infrastructure. That is a legitimate framing and a real control, because it means names and policy numbers are scrubbed before parsing, not after.
ESXPress takes a different road. The validator path never uploads anything at all, which makes the PII question moot for that tool. The conversion path keeps documents on servers with documented controls, and the security page maps controls to SOC 2 trust criteria like data confidentiality and change management, with a public list of sub-processors for the DPA. There is no universal right answer, only the question of what your firm needs: max control over files in transit, or a documented server-side chain.
What the validator checks while it stays local
The browser validator is not a thin wrapper. It checks required sections of the document, CAT|SEL code shape, SEL codes that break Xactimate import, and line-item structural rules against the built-in code dictionary. No signup, no quota, no upload to server, so you can run a file through it at 2 AM on a customer's machine and the file never leaves that machine.
Data rights and the paper trail
Payments route through Stripe, which maintains Binding Corporate Rules and Standard Contractual Clauses for international transfers. The site defaults to privacy-respecting analytics (Plausible) and Google Analytics only after consent with consent mode denied by default; no behavioral advertising. Users can export, correct, or delete their data at any time through the Dashboard or by emailing hello@esxpress.org, and data subject requests are answered within 30 days. A Data Processing Agreement covering processor role, sub-processor disclosures, and data subject handling is available on request for enterprise customers. The privacy policy, terms, DPA, and vulnerability disclosure are all published, and hello@esxpress.org has a PGP key (fingerprint 9901 2E5D 9661 CFF4 F816 AA41 0C76 E4C5 5B5E F4D0) for encrypted reports.
The decision rule
If the question is "can I check this file without it leaving this computer," the answer is yes and the tool is the validator. If the question is "what does a full conversion do with my customer data," the answer is documented on the security, privacy, and DPA pages, with sub-processors named. Read both sides of that line before you hand a carrier scope to any tool, including this one.
Related: PDF to ESX conversion.