The one-sentence explanation

InfoPath separates the form from the answers. The .xsn template holds the fields and the layout; each submission is a separate plain .xml file holding only the values. To show you a form, InfoPath has to fetch both — and the record tells it where to find the template. If it cannot fetch the template, there is nothing to draw, so you get raw XML in a browser or an error in InfoPath.

Read this before you worry. Everything anybody typed into that form is inside the record's own XML. Losing the template costs you the layout and the friendly field labels. It does not cost you the data. Nothing needs to be recovered from a backup and nothing has been corrupted — a pointer has gone stale, which is a much smaller problem than it looks.

Find the pointer — it is the first line or two of the file

Open a copy of the record in Notepad, TextEdit, or any code editor. At the very top, before the data, you will find processing instructions along these lines:

  • <?mso-infoPathSolution ... href="..." name="urn:schemas-microsoft-com:office:infopath:..." solutionVersion="..." productVersion="..." ?>
  • <?mso-application progid="InfoPath.Document"?>

Three attributes are doing the work:

  • href — where the template was when this record was saved. A SharePoint URL, a UNC path, or a local file path.
  • name — the solution identifier. This is the stable one. It stays the same across copies of the same template, so it is what you should match on when hunting for the right .xsn across share drives.
  • solutionVersion — which version of the template this record was filled in against. Useful when a form was revised and fields were added over the years.

Look at the href. If it names a site, a server or a drive letter that no longer exists, you have found your cause and you can stop troubleshooting InfoPath.

The free fix: point the record at a template you can reach

If you can still lay hands on the .xsn — in a document library, a backup, a developer's folder, or an old project share — this takes minutes.

  1. Copy everything first. Work on copies of the records in a scratch folder. Never edit an original, and never edit anything at all if the records are under legal hold or a retention policy without asking the person who owns that policy.
  2. Put the template somewhere stable and simple, for example C:\forms\Expenses.xsn.
  3. Edit the href in your copied record to point at it — a file:///C:/forms/Expenses.xsn-style path, or a UNC path everybody can reach. Change nothing else.
  4. Clear the InfoPath template cache before you test, or InfoPath may keep serving a stale copy: infopath /cache clearall from the Run box.
  5. Open the copy. If it renders, you have your route, and you can script the same edit across the rest of the folder.

Two honest caveats. If the record was filled in against an older version of the template, fields added later will simply be empty and fields since removed may not display — the data is still in the XML either way, it just is not on screen. And if the template opens data connections or runs code on startup, repointing it will not stop those from failing; see the error guide for what those failures look like.

When the template really is gone

This is the case people write into forums about, and it is more common than it should be: the site was decommissioned, the .xsn went with it, and all anybody kept was a folder of .xml files. You still have options, and you still have your data.

Read the values straight out of the XML (free)

Open a record in a text editor. The element names may be unlovely — my:field7 rather than "Cost centre" — but the values are plain text and right there. For a handful of records this is genuinely all you need.

Script it across the folder (free, technical)

A short script will pull the same values out of every file. In PowerShell, casting each file with [xml](Get-Content $f) and walking the element tree gets you to a CSV without any special tooling. This is a completely legitimate answer for a technical team with a couple of days and simple, flat forms. Where it gets awkward is repeating sections — a table of line items inside each record — because flattening those into rows correctly is fiddlier than it first appears, and it is where hand-rolled scripts quietly drop data.

Reconstruct the labels from a sibling record or an old export

If any printout, PDF or screenshot of a completed form survives, you can map field names to labels by matching values you can see against values in the XML. Slow, but it works, and it is often enough to make an archive usable by someone who was not there at the time.

Look for the template one more time before giving up

Search your estate for the name attribute rather than the filename — that identifier is stable across copies and often turns up an .xsn somebody stashed in a project folder, an email attachment, or a backup of a developer's machine.

What a dedicated reader adds here

The specific value in this scenario is that a parser does not need the template to be reachable at its original address. Point XSN Rescue at a folder and it reads whatever is in front of it: records on their own, templates on their own, or both together. Given both, it uses the template's XSD to give you the field catalogue — name, type and dotted path — so my:field7 gets its meaning back, and preserves the template's own XSL views in the HTML rendering. Given only records, it still recovers every filled-in value, including repeating and nested sections, disambiguated by indexed field paths.

It also does the things that matter when these are records rather than files: it opens everything read-only and writes source_modified: false per file so you can show the originals were untouched; it produces an audit trail in the form of a recovery report naming every file and its outcome, with nothing skipped silently; it runs entirely on your own machine, no upload and no account; and it is bought once, not rented.

Its limits, plainly. Code-behind, external data connections and user-role logic are not executed or recovered — only data and static layout. Digital signatures are surfaced as fields, not cryptographically verified. The archival PDF uses a standard Latin font, so characters outside that set are marked [U+XXXX] and counted, while the JSON export keeps the exact text. And it will not invent field labels that were only ever in a template you no longer have — without the .xsn you get the values and the paths, not a friendly name that never existed in the record.

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.

A sensible order of work

  1. Copy the records to a working folder. Leave the originals alone.
  2. Read the href, name and solutionVersion at the top of one record.
  3. Hunt for the template by name, not by filename.
  4. Found it? Repoint a copy, clear the cache, test, then repeat across the folder.
  5. Not found? Go straight to reading the values out of the XML — the data was never in the template.
  6. If these are records you must keep, finish the job: get them into open formats with something that tells you what it did to each file.

If step four solves it for you and you never come back here, that is a good outcome as far as we are concerned.