What an .xsn file actually is

This is the part that should put your mind at ease. An InfoPath .xsn is not a mysterious proprietary blob. It’s a Microsoft Cabinet (CAB) archive that bundles a handful of ordinary, open files:

  • manifest.xsf — the form definition: solution name, version, and how the pieces fit together.
  • One or more .xsd schema files — the field catalogue: every field’s name, data type and its path in the form.
  • One or more .xsl transforms — the views that lay the form out on screen.
  • Sometimes sample/default data and other resources.

And the records people filled in? Those are separate form-data .xml files — plain XML. There’s no encryption and no proprietary binary format to defeat. That’s why recovery is a matter of careful parsing, not code-breaking.

A note on protection, so it’s clear: because InfoPath forms aren’t encrypted, getting your data out is never “cracking” anything. It’s reading files you already own and have every right to access. No passwords are broken and no technical protection is circumvented — there’s simply nothing of that kind in the way.

The three things you might want to recover

  1. The field catalogue — what questions the form asked (from the .xsd).
  2. The filled-in values — what people answered (from the form-data .xml).
  3. The layout — how it looked (from the .xsl views).

For most people the middle one — the answers — is what really matters for audit and retention. The others make the answers easier to read and trust.

Free ways to export it yourself

Unpack the CAB and read the parts

On Windows you can expand a CAB with the built-in expand command, or use a tool like 7-Zip. Rename a copy of the .xsn to .cab if your extractor needs the extension, unpack it, and you’ll see the .xsf, .xsd and .xsl members. Open them in any text or XML editor. This shows you the form’s structure for free.

Read the form-data XML directly

A filled-in form-data .xml opens in any text editor. The field values are right there as XML elements. For a few records that’s genuinely all you need. The catches at scale: repeating and nested sections make the paths fiddly, entities and CDATA need careful handling, and turning a pile of XML into a clean table by hand is slow.

Export from InfoPath while it still runs

If InfoPath still works on a machine, you can open forms and export data through the app. Free and accurate — but it depends on the app that’s being retired, which is exactly the dependency you’re trying to remove.

Letting a tool do the careful version

XSN Rescue does the same reading, but properly and at scale, entirely on your own computer:

  • Unpacks the .xsn CAB and reads the manifest.xsf (solution name + version), the .xsd (field catalogue: name, type, dotted path) and the .xsl views.
  • Walks a form-data .xml and recovers every filled-in leaf value — with entity decoding, CDATA handling, and repeating/nested sections disambiguated by indexed field paths.
  • Exports every record to a CSV table, JSON, an archival PDF per record (values plus the field catalogue and solution name/version), and a clean HTML rendering — a readable table of every recovered field and its value, with the template’s original XSL views preserved alongside it.
  • Writes an honest recovery report every run: what was and wasn’t recovered, integrity notes, and a read-only check (source_modified: false) recorded per file. Files are classified by content, so even a mislabelled .xsn or .xml is handled correctly.

What it doesn’t do — stated plainly. It recovers data and static layout, not live behaviour: form code-behind (managed code/script), external data connections and user-role logic are not executed or recovered. Digital signatures are surfaced as fields but not cryptographically verified. File attachments stored in InfoPath’s documented base64 envelope are decoded back to real files (original name, hash-verified) in an attachments folder; embedded base64 that is not a decodable attachment envelope is preserved verbatim in the data export and marked as such — never guessed. XSN Rescue does not execute the template’s XSL, script or ActiveX behaviours — it lays the recovered fields out itself, so complex view logic is deliberately not reproduced — but the recovered data table is always faithful, and the report says exactly what happened.

Which route should you pick?

  • A few forms, one-off: the free manual methods are fine — start there.
  • Hundreds or thousands of records, or you need it auditable: a tool that recovers every value consistently and writes a report per file will save days and stand up better in an audit.
  • You need a hand-over archive (PDF per record + inventory): that’s the archive output — covered in our archiving guide.

Whatever you choose, the encouraging headline stands: your InfoPath data is on open standards, and it can be recovered. Do it while extracting is still easy.