ACCDB File Documentation

Summary

An ACCDB file is a Microsoft Access database, the format Access has used since the 2007 version (replacing the older .mdb). One self-contained file holds the tables, relationships, queries, forms, reports, macros and VBA code of a database application. It is a proprietary binary format backed by the ACE engine, with the MIME type application/x-msaccess and the string Standard ACE DB near its start. Microsoft Access (Windows only) is the native opener; free tools like MDB Viewer Plus or LibreOffice Base read a .accdb without it.

Technical details

FeatureValue
Full nameMicrosoft Access Database (2007+)
File extension.accdb
MIME typeapplication/x-msaccess
Format typeProprietary binary database file
Database engineACE (Access Connectivity Engine), successor to Jet
DeveloperMicrosoft
Introduced2007, with Access 2007
Replaces.mdb (Jet engine, Access 95–2003)
Open standardNo — proprietary
Byte orderLittle-endian
Page size4096 bytes
Magic stringStandard ACE DB at offset 4 (MDB shows Standard Jet DB)
Native openerMicrosoft Access (Windows only; no Access for macOS)
StoresTables, queries, forms, reports, macros, VBA modules, relationships
ACCDB-only featuresMultivalued fields, attachment fields, calculated columns, data macros
Related extensions.mdb, .accde, .accdt, .accdr, .laccdb, .ade
Specificationlearn.microsoft.com — Access 2007 file format reference
File signature (magic bytes)
00 01 00 00 53 74 61 6E 64 61 72 64 20 41 43 45 20 44 42

An .accdb begins with 00 01 00 00, then at offset 4 the ASCII string Standard ACE DB (53 74 61 6E 64 61 72 64 20 41 43 45 20 44 42). The older .mdb format instead carries Standard Jet DB at the same offset, so this string is the quickest way to tell the two apart in a hex editor. This header sits in the first database page; ACE, like the Jet4 engine before it, stores the file in fixed 4096-byte pages.

What is an ACCDB file?

ACCDB is the default file format of Microsoft Access since Access 2007, when it replaced the older .mdb format that Access had used from 1995 to 2003. It is a single self-contained file that holds an entire database application: the data tables, the relationships between them, saved queries, data-entry forms, printable reports, macros, and the Visual Basic for Applications (VBA) code modules behind the app. Because the data and the application live in the same file, an .accdb you receive might be nothing but data, or it might be a complete program with a user interface and code.

The format is backed by the ACE engine (Access Connectivity Engine), the successor to the older Jet database engine. This article covers what changed from Jet/MDB to ACE/ACCDB, how the file is laid out on disk in fixed pages, what each kind of object inside it is, the family of related extensions, and the specific way ACCDB runs code — which is where its real risk lives.

ACE versus Jet: what ACCDB added and dropped

ACCDB is not just a renamed .mdb. Moving from the Jet engine to ACE brought new capabilities that the old format could not represent, and dropped some legacy ones. The additions are the reason a database using them cannot be saved back to .mdb:

FeatureStatus in ACCDB
Multivalued fieldsAdded — a single field can hold several values
Attachment fieldsAdded — files stored inside a record
Calculated columnsAdded — a column computed from others
Data macrosAdded — table-level triggers on insert/update/delete
SharePoint integrationAdded
User-level securityRemoved
Database replicationRemoved
Workgroup .mdw / .mde splitRemoved (replaced by .accde)

The clearest fingerprint of the engine change is in the file header. Both formats store the same kind of marker at offset 4, but the string differs: an ACCDB reads Standard ACE DB, while an MDB reads Standard Jet DB. That one string is the fastest way to identify which format a file really is, regardless of its extension.

Pages: how ACE lays the file out on disk

Like the Jet4 engine before it, ACE organises the file into fixed-size pages of 4096 bytes. The whole database — table data, indexes, the internal catalog — is a collection of these pages, each with a type and a role, chained together by page numbers rather than stored as one continuous stream. The first page is the database header page; it carries the Standard ACE DB marker, the format version, and pointers into the rest of the file.

Page 0:   Database header  — "Standard ACE DB", version, page pointers
Data pages:   rows of a table, packed into 4096-byte pages
Index pages:  B-tree nodes for indexed columns
LV pages:     "long value" pages for Memo/OLE/attachment data too big for a row
System pages: the MSys* catalog tables describing every object

Storing data in fixed pages is what lets Access read and write parts of a large database without loading the whole file, and it is why an .accdb can grow and then benefit from a Compact and Repair pass, which rewrites the pages to reclaim space left by deleted rows. A row longer than a page — a Memo field, an embedded attachment — spills into dedicated long-value pages that the row references.

The objects inside: tables, queries, forms, reports, code

An Access database is a container of typed objects, and understanding the file means knowing what each object is:

  • Tables hold the actual data, stored in the data pages by the ACE engine. They are the only objects that contain records; everything else operates on them.
  • Queries are saved SQL — SELECT statements that return a view of the data, or action queries (INSERT/UPDATE/DELETE) that change it. A query stores the SQL, not a copy of the data.
  • Forms are the data-entry and navigation user interface: the windows a user sees and types into.
  • Reports are print and PDF layouts over the data, with grouping, sorting and totals.
  • Macros are lists of automation actions, including data macros that fire as table-level triggers when a record changes.
  • Modules are VBA code — full Visual Basic for Applications procedures behind the application.

Access keeps track of every one of these in a system catalog: a set of hidden tables whose names begin with MSys (such as MSysObjects), which record the object list, their types, and the relationships between tables. When a third-party tool reads an ACCDB, it is these catalog tables it reads first to discover what the database contains. It also explains why free readers reliably recover tables and data but often cannot reproduce forms, reports or VBA: those objects are stored in Access-specific structures that only Access fully interprets.

The ACCDB family: accde, accdt, accdr, laccdb

Several sibling extensions belong to the same format family, and each signals a specific state of the database:

ExtensionWhat it is
.accdbThe standard editable database
.accdeA compiled, locked build: VBA source removed, design view disabled (for distribution)
.accdtA database template
.accdrForces the database open in runtime mode (users run it, cannot redesign)
.laccdbA temporary lock file created next to an open database, recording who has it open

The .laccdb lock file is the source of a frequent problem. Access creates it while a database is open, to coordinate multi-user editing, and normally deletes it when the last user closes the database. If Access crashes, a stale .laccdb can be left behind and make the database open read-only or refuse edits. The remedy is to make sure no one has the database open, then remove the leftover lock file — but never delete a .laccdb while the database is genuinely in use.

Data macros and VBA: how an ACCDB runs code

An ACCDB is not purely passive data. Because it can contain VBA modules and data macros, it can execute code, and that is the format's genuine security concern. VBA is full programming; a data macro is a trigger Access runs automatically when a table row is inserted, updated or deleted. Both mean that simply working with a database from an untrusted source could run someone else's code.

Access mitigates this the same way Word and Excel do: it opens an unknown database with macros disabled, showing a Trust Center warning (the yellow security bar), and code stays inert unless you explicitly enable it or the file's location is trusted. Leave it disabled unless you trust the sender. Read-only viewers such as MDB Viewer Plus or LibreOffice Base do not run Access macros at all, which makes them a safer way to inspect an unfamiliar .accdb when you only need to see the data. Beyond code, the data itself is inert. A separate protection is encryption: Database Tools > Encrypt with Password password-protects the file, with reasonably strong encryption in the Access 2010+ ACCDB format (the original Access 2007 encryption was weak).

Why there is no ACCDB opener on macOS

Microsoft Access is a Windows-only Microsoft 365 / Office desktop application, and there has never been a Microsoft Access for macOS. That single fact drives one of the most common questions about this format — how to open an .accdb on a Mac — and it has no native answer. The practical routes are to use LibreOffice Base, which connects to the database to read tables and export the data (though it will not fully load Access forms, reports or VBA), or to run Windows and real Access in a virtual machine when full application fidelity is required. On Linux the situation mirrors this: LibreOffice Base for browsing, plus the command-line mdbtools package (mdb-export file.accdb TableName) to dump a table straight to CSV.

References