First: decide which file you actually need

This trips up almost everybody, so it is worth thirty seconds. InfoPath splits a form into two files:

  • The template — .xsn. The blank form. It defines what fields exist, what type each one is, and how the form is laid out. One template, reused by everybody.
  • The record — .xml. One file per submission, holding what somebody actually typed. Plain XML, readable in Notepad.

If you are trying to find out what somebody answered, the values are in the .xml files, not the .xsn. The template is what tells you that my:field7 means "Cost centre". You usually want both, and for different reasons.

What is actually inside an .xsn

An .xsn is a Microsoft Cabinet (CAB) archive — the same container format Windows has used for decades — holding a set of open XML parts. Extract one and you will typically find:

  • manifest.xsf — the form definition: solution name, version, the views, the data connections, which files belong to the template.
  • myschema.xsd (or similarly named .xsd files) — the XML Schema. This is the field catalogue: every field's name, its data type, and where it sits in the tree. This is the file that turns my:field7 back into something meaningful.
  • view1.xsl and friends — XSL transforms describing how the form is drawn. The layout lives here.
  • template.xml and sampledata.xml — a blank instance and, sometimes, sample content.
  • Resource files — images, and in some templates a compiled code-behind assembly.

It is compressed, not protected. An .xsn is not encrypted and is not password protected. Extracting one is an ordinary archive operation — no password cracking, no circumvention of any technical protection measure. That is why the data in InfoPath files is recoverable at all, and it is the single most reassuring fact on this page.

Extracting it, free — three routes

On Windows: expand (already installed)

Windows ships with a CAB extractor. From a command prompt, in a folder you are happy to write into:

  • expand MyForm.xsn -F:* C:\temp\myform-extracted

Make the destination folder first. The -F:* says "all members". The older extract.exe from the Cabinet SDK does the same job if you have it. Work on a copy of the template, not your only one.

On macOS or Linux: cabextract

macOS has no built-in CAB extractor, but cabextract is free and does the job:

  • Install it — for example brew install cabextract on macOS, or your distribution's package manager on Linux.
  • Then: cabextract -d myform-extracted MyForm.xsn

Anywhere: a general archive tool

Archive utilities that understand the CAB format — 7-Zip is the usual one on Windows — will open an .xsn directly. If the tool will not accept the extension, copy the file and rename the copy to MyForm.cab; that is often enough to make it offer to open it. Renaming a copy changes nothing about the original.

If InfoPath is still available to you

There is an official route too: inside InfoPath, File → Extract Form Files writes the same parts out to a folder. Worth knowing, but the whole point of this page is what to do when that is not on the table.

Reading what you extracted

Now you have a folder of XML. Here is how to get value out of it without a great deal of ceremony.

Start with the schema

Open the .xsd in a text editor or a browser. Each xs:element gives you a field name and its type. Elements nested inside a repeating group are your repeating sections — a table of line items, for instance. Write yourself a quick map of field name to plain-English label as you go; you will want it when you look at the records.

Then the views

The .xsl files hold the layout, including the visible labels next to each control. If the schema left you guessing what my:field7 was, search the XSL for field7 and the label sitting beside it in the table cell will usually tell you.

You can, in principle, run a record through the view transform with any XSLT processor to render something form-shaped. Be prepared for it to look approximate: InfoPath's views use InfoPath-specific extension attributes that a general processor ignores, so you tend to get readable content with imperfect presentation. Useful; not a faithful reproduction.

Then the records

Open one .xml in a text editor. You will see a processing instruction at the top naming the template, then a tree of elements holding the values. That is your data. If the record refuses to open in InfoPath because it cannot find its template, that is a separate and very common problem with a free fix — see the missing-template guide.

Where the manual route runs out

Everything above is free and entirely legitimate. It is the right answer for one template and a few records, and for satisfying yourself that the data is really still there. It stops being the right answer at a fairly predictable point:

  • Volume. Extract-and-read is per-file work. At a few hundred records it is a bad week; at several thousand it is not a plan.
  • Repeating sections. Flattening nested and repeating groups into a table that a spreadsheet can hold is fiddly, and it is where hand-rolled scripts quietly lose rows.
  • Attachments. A file attached inside a form is stored base64-encoded inside the record with a small binary header. Getting a working .docx back out of that by hand is possible but unpleasant, and easy to get subtly wrong.
  • Evidence. A folder of extracted XML is not an archive an auditor can use. There is no index, no per-record document, and no record of what was and was not recovered.
  • A record that you did not alter anything. Manual extraction leaves no trail showing the originals were untouched. For records under retention or legal hold, that trail is often the point.

What a dedicated reader adds

XSN Rescue is our answer to exactly that list. It parses the CAB and the XML directly — same format facts as above, done at folder scale — and produces the field catalogue from the XSD, every filled-in value from each record with repeating sections disambiguated by indexed field paths, attachments decoded from base64 back into real files, and exports to CSV, JSON and HTML with the template's original XSL views preserved in the HTML rendering. Each run also writes an inventory of every form in the folder and a recovery report saying what happened to each file.

The four things it is built around: it opens your files read-only and records source_modified: false per file so you can check; it leaves an audit trail in the form of that recovery report; it runs entirely on your own machine with nothing uploaded and no account; and it is a one-time purchase, not a subscription for reading your own records.

What it does not do. It recovers the data and the static layout. Code-behind (managed code or script), external data connections and user-role logic are not executed or recovered. 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 regardless. All of that is stated in the recovery report, per file.

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.

The short version

  1. .xsn = CAB archive of open XML. Not encrypted. Extractable with free tools on any platform.
  2. The template holds the fields and layout; the .xml records hold the answers. You usually want both.
  3. expand on Windows, cabextract on macOS or Linux, or any CAB-aware archive tool.
  4. Read the .xsd for field names and types, the .xsl for the human labels.
  5. Copy first, always. Do the work on copies and leave the originals alone.

If that gets you what you need, good — that was the point of writing it out properly.