The Complete Guide to Access Validating: Everything You Need to Know

Microsoft Access has been a fixture of business software since 1992. Millions of .mdb and .accdb files exist in corporate file systems, legacy systems, and personal archives around the world. Despite the rise of cloud databases, Access databases remain in active use for inventory systems, small business applications, departmental reporting, and countless internal tools that were never migrated to a more modern platform.

When you receive an Access file — from a client, a legacy system, or your own archive — the first practical question is: is this file valid and intact? Access itself cannot open a corrupted or truncated file, and its error messages are not always informative. A dedicated validator can answer that question in seconds, without requiring Access to be installed.

This guide covers what MS Access file validation means, what checks a validator performs, how to interpret results, and the practical scenarios where validation saves significant time and frustration.

Connect on LinkedIn →

Access File Formats: MDB vs ACCDB

Microsoft Access uses two primary file formats. Understanding the difference is important for validation and migration decisions.

MDB (Jet Database Engine). The original Access format, introduced in Access 1.0 and revised across multiple versions. MDB files are managed by the Microsoft Jet database engine. Access 97 used Jet 3.x with a fixed 2 KB page size. Access 2000, XP, and 2003 all used Jet 4.x with a 4 KB page size. MDB files use the internal format identifier Standard Jet DB at byte offset 4 in the file header.

ACCDB (ACE Database Engine). Introduced in Access 2007, the ACCDB format replaced MDB as the default for new databases. It is managed by the Microsoft ACE (Access Connectivity Engine) and supports features not available in the Jet engine, including multi-valued fields, attachment fields, and stronger encryption. ACCDB files use a 4 KB fixed page size and the internal identifier Standard ACE DB. ACE version numbers in the header distinguish Access 2007 (ACE 12) through Access 2016/2019/365 (ACE 16).

Both formats share the same 4-byte magic number at offset 0: 00 01 00 00. A validator can distinguish the two formats by reading the format string at offset 4 and the version byte at offset 0x14.

What Is Access File Validation?

Access file validation is the process of inspecting the binary structure of an .mdb or .accdb file to confirm it is a well-formed Access database. Unlike text formats such as CSV or JSON, Access files are binary — their structure is defined entirely by byte offsets and values documented in the Jet/ACE file format specification.

A validator reads the file's header, checks for the correct magic bytes, decodes the format identifier, reads the version byte, checks the page size, verifies that the file size is an integer multiple of the page size, and scans for known corruption indicators. These checks can be performed without Access installed, without opening the file in any application, and without sending the file to a server.

Validation is not the same as repair. A validator tells you whether the file appears to be structurally intact. It does not fix corruption, recover lost data, or open the database. For repair, you need the Microsoft Access compact and repair function or a dedicated database recovery tool.

What Gets Checked

A thorough Access validator performs at least seven distinct checks, each targeting a different layer of the binary structure:

1. File signature — the 4-byte magic number 00 01 00 00 that every valid Jet and ACE file begins with.
2. Format identifier — the ASCII string starting at offset 4: Standard Jet DB for MDB or Standard ACE DB for ACCDB.
3. Version byte — the byte at offset 0x14 that identifies the specific Access version.
4. Page size — derived from the engine version (2 KB for Jet 3, 4 KB for Jet 4 and ACE).
5. File size alignment — whether the total file size is a multiple of the page size.
6. Minimum size check — whether the file is at least one page in length.
7. Encryption flags — whether the header indicates a database password (for Jet 3 databases).

Some validators also scan for unexpected null regions in the header, which can indicate partial corruption or zeroed-out metadata — a pattern seen in damaged files.

File Signature and Magic Bytes

Every valid Access database begins with the four bytes 00 01 00 00 at the very start of the file. This is the file's "magic number" — a fixed signature that identifies the file type at the binary level, independent of its extension.

A file that does not begin with these four bytes is not a valid Access database, regardless of its .mdb or .accdb extension. This situation arises when a file is corrupted, truncated, or misidentified — for example, a ZIP archive or a plain text file that was renamed with an Access extension.

Following the magic bytes at offset 4 is a 15-byte ASCII string: Standard Jet DB for MDB files or Standard ACE DB for ACCDB files. If neither string is present at that offset, the file cannot be opened by the Access database engine.

A mismatch between the file extension and the format string — for example, a file with a .accdb extension that contains Standard Jet DB internally — is a warning worth surfacing. This typically means the file was renamed without being converted to the newer format.

Version Detection

The byte at offset 0x14 (decimal 20) in the header identifies the specific version of the Access engine that created the database. For Jet (MDB) files:

• 0x00 — Access 97 (Jet 3.x, 2 KB pages)
• 0x01 — Access 2000, XP, or 2003 (Jet 4.x, 4 KB pages)

For ACE (ACCDB) files:

• 0x02 — Access 2007 (ACE 12)
• 0x03 — Access 2010 (ACE 14)
• 0x04 or 0x05 — Access 2013 (ACE 15)
• 0x06 — Access 2016, 2019, or 365 (ACE 16)

Version detection matters for several practical reasons. An MDB file created in Access 97 (Jet 3, page size 2 KB) cannot be opened by all versions of Access without an upgrade step. Knowing the version in advance lets you plan the migration correctly. Unrecognized version bytes are a soft warning — they may indicate a version of Access not yet documented in the public format specification, or a modified file.

Page Size and File Alignment

Access databases are organized into fixed-size pages. The Jet 3.x engine (Access 97) uses 2 KB (2,048 byte) pages. All Jet 4.x and ACE engines use 4 KB (4,096 byte) pages. Every object in the database — tables, forms, queries, reports, macros — is stored in one or more contiguous pages.

