How to Validate a DBF File: Step-by-Step Tutorial
🗄️ Open the DBF Validator and follow along — free, private, nothing uploaded.
Open DBF Validator →Steps
This tutorial walks you through validating a .dbf file using the DBF Validator. The tool reads your file entirely in your browser using the Web File API — nothing is uploaded to a server. It is suitable for sensitive business data, customer records, geographic attribute tables, or any private dBASE content.
1 Locate Your DBF File
Find the .dbf file you want to validate. Common sources include:
- Shapefile components — the
.dbffile that accompanies a.shpand.shxfile, containing the feature attribute table - dBASE / FoxPro exports — table exports from FoxPro, Visual FoxPro, Clipper, or dBASE IV
- Legacy accounting or ERP exports — data extracts from older business systems that used dBASE as their underlying storage
- Government or municipal data downloads — property records, permit databases, zoning data, or voter roll exports distributed as DBF files
Check that the file has a .dbf extension. Files with associated memo files (.dbt or .fpt) can still be validated — the validator reads only the .dbf component and will note that memo fields are present.
Tip: If you received a shapefile as a ZIP archive, extract it first. The .dbf component will share the same base filename as the .shp file (e.g., parcels.dbf alongside parcels.shp).
2 Open the DBF Validator
Navigate to dataconversioncenter.com/developer-tools/dbf-validator/. The page loads instantly — there is no registration, no account, and no installation required. The validator runs entirely in your browser using the FileReader API with ArrayBuffer binary reads.
You will see a drop zone in the center of the page with a brief description of what the validator checks. The trust badges below the header confirm that all processing is local: no files leave your machine.
3 Drop or Browse for the File
Load your .dbf file using one of two methods:
- Drag and drop. Drag the file from your file manager or desktop onto the drop zone. A blue highlight indicates the zone is ready to receive the file. A full-page overlay also activates when you drag a file anywhere over the browser window, preventing accidental browser navigation.
- Browse. Click the "browse" link inside the drop zone to open a standard file picker. Navigate to the
.dbffile and select it.
Once the file is loaded, the drop zone is replaced by a file name chip showing the file name and a clear button. The tool is now ready to validate.
Wrong file type? If you accidentally drop a non-DBF file, the validator shows a red banner identifying the actual extension and does not attempt to parse it. Click Clear and try again with the correct file.
4 Run the Validation
Click the blue Validate DBF button. The validator performs all checks synchronously in the browser — for files up to 50 MB the result appears in under a second. For very large files (tens of megabytes with hundreds of thousands of records), the scan may take a moment as it reads every record's deletion flag.
5 Read the Status Bar
The first thing to check after validation is the status bar directly below the button row. It uses three colors to communicate the overall result at a glance:
"Valid DBF — no issues found."
"Valid DBF — 2 warning(s). See details below."
"Validation failed — 1 error(s) found."
A green status bar means the file is structurally sound and safe to process. An amber bar means the file is parseable but has non-critical issues worth reviewing — see Step 9. A red bar means the validator found a structural problem that will likely cause downstream failures — see Step 10.
6 Review the Stats Panel
Below the status bar, the Valid DBF stats panel shows key facts about the file in a grid of cards:
| Stat | What it means |
|---|---|
| Active records | Records not flagged for deletion — the "live" row count |
| Deleted records | Records marked with the soft-delete flag (0x2A) still present in the file |
| Fields | Number of column definitions in the header |
| Record size | Bytes per record (including the 1-byte deletion flag) |
| Header size | Bytes from the start of the file to the first data record |
| File size | Total file size, shown in B / KB / MB |
| Version | dBASE variant identified from the first byte |
| Last updated | Date stored in header bytes 1–3 (YY/MM/DD, two-digit year) |
| Lang driver | Language driver ID byte — indicates the character encoding used |
Pay particular attention to the Active records count and compare it to what you expect. If you're validating a shapefile attribute table, this count must match the feature count in the .shp component.
Last updated date: The date in the header is not automatically updated by all tools — some generators never set it. An obviously wrong date (e.g., 1900-00-00) is flagged as a warning. It does not affect data integrity.
7 Review the Field Definitions
The Field Definitions panel lists every column in the file in a table with five columns:
- # — the field's position in the record (1-indexed)
- Field Name — the column identifier as stored in the header (up to 10 characters)
- Type — the field type code and its full name (e.g.,
C— Character,N— Numeric,D— Date) - Length — the field's byte width in each record
- Decimals — the decimal precision for numeric fields;
—for non-numeric types
Review the field list to confirm that all expected columns are present with the correct names and types. Common things to check:
- Are field names matching the schema documentation for this data source?
- Are numeric fields that should carry decimal values showing a non-zero decimal count?
- Are date fields typed as
D(Date) rather thanC(Character)? - Are memo fields (
M) present? If so, you will need the associated.dbtor.fptfile to read their contents.
8 Check the Data Preview
The Data Preview panel shows the first five active records rendered in a table with field names as column headers. This is an important sanity check independent of the structural validation: does the data look correct?
Things to look for in the preview:
- Garbled characters. Non-ASCII characters that appear as replacement characters or question marks indicate an encoding mismatch. Check the Lang driver value in the stats panel and configure your downstream parser to use the correct codec.
- Empty values where data is expected. A field that appears blank in the preview may have a length mismatch — the field descriptor declares a longer length than the actual content — or the field may genuinely be empty in these rows.
- Truncated values. Character fields are padded with spaces to their declared length. Values that appear cut off at a consistent character boundary may indicate that the field length is shorter than the data it was designed to hold.
- Unexpected nulls or zeros. Logical fields should show T, F, Y, N, or a space for unknown. A zero byte rendered as an empty string or unusual character may indicate that the logical field was not populated correctly.
9 Interpret Warnings
Warnings are listed in the amber Warnings panel. Each warning describes a non-critical issue that does not prevent parsing but may affect downstream processing. Common warnings and what to do about them:
EOF marker absent
The standard end-of-file byte (0x1A) was not found at the end of the file. This is harmless for most modern parsers, which determine the end of the data area from the header's record count and record size rather than scanning for the marker. No action is usually required.
Unrecognized version byte
The first byte of the file is not in the list of known dBASE version codes. The file may be from a proprietary tool or an unusual variant. If the rest of the structure validates correctly, the file is likely parseable as a standard DBF. Proceed with caution and test with your target parser.
Invalid last-updated date
The date bytes in the header do not form a valid calendar date (e.g., month 00 or day 33). This is a generator bug and does not affect the data. No action required unless the consuming application reads the header date.
Deleted records present
One or more records are marked with the soft-delete flag. They still occupy space in the file. If the consuming application does not filter deleted records, they may appear in query results. Run a PACK operation in your dBASE or FoxPro application to permanently remove them before exporting, or filter them in your consuming application.
Duplicate field names
Two or more fields share the same name (case-insensitively). Most SQL consumers and ORMs will either reject the file or produce unpredictable column mapping. The fix is to rename the duplicate fields in the originating application before re-exporting.
File size has extra bytes
The actual file is slightly larger than expected based on the declared record count and record size. Extra bytes after the data area are unusual but not necessarily harmful. They may be padding added by the generating application. If your parser reads the data area by record count rather than file size, no action is required.
10 Act on Errors
Errors are listed in the red Validation Errors panel. Each error describes a structural problem that will likely cause your downstream tool to fail or produce incorrect output. Common errors and resolution paths:
File too small
The file is shorter than the minimum 32-byte header, or shorter than the size required for the declared number of records. The file is truncated. Resolution: re-export from the source system. If the source is unavailable, this file cannot be recovered.
Record count mismatch (file truncated)
The declared record count times the record size does not fit within the actual file size. Resolution: re-request or re-download the file. This is almost always caused by an incomplete file transfer or a crashed export. Confirm the expected file size with the data provider.
Field length sum mismatch
The sum of all field lengths plus one (deletion flag) does not equal the declared record size. The header is internally inconsistent. Resolution: this requires manual hex editing of the header's record size field (bytes 10–11) to match the actual field sum, or correcting the individual field lengths. This is a generator bug and should be reported to the software vendor.
No field descriptors found
The header declares fields but none were found at the expected offset, or the field array terminator appears at the very start. The file may have a corrupt header beyond byte 32. Resolution: inspect the file in a hex editor to determine whether the field descriptor region is intact.
Invalid field type code
A field has a type code character that is not recognized for any standard dBASE variant. This may indicate a proprietary extension or header corruption. Resolution: identify the originating application and check its documentation for custom field type codes. If the type code appears in only one field, it may be a padding byte that was misread as a type code — inspect the relevant descriptor offset in a hex editor.