How to Use the Access Validator: Step-by-Step Tutorial

This tutorial walks you through validating an MS Access database file from start to finish using the Access Validator. You will learn how to load a file, read the validation results, interpret the hex dump, understand version and encryption information, and know what to do when validation fails.

No installation is required. The validator runs entirely in your browser — nothing is uploaded to any server.

Connect on LinkedIn →

Step 1 — Open the Access Validator

Navigate to dataconversioncenter.com/developer-tools/access-validator/ in any modern browser. No sign-in is required. The tool loads entirely in your browser — no server processing occurs at any point.

You will see a drop zone labeled "Access Database File" in the center of the tool, with a file browser link and two buttons: Validate Access File and Clear.

Step 2 — Load Your Access File

You can load a file in two ways:

1. Drag and drop. Drag your .mdb or .accdb file from Windows Explorer, macOS Finder, or your file manager directly onto the drop zone. A full-page overlay will appear while you drag, prompting you to drop anywhere.
2. Browse. Click the browse link in the drop zone to open a file picker. Select your .mdb or .accdb file and confirm.

Once the file is loaded, the drop zone is replaced by a file name display showing the database icon and your file's name. If you load the wrong file, click the × button beside the file name to remove it and load a different one.

Wrong file type? If you drop a file that is not an .mdb or .accdb, a red error banner will appear identifying the file extension. Clear the error by clicking the × button, then load the correct file.

Step 3 — Run Validation

Click the blue Validate Access File button. The validator reads the file's binary header — this is instantaneous even for large files, because only the first few hundred bytes are inspected.

Results appear immediately below the buttons: a status bar followed by one or more result panels, a header details table, and an annotated hex dump.

Step 4 — Read the Status Bar

The status bar appears directly below the buttons and gives a one-line summary of the validation result:

• Green — "✓ Valid Access database — no issues found." The file has a correct signature, a recognised format string, a known version byte, a correct page size, and a file size that is an exact multiple of the page size. No encryption was detected.
• Yellow — "Valid Access file — N warning(s). See details below." The file passes all structural checks but has one or more conditions worth reviewing. The file is likely intact. See the Warnings panel for specifics.
• Red — "Validation failed — N error(s) found." The file failed one or more critical structural checks. See the Errors panel for the exact failure.

Step 5 — Read the Stats Panel

If the file passes the basic checks (magic bytes and format string), a green stats panel appears showing key metadata extracted from the header:

• Format. Either MDB (Jet) for legacy databases or ACCDB (ACE) for modern databases. This tells you which engine manages the file.
• Version. The specific Access version that created the database — for example, "Access 2010" or "Access 2000 / XP / 2003".
• Engine. The database engine identifier — for example, "Jet 4.x" or "ACE 14".
• Page size. The fixed page size for this engine version, in bytes: 2,048 B for Jet 3 (Access 97), 4,096 B for all other versions.
• Page count. The number of pages in the database, calculated by dividing the file size by the page size. Shown as "—" if the file size is not a clean multiple of the page size.
• File size. The total file size in bytes, KB, or MB as appropriate.
• Encrypted. "Yes" if a database password was detected (Jet 3 only). "No" otherwise.

Step 6 — Read the Header Details Table

Below the stats panel is a table showing the specific values read from the header, presented as label/value pairs:

• Format identifier. The raw ASCII string at offset 4 — either Standard Jet DB or Standard ACE DB.
• Access version. The human-readable version label derived from the version byte.
• Database engine. The engine name and major version.
• Version byte. The raw hexadecimal value of the version byte at offset 0x14, for example 0x02 (offset 0x14).
• Page size. The derived page size with an explanation of why it was derived that way — for example 4 096 bytes (ACE fixed).
• Encryption. Either None detected or a description of the encryption method found.

Step 7 — Read the Hex Dump

The third panel shows an annotated hex dump of the first 80 bytes of the file. This is the raw binary content of the file header, formatted as rows of 16 bytes each.

How to read the hex dump:

• The grey column on the left shows the byte offset (in hexadecimal) of the first byte in each row. 0000 is the start of the file; 0010 is byte 16; 0020 is byte 32, and so on.
• The center section shows each byte as two hexadecimal digits. A gap between byte 8 and byte 9 in each row helps visual counting.
• The right section shows the ASCII representation of each byte. Printable characters appear as-is; non-printable bytes appear as dots.

Highlighted regions:

