A SQL Server BAK file is a backup in a binary format built for restoring, not reading, so double clicking it or opening it in Notepad shows only garbage. Without SQL Server you cannot restore it, but you can still read it two ways, the native RESTORE commands reveal the backup’s details, and a tool that parses the file directly shows the tables inside. Univik SQL Backup Recovery reads a copied BAK file on Windows without any SQL Server install.
You have a file ending in .bak and no SQL Server to open it with. This guide covers the SQL Server kind of backup file, not the AutoCAD drawing backup that shares the extension, so if your .bak came from a drawing program this is the wrong guide. For a SQL Server backup, the short answer is that you cannot open it the way you open a document. The rest of this page explains what you can do instead, both with the tools SQL Server gives you and without a server at all.
What a BAK file Actually Is
A BAK file is a SQL Server database backup, a point in time copy of a database written to disk so it can be restored later. It is not the live database, that is the MDF file, and it is not a spreadsheet or an export. It holds the data and the structure packed in SQL Server’s own backup layout, widely understood to be the Microsoft Tape Format, a binary design meant to be read back by a restore operation rather than by a person.
One thing it is not is a bacpac. A bacpac is a logical export used mostly with Azure SQL, and it is really a zip archive you can crack open. A BAK is a physical backup with a different internal shape, and Azure SQL cannot even restore one directly. Knowing which file you have matters, because the routes for each are different, and everything on this page is about the physical BAK.
Why You Cannot Just Open a BAK file
The instinct is to double click the file or drag it into a text editor. Try it and you get a screen of unreadable characters, because the backup is binary and structured for SQL Server’s restore engine, not for reading. There is no standard viewer built into Windows for it the way there is for a text or image file.
The format is also proprietary and undocumented in full, so there is no simple converter that turns a BAK into a spreadsheet in one step. This is the wall people hit, the file plainly holds their data, but the only thing designed to read it is the very SQL Server they may not have. That leaves three honest paths, read the backup’s details without restoring, restore it to see the data, or use a tool that parses the file directly.
Two shortcuts float around that are worth skipping. Renaming the file to .xls and opening it in Excel does not work, a backup is not a spreadsheet and Excel shows the same binary mess a text editor does. Online BAK to Excel converters do work on small demo files, but they mean uploading your backup to someone else’s server, and a real backup holds the kind of customer records or financial data that no data governance policy would allow off site. For anything real, keep the file on a machine you control.
Peek at a BAK file without Restoring
SQL Server can tell you a lot about a backup without restoring it, through a family of RESTORE commands that read only the header rather than unpacking the data. These need a running SQL Server to execute, but they touch nothing and change nothing, so they are safe to run against a backup you are inspecting.
RESTORE FILELISTONLY FROM DISK = ‘C:\Backup\YourFile.bak’
These are worth running first whatever you plan next. HEADERONLY tells you what kind of backup you are holding and which SQL Server version made it, VERIFYONLY tells you whether it is intact before you spend time on it, and FILELISTONLY gives you the logical file names a restore will need. What none of them do is show you a single row of data, and that is the limit that sends most people to the next step.
Seeing the Actual Data
To see the rows inside a backup with SQL Server’s own tools, you have to restore it. That means a running SQL Server instance, enough disk space for the restored database and the permission to run the restore. The restore unpacks the backup into a live database, and only then can you query the tables. If you only need one table, the safe pattern is to restore the whole thing under a temporary database name, copy out the table you want, then drop the temporary database.
The catch is in the requirement itself. Every native way to see the data assumes a SQL Server you can restore into, and the whole reason you are here may be that you do not have one, or the one you have will not take the file. When that is the situation, the native routes run out and the third path is the one that helps.
Reading a BAK file with No SQL Server
The route that does not need a server is a tool that reads the backup file directly. Instead of asking SQL Server to restore the backup, it parses the BAK format itself, walks the data inside and shows you the tables, so you can read or export what the backup holds even where no SQL Server is installed at all. Univik SQL Backup Recovery works this way on Windows, it opens a copied backup file and surfaces the tables inside without a restore.
This is the same idea that lets a tool read a live database file directly, the approach behind opening an MDF without SQL Server, applied to the backup file rather than the data file. It is the practical answer to the exact search that brings people here, opening a BAK when there is no server to restore it into, whether because none is installed, the licence is gone or the only copy of the data is the backup itself.
Open the backup with no server to restore into
Univik SQL Backup Recovery reads a copied BAK file on Windows and shows the tables inside, with no SQL Server install and no restore step.
The Version Lock to Know About
Even with a SQL Server to hand, one wall stops many restores. A backup cannot be restored to a SQL Server older than the one that made it. A backup taken on SQL Server 2022 will not restore onto a 2019 instance, and the version mismatch raises Error 3169. A separate message, that the media family is incorrectly formed, can mean either a version problem or a damaged file. Running HEADERONLY first tells you the source version so you know which wall you are facing.
This is the same one way street that applies to database files, laid out in opening a higher version MDF on an older SQL Server. When the only server you have is older than the backup, restoring is off the table, and a reader that parses the file directly gets around the version check entirely, since it never hands the file to a restore engine.
When a BAK Holds More than One Backup
A single BAK file can contain more than one backup set, a full backup followed by a differential or a run of log backups all written to the same file. This surprises people who expect one file to mean one backup. HEADERONLY lists every set inside with its type, and when you restore you point at the one you want with a file number rather than assuming the file holds a single backup.
It matters for reading too. If you open a multi set backup and see less or more than you expected, the file may hold several points in time, and the set you want may not be the first one. Checking the header before you commit to a route saves the confusion of restoring the wrong point in time.
Which BAK Route Fits Your Situation
The right route comes down to what you have and what you need. If you have a compatible SQL Server and want the whole database back, restoring is the natural path and the version lock is not in your way. If you only need to check what a backup contains, the RESTORE peek commands answer that in seconds without unpacking anything.
There is a route for the harder cases too. If you have no SQL Server, or the one you have is older than the backup, a reader that parses the file directly is the one that fits. The same holds when you only need to read or pull out some data rather than stand the whole database back up. It is also the calm option when the backup is the last copy of the data and you would rather read it on a separate machine than risk anything on a restore. It is worth separating two reasons a backup will not open. A version lock is not damage, the file is fine and simply needs a newer server or a direct reader. A backup that will not open on any server, or reports itself as incomplete, is damaged rather than version locked, and that shades into recovery, which our guide to what causes SQL Server corruption covers.
Frequently Asked Questions
Can I Open a BAK file Without SQL Server?
Not with SQL Server’s own tools, since those need a running instance to restore into. You can open one with a third party reader that parses the BAK format directly and shows the tables inside, with no SQL Server installed. That is the route when none is available or the backup is your only copy of the data.
Why Does my BAK file Show Garbage in Notepad?
Because a BAK file is binary, not text. It is a SQL Server backup written in a proprietary layout built for the restore engine to read back, not for a person to open in an editor. A text editor shows the raw bytes as unreadable characters, which is expected and does not mean the file is damaged.
How do I See What is Inside a BAK file?
Run RESTORE HEADERONLY and RESTORE FILELISTONLY against it on a SQL Server, which reveal the backup sets, the source version and the logical files without restoring anything. To see the actual rows you either restore the backup or use a tool that reads the file directly. The peek commands show details, not data.
Is a BAK File the Same as a bacpac?
No. A BAK is a physical SQL Server backup in the Microsoft Tape Format, restored through the RESTORE command. A bacpac is a logical export used mostly with Azure SQL and is really a zip archive. They have different internal structures, and Azure SQL cannot restore a BAK directly, which is why the distinction matters for cloud work.
Can I Open a Newer BAK file on an Older SQL Server?
No. A backup cannot be restored to a SQL Server older than the one that created it, so a 2022 backup will not restore onto a 2019 instance. Run RESTORE HEADERONLY to read the source version. A reader that parses the file directly avoids the version check, since it never uses the restore engine.
How do I Extract One Table from a BAK file?
With SQL Server, restore the whole backup under a temporary database name, copy the table you want into your target database, then drop the temporary one. Restoring a single table on its own is not supported and risks breaking the relationships between tables. A direct reader can also pull out individual tables without a full restore.