What you are actually working with

Each submitted InfoPath form is its own plain .xml file. Inside it is a tree of elements holding the values somebody typed. The .xsn template — a CAB archive of open XML — holds the schema that says what each element means and what type it is. Nothing here is encrypted, which is why every route below is possible at all.

Two consequences worth holding on to:

  • You can extract the values without InfoPath. It is XML.
  • Getting them into a table means deciding how to flatten a tree. That decision is where exports go wrong.

The repeating-section trap, stated up front. A form with a table in it — expense lines, inspection items, attendees — stores that table as a repeating group nested inside the single record. A spreadsheet row is flat. So every export has to choose: one row per record with the repeating values squashed into it, or one row per repeated item with the header fields duplicated. Both are valid. What is not valid is silently overwriting my:item/my:cost with the last occurrence and reporting success. If you take one thing from this page: after any export, open a record you know well and count the line items against the spreadsheet.

Route 1 — InfoPath's own merge and export (free, if you still have it)

If a working InfoPath install is still available, use it while it is. Its merge-forms feature combines many records into one, and you can export a form to Excel from within the application. For simple, flat forms in modest numbers this is the fastest route in existence and it costs nothing.

Where it breaks: it needs the template as well as the records, it needs a machine with InfoPath on it — which is exactly the dependency most people are trying to remove — and merge behaviour on repeating sections depends on how the template was designed. InfoPath reached Microsoft's published end of support on 14 July 2026, so this route gets harder to rely on with every hardware refresh.

Route 2 — Open the XML in Excel (free, no InfoPath needed)

Excel will open an XML file as a table and infer a schema if you do not give it one; with the .xsd from the template you can supply the real one and map fields to columns deliberately. Point it at one record to check the shape, then use Power Query to fold in a whole folder of them.

Where it breaks: repeating sections, as above — Excel's flattening is not always the one you want, and it will not warn you. Namespaces in InfoPath XML can also confuse the schema inference, giving you column names you have to unpick. And attachments come through as an unreadable base64 blob, not as files.

Route 3 — A script (free, technical, and genuinely good)

For a technical team this is often the right answer, and we would rather say so than pretend otherwise. In PowerShell, the shape of it is:

  • Enumerate the .xml files in the folder.
  • Cast each one with [xml](Get-Content -Raw $file).
  • Walk the element tree, collecting leaf values into an ordered dictionary keyed by field path.
  • Emit one object per record and pipe the lot to Export-Csv -NoTypeInformation.

Python with lxml or xml.etree does the same thing just as well. A day of work gets most estates a long way.

Where it breaks: four places, all of them avoidable if you know to look. Repeating sections need indexed paths — my:items/my:item[3]/my:cost — or occurrences collide. XML entities and CDATA sections need decoding or you get & in your data. Records filled in against different versions of the template have different field sets, so you need a union of columns rather than the first record's. And a file that fails to parse must be reported, not skipped — a script that quietly continues past a bad file is how an "export" ends up short of a few hundred records with nobody noticing.

Route 4 — A dedicated reader (what we make)

XSN Rescue is built for the version of this job where the folder is large, the records matter, and nobody wants to maintain a script. It reads the .xsn to build the field catalogue from the XSD — every field's name, type and dotted path — then walks each record and recovers every filled-in leaf value, with entity decoding, CDATA handling, and repeating and nested sections disambiguated by indexed field paths rather than flattened blindly.

Out of a single pass you get the data as a CSV table and as JSON objects (with the field catalogue and solution name and version alongside), a clean HTML rendering with the template's original XSL views preserved, a self-contained archival PDF per record, and attachments decoded from base64 back into real files — a Word or Excel document attached to a form comes out as a .docx or .xlsx you can open, saved beside the record.

It also gives you the two things a spreadsheet cannot give you on its own: an inventory of the whole folder — distinct templates, record counts, and per-field name, type and fill rate, every figure computed from your parsed data — and a recovery report on every run stating what was and was not recovered for each file. Nothing is skipped quietly; a file that would not parse appears in the report with the reason.

What it does not do. Code-behind (managed code or script), external data connections and user-role logic are not executed or recovered — it recovers data and static layout. Digital signatures are surfaced as fields but not cryptographically verified. The archival PDF uses a standard Latin font, so characters outside that set are marked [U+XXXX] and counted; the JSON export preserves the exact text either way. The recovery report says all of this per file rather than leaving you to find out.

Platform. XSN Rescue runs on macOS (10.15 or later, Intel and Apple silicon, one universal download) and on Windows 10 and 11 (64-bit). Both are the same version and the same price — one purchase covers both. There is no Linux build, and we are not giving a date for one; on Linux, the free routes above are your path, and they work.

Which route fits which situation

  • A dozen simple forms, InfoPath still available. Route 1. Do it this afternoon and be done.
  • A few hundred flat forms, no InfoPath, someone comfortable in Excel. Route 2, with a spot-check against a record you know.
  • Any number, a developer available, forms without attachments. Route 3. It is free, it is yours, and it will teach you a lot about your own data.
  • Thousands of records, attachments in them, or an audit that will ask how you know nothing was lost. Route 4 is what we built, and the report is most of the reason.

Whatever you choose, do these four things

  1. Work from copies. Never let an export touch your originals.
  2. Keep the originals. A CSV is a derived work; the .xml records are the evidence. Keep both.
  3. Reconcile the counts. Number of files in, number of rows out, and a manual check of one record with a repeating table. This single step catches nearly every silent loss.
  4. Write down what you did. Which route, which day, which folder, which files failed. In two years, that note is the difference between an archive and a folder of mystery.

If routes 1 to 3 get you there, that is a good outcome. They are free, they are legitimate, and we would rather your records survived than that you bought anything.