XML wraps data in named tags, but an .mdf holds none. The file is really a binary SQL Server database, so a text editor shows nothing usable and renaming it to .xml will not help. A Windows tool that reads the .mdf on its own turns the tables into markup with no SQL Server instance anywhere. Univik MDF Converter does exactly that and writes well formed XML, columns as elements or attributes, with dates, null and reserved characters handled the way XML requires. Nothing leaves your machine.
One note on the extension. This guide covers the SQL Server database .mdf, a Master Database File that keeps a database’s tables and rows in one binary container. Two other files share those letters, an Alcohol 120% disc image and an automotive ASAM MDF4 recording. If you have either of those, our MDF to CSV guide sorts out which file is which.
Why XML and Not CSV or JSON
XML is the right choice when data has to move between systems that expect a strict, self describing format. A CSV is only flat text. JSON is a light structure meant for code. XML wraps every value in a named tag and can carry a schema that states exactly what is allowed, which is the point in enterprise and interchange work.
Take a single row. In XML it might read <row id=”7891″><active>1</active></row>, where the tags name each field and nothing is left to guess. The markup is heavier than JSON, but it describes itself and can be checked before anything reads it.
When the data is just flat rows, our MDF to CSV guide covers that route, and when the target is code or a NoSQL store, converting to JSON stays lighter. XML is the one to choose when a SOAP service, a config loader or an older enterprise system waits on the other end.
Three Ways to Convert MDF to XML
Three routes take an .mdf to XML, and each needs something different in place first.
Inside SQL Server, the native route uses FOR XML. Once the database is attached you append the clause to a query and choose a mode. RAW gives one element per row, AUTO nests by table and PATH gives the most control over element and attribute names. ROOT adds the wrapping element and ELEMENTS turns attributes into child elements. This needs a live instance with the database attached, and writing the result to a file takes a further step through sqlcmd or bcp.
The online route pushes the file to a hosted converter and downloads XML back. It skips SQL Server, but every table travels to someone else’s server first.
The direct read route never leaves your machine. It reads the .mdf and produces the XML locally, with no instance and nothing sent out.
Reading the MDF Straight to XML
A single read of the .mdf can produce XML just as it produces CSV or JSON. The tool opens the file, rebuilds each table, then writes the rows as tagged markup rather than a grid. With nothing mounted, it works on a PC that has no SQL Server and on an .mdf that no server will load.
The direct read comes down to four steps.
- Open the .mdf in the tool, with no SQL Server running.
- Select a single table or all of them at once.
- Choose the XML shape, elements or attributes, with the root added for you.
- Export the file to a folder you pick.
Univik MDF Converter takes this route on Windows. You pick elements or attributes and it writes well formed XML with the root element already in place. Rows the file still marks as deleted appear in red before you export. The version support and licensing are laid out on the MDF Converter product page. To read the tables without writing a file, the MDF viewer opens them on their own.
Columns as Elements or Attributes
XML gives you two places to put a column’s value, and the .mdf export can produce either. The choice shapes how the document reads and how a consumer pulls values out.
As attributes, a row stays compact. Each column sits on the element itself, as in <row id=”7891″ active=”1″/>. As elements, the same row spreads out, with every value in its own tag, which nests and validates more cleanly. Either way, a well formed XML file needs a single root element wrapping all the rows, so the export adds one.
Attributes suit compact, flat data. Elements suit anything that will be nested, transformed or checked against a schema.
How Multiple Tables Map to XML
A database holds many tables, and XML needs them arranged under roots. The export keeps it simple. Export Table writes the current table as one XML file under a single root. Export All Data Tables takes every user table, one XML file each, named for the table with the system tables skipped.
One table per file gives each document a clean root that validates on its own. Combining several tables under one root is possible in your own tools afterward, not a step the export forces.
How Types, Dates and Encoding Appear in XML
Every value in XML is text between tags, so the export relies on encoding and escaping to keep that text exact.
Encoding. The file opens with an encoding declaration set to UTF-8, which keeps accented and non Latin text intact without a separate step.
Reserved characters. Five characters have special meaning in XML and cannot be used directly in data, so the export replaces them with their entities. The ampersand, the two angle brackets, the double quote and the apostrophe each get encoded, which keeps the markup well formed.
Dates and null. A datetime is written as an ISO 8601 timestamp like 2026-03-14T09:30:00, the xs:dateTime form. A NULL column is either dropped from the row or kept as an empty element flagged xsi:nil, so a missing value stays distinct from an empty one.
Binary. A varbinary value has no plain text form, so it is written as base64 inside the tag or left out of the export.
Validating the XML With an XSD Schema
The feature that sets XML apart from CSV and JSON is the schema. An XSD, short for XML Schema Definition, states which elements and attributes are allowed, in what order and of what type, so a document can be checked before it is trusted.
That matters because XML travels into systems that will not accept surprises. A SOAP service, a configuration loader or an XSLT transform validates the incoming XML against an XSD and rejects anything that does not fit. SQL Server can emit a matching schema inline through the XMLSCHEMA directive on FOR XML, and a direct read export can pair the data with a schema the same way.
Validation is what makes XML a safe agreement between systems. The rules of the format itself are set by the W3C XML specification, so a file that validates reads the same wherever it goes.
Handling a Corrupt or Detached MDF
XML export assumes the .mdf opens cleanly. A damaged file means recovery has to come first. If enough pages survive, a direct read can still write the intact tables to XML from a file SQL Server refuses. Beyond that point, the file needs repair before any export.
A database that will not start is a recovery task. Our guide on recovering a SQL database without a backup walks through it, and the SQL database recovery tool operates on the .mdf directly when the file itself is at fault. The MDF file extension guide covers how the MDF, NDF and LDF parts fit together.
Read your MDF and write clean XML, no SQL Server required
Univik MDF Converter reads your .mdf on Windows and writes well formed XML, elements or attributes, alongside eight other formats. Rows the file marks as deleted are flagged in red, and nothing is uploaded.
Frequently Asked Questions
Can I Convert an MDF to XML Without SQL Server?
Yes. Opening the .mdf as a plain file means no database engine runs and nothing needs installing. Univik MDF Converter reads it on Windows and writes well formed XML. FOR XML cannot do the same, since it is a clause that only runs inside a live SQL Server database with the file attached.
Should the Columns be XML Attributes or Elements?
Either works, and the export lets you pick. Attributes keep a row compact, with each column sitting on the element. Elements give every value its own tag, which nests and validates more cleanly. Choose attributes for flat, compact data and elements for anything you will transform or check against a schema.
How are Special Characters and Encoding Handled in the XML?
XML reserves five characters, so the export replaces them in data with their entities. The ampersand, the two angle brackets, the double quote and the apostrophe each get encoded, which keeps the markup well formed. The file also states its encoding as UTF-8, which brings accented and non Latin text across without a separate step.
Does the Exported XML Include an XSD Schema?
It can. An XSD describes the elements, attributes and types the document allows, so a consumer can validate the file before reading it. SQL Server produces one inline through the XMLSCHEMA directive on FOR XML, and a direct read export can attach a schema alongside the data.
How are Dates and Null Columns Written to the XML?
A datetime is written as an ISO 8601 timestamp like 2026-03-14T09:30:00, which is the xs:dateTime form. A NULL is either dropped from the row or kept as an empty element flagged xsi:nil, so a missing value never looks like an empty one.
Is XML or JSON the Better Target?
It depends on what reads the file. XML suits strict interchange, schema validation and older enterprise systems that expect tagged markup. JSON is lighter and easier for code and NoSQL stores, which our guide on converting MDF to JSON covers. Choose XML when a schema or a legacy system is in the picture.