• Blue (magic bytes and version): Bytes 0–3 (the four magic bytes 00 01 00 00) and byte 20 (the version byte at 0x14) are highlighted in blue. The magic bytes appear as four blue zeros in the first row.
• Green (format string): Bytes 4–18 contain the ASCII format identifier string. In the right column you will see either Standard Jet DB or Standard ACE DB in green.

When validation passes, the hex dump lets you visually confirm the correct bytes are present. When validation fails due to a bad signature, the hex dump shows exactly what bytes were found instead of the expected 00 01 00 00 — often revealing that the file is actually a ZIP, PDF, OLE compound document, or other format.

Step 8 — Understand Warnings

Warnings appear in a yellow panel between the status bar and the stats panel. The file is still valid when warnings are present — they flag conditions worth reviewing, not structural failures. Common warnings include:

File size not a multiple of page size. The file size is not an exact multiple of the page size. This is a soft warning that the file may have been truncated or was not closed properly. The database engine may still be able to open the file, but you should run Compact and Repair in Access before relying on it for production use.

Extension/format mismatch. The file has a .accdb extension but the internal format identifier says "Jet DB" (or vice versa). This means the file was renamed without being converted to the expected format. Open the file in the correct version of Access to verify its contents.

Database password set (Jet 3). A password is encoded in the header. The file can only be opened with the correct password in Microsoft Access. This is informational — the file structure is valid, but access requires authentication.

Unrecognised version byte. The version byte at offset 0x14 does not match any known Access version. This may indicate a future version of Access not yet documented, or a modified file. The file may still open in a recent version of Access.

Bytes 20–31 all zero. An unusual null region in the header. In healthy databases this region contains version flags and creation metadata. All-zero bytes here may indicate partial corruption or a zeroed header.

Step 9 — Handle Validation Errors

Errors appear in a red panel. They indicate that the file failed a critical structural check and cannot be a valid Access database as-is. Here are the specific errors and what to do about each one.

Invalid file signature. The first four bytes are not 00 01 00 00. This means the file is not an Access database, regardless of its extension. Check the hex dump to see what the actual bytes are — they may indicate a different format. If the file was received from an external source, request the correct file. If the file was renamed by mistake, identify the correct format from the magic bytes.

Unrecognised format identifier. The magic bytes are correct but the string at offset 4 is not Standard Jet DB or Standard ACE DB. This is unusual and may indicate a very old Access format, a damaged header, or an unusual Access variant. Try opening the file directly in Microsoft Access to see if it recognises the format.

File too small. The file is smaller than 4,096 bytes (one page). A valid Access database must have at least one complete page containing the header. Files this small are either empty, truncated, or not Access databases. Check whether the full file was transferred or downloaded correctly.

Step 10 — Practical Examples

Here are three real-world scenarios and what to expect from the validator in each case.

Example 1: Valid ACCDB file, no issues. You receive an .accdb file from a client and want to confirm it is intact before opening it in Access. You load the file, click Validate, and see a green status bar: "✓ Valid Access database — no issues found." The stats panel shows Format: ACCDB (ACE), Version: Access 2016 / 2019 / 365, Page size: 4,096 B, and Page count: 2,560 for a 10 MB file. The hex dump shows 00 01 00 00 in blue at the start and Standard ACE DB in green. The file is structurally intact and safe to open in Access.

Example 2: Truncated MDB file. A file share backup has an .mdb file that was interrupted mid-copy. When you load and validate it, you see a yellow status: "Valid Access file — 1 warning(s). See details below." The warning reads: "File size (6,144 bytes) is not an exact multiple of the page size (2,048 bytes)." The page size shows 2 KB (Jet 3 fixed), confirming it is an Access 97 database. The file size is 6,144 bytes — exactly 3 pages — which is a clean multiple. Wait — re-reading, the warning says the file size is not a multiple. Perhaps the copy gave 6,200 bytes. The conclusion: the last page is incomplete. The database may not open correctly. Obtain a fresh copy of the file from the source.

Example 3: File renamed with wrong extension. A file named archive.mdb fails to open in Access with a generic error. You load it in the validator and see a red status: "Validation failed — 1 error(s) found." The error reads: "Invalid file signature. Expected 00 01 00 00 at offset 0 but found 50 4B 03 04." Looking at the hex dump, the right column shows PK at the very start — that is the ZIP file magic number. The file is actually a ZIP archive that was renamed to .mdb. Extract its contents to find the actual Access database.