A key structural invariant of any intact Access database is that its total file size must be an exact multiple of the page size. If the file size is not divisible by the page size, the file has been truncated, and at least one page is incomplete. This is a strong signal of corruption — typically caused by an interrupted write (crash, power failure, or improper dismount of a network share).

The page count is derived by dividing the file size by the page size. A 40 MB ACCDB file should have exactly 10,240 pages of 4 KB each. If the file size is 40,001,024 bytes — 256 bytes more than a clean multiple — one page is incomplete and the database is damaged.

Encryption and Password Detection

Access supports database-level password protection. The behavior and detectability of this protection differs between Jet 3, Jet 4, and ACE engines.

Jet 3 (Access 97). Passwords in Jet 3 databases are stored at bytes 0x42 through 0x55, XOR-encoded with the value 0x86. If those bytes contain anything other than 0x86 (which represents a null character XOR'd with the mask), a password is set. This is relatively easy to detect and is surfaced as a warning by the validator.

Jet 4 (Access 2000–2003). The password field in Jet 4 databases is RC4-encrypted using a key derived from a per-database seed stored elsewhere in the header. The encrypted bytes are always non-zero regardless of whether a password is set, making reliable detection without the key impossible at the binary header level. The validator does not flag encryption for Jet 4 files.

ACE (ACCDB). A truly encrypted ACCDB (using Office Open XML encryption) does not present as a normal ACE database at the binary level. Instead, it is wrapped in an OLE compound document structure with the magic bytes D0 CF 11 E0, and the Standard ACE DB format string would not be readable. If a file has passed the format string check, it is not fully encrypted at the container level — though individual fields or the database password may still restrict access.

Corruption Indicators

Beyond the structural checks described above, a validator may scan for additional indicators of corruption or improper modification. One common pattern in damaged files is a block of unexpected null bytes in the region of the header that should contain version flags and creation metadata (bytes 20 through 31). In a healthy Access database, this region is populated by the engine at creation time and is not all zero. All-zero bytes in this range suggest the file may have been partially wiped or the header was zeroed out by a recovery attempt.

Other corruption indicators include files smaller than a single page (impossible for a valid database, which must have at least one page containing the header itself), and file sizes that are only a few bytes off from a clean page-size multiple (suggesting a partial write of the final page).

It is important to understand the limits of header-level validation. A validator can confirm that the file appears structurally intact based on its binary header. It cannot confirm that the data within the pages is uncorrupted, that all cross-references between pages are valid, or that the database can be successfully opened by the Access engine. For a definitive assessment of data integrity, you need the Access compact and repair function.

Reading the Hex Dump

The Access Validator includes an annotated hex dump of the first 80 bytes of the file. Understanding this output helps you interpret validation results and diagnose edge cases.

The hex dump displays each byte as a two-digit hexadecimal value, organized into rows of 16 bytes. The left column shows the byte offset in hexadecimal (0000, 0010, 0020, and so on). The right side shows the ASCII representation of printable bytes and dots for non-printable bytes.

The validator highlights specific regions in the dump:

• Blue (magic bytes): Bytes 0–3 (00 01 00 00) and byte 20 (version byte).
• Green (format string): Bytes 4–18 (Standard Jet DB or Standard ACE DB).

When a validation fails at the magic byte or format string check, the hex dump lets you see exactly what bytes are present at those offsets — useful for diagnosing whether the file is actually a different format (ZIP, OLE compound document, PDF, etc.) that was incorrectly labeled.

Best Practices for Managing Access Files

Whether you are a developer integrating Access data into a modern system or a business user maintaining legacy databases, these practices reduce the risk of data loss and make Access file management more reliable.

• Validate before migrating. Before attempting to export or migrate data from an Access database, validate the file to confirm it is structurally intact. Attempting to open a corrupted file in Access may trigger its repair process, which can alter or lose data.
• Validate archives. If your organization keeps Access databases as long-term archives, run periodic validation checks to detect silent corruption caused by storage media degradation or filesystem errors.
• Check files received from external sources. When you receive an Access file from a client or partner, validate it before attempting to open or process it. This takes seconds and catches problems before they cause confusion or data loss.
• Keep the original. Never work directly on an Access database that you cannot recreate. Always make a copy before opening, compacting, or repairing a file. Validation is non-destructive, but subsequent repair operations are not.
• Note the version before migrating. The version byte identifies which version of Access created the database. This matters when planning a migration — an Access 97 database (Jet 3, 2 KB pages) may require an intermediate conversion step before it can be opened in a modern version of Access.
• Use compact and repair proactively. For databases in active use, run the Access compact and repair function regularly. This reclaims space from deleted records and rebuilds internal index structures. A file that passes structural validation may still benefit from compaction.

Common Use Cases

Legacy system audits. Organizations migrating from Access-based applications to cloud databases often discover dozens or hundreds of .mdb and .accdb files scattered across file shares. Validating these files en masse before attempting migration identifies which are intact, which are corrupted, and which are not Access files at all despite their extensions.

Forensic and data recovery work. When recovering data from a damaged system, Access database files may be present alongside other recovered files. A quick validation check confirms which files are valid Access databases before time is spent on recovery attempts.

Automated file processing. If your application receives Access files as uploads or processes them from a watched folder, running a validation check before attempting to open or export the file prevents crashes and provides meaningful error messages when files are malformed.

Archival verification. Organizations that keep Access databases as long-term records can run periodic validation to confirm that stored files remain intact. Storage media degradation and filesystem corruption can silently damage files over time, and periodic validation catches these problems before the data is needed.

Version inventory. When planning an Access migration, knowing the version of each database (Access 97, 2000/XP/2003, 2007, 2010, 2013, 2016/365) helps plan the migration path. Older Jet 3 databases may need to be converted before they can be opened in newer versions of Access, and the validator surfaces this information from the binary header without requiring Access to be installed.