Opening an Access database on a Mac, and where each method stops

Why a Mac has no native way in

Microsoft Access has no macOS version, and the engine that reads .mdb and .accdb files ships as a Windows component. There is no Apple-supplied reader and no Microsoft one, which is why double-clicking the file on a Mac opens a dialog asking which application should open “this kind of document” rather than the file. Everything below exists because that gap is real, and each option fills it differently.

The gap is not the file format being secret. A Jet or ACE database is a documented page-structured file; the header, the page allocation table, and the catalog layout are all knowable. What Windows supplies is a reader built by the people who wrote the writer. Everything on macOS is a reimplementation, and reimplementations differ in which parts of the format they handle.

Four ways to read the file, and their cost

On a Mac you have four realistic routes: a browser-based parser, mdbtools from the command line, LibreOffice Base, or a Windows virtual machine. They are not variations of one another — they differ in whether anything gets installed, whether the file leaves the machine, and whether they can do anything with a damaged file.

The practical split is between routes that install something and the one that does not. If you are reading one file once, installing a toolchain is a poor trade. If you are processing a directory of exports every week,mdb-tables and mdb-export in a shell loop is the right answer and no browser will beat it.

What happens to each option on a damaged file

Every route above assumes the file is structurally intact. When the page grid is broken, the header is rejected, or pages are missing, they fail in the same shape: an error, or a table list that is shorter than it should be with no indication that anything was skipped. This is the part of the Mac story that the guides leave out, because the guides are written by people selling viewers.

The failure is quiet in a specific way. A reader walks the catalog, gets a table list, and returns rows until it hits a page it cannot decode. If it stops and reports what it got, you see a short table. If it treats the unreadable page as the end of the table, you see a small table that looks complete. The second behaviour is common, and it is why a Mac user can come away believing a 60,000-row table had 400 rows in it.

The distinction that matters is between reading and recovering. A reader returns the rows it can walk to. A recovery pass attempts to reconstruct enough structure to find rows the reader never reached — rebuilding the page grid after the header was destroyed, or resynchronising after records were rotated by a bad write. These are different jobs with different failure modes, and only the first one is available in most Mac tools.

A check order that costs nothing

Before installing anything, you can establish whether the file is readable and how much of it a reader can reach. The check is: open the file, look at the table list, and compare each table’s declared row count against the number of rows actually returned.

1. 1

   Open the file without installing anything

   Drop it into the browser-based reader. The file is parsed by a local engine in the tab; it is not uploaded. That matters if the database holds client records or payroll.

2. 2

   Read the four counts per table

   Declared in catalog, recovered, unreadable (skipped), and not reached. A table where the first two match is intact. A table where they diverge tells you the size of the problem before you commit to a tool.

3. 3

   Check the version before blaming the file

   An .accdb from a newer Access than the reader you are testing with will fail without being damaged. The version byte sits in the header, and it is the first thing worth confirming.

4. 4

   Only then choose a route

   Counts reconcile: any of the four options works, pick on convenience. Counts diverge: a viewer will not help, and a converter will produce a clean-looking file with rows missing.

If the file is rejected outright rather than returning a short table, the cause is usually in the first few dozen bytes — the header check that produces “unrecognized database format” walks through the five causes and which of them leave the rows intact.

Getting the data out on a Mac

Once the data is readable, the useful output on a Mac is a format the Mac already handles: CSV for a spreadsheet, SQLite for a script, or SQL for rebuilding the schema somewhere else. All three are copies of the data, not copies of the Access application.

Our exports were verified by reopening them rather than by trusting the download. A generated .sql file of 753,909 bytes rebuilt a table and loaded 11,149 rows into SQLite, matching the count the page reported; a generated SQLite file opened with the SQLite format 3 magic string and read back 4 tables and 21 rows in Node’s built-in SQLite library. The schema details — which column types survive, what happens to Currency and Attachments — are in the .mdb to SQLite conversion notes.

One thing that is not a compromise but a design choice: the engine runs in the browser as WebAssembly, so the platform question stops mattering. The same page works on macOS, Linux, and Windows, and needs no Access installation on any of them. To check the “nothing is uploaded” claim rather than assert it, we loaded the page, cut the network, then dragged in a damaged 60,000-row database: the report still rendered, all 81 integers in it matched the online run, and no engine asset was re-downloaded. That test exists to show the file had nowhere to go — not to promise the site keeps working offline, since navigating after a disconnect will fail.

What a Mac still cannot do

Opening the data does not give you the application. Forms, reports, macros, and VBA are Access objects, and running them requires Access; a Mac can read their source but cannot execute them. If the database is really a small business application — forms that write through logic, reports that print on a schedule — the honest answer is a Windows machine or a rewrite, not a viewer.

• Workgroup security files (.mdw) are not supported, and no Mac tool bypasses them.
• Encrypted databases need the password. There is no reader on any platform that gets past AES without it.
• Layouts are not rebuilt. Forms and reports can be read as source, not reconstructed as working screens.

Knowing which of those three applies to your file takes a minute and decides whether the next step is a conversion or a Windows VM. The FAQ states the same boundaries in shorter form, including what the free pass reports before anything is paid for.