DBF Analyzer
Drop a .dbf file — get its exact dialect, field structure, codepage,
memo/index dependencies and integrity warnings.
Everything runs in your browser; the file never leaves your machine.
No DBF at hand?
Planning to migrate this data?
One to two weeks. You get a full inventory of the application and its data, a risk map (what breaks first, what is undocumented, what nobody can rebuild), a data-quality report and a migration roadmap with honest effort estimates — a document you can execute with us or with any other team. Fixed price, agreed before we start.
Send us the analyzer report (structure only — it contains no row data) and we will tell you, for free, what the migration traps in your specific tables are.
What the DBF header tells you
A DBF file starts with a 32-byte header and one 32-byte descriptor per field — and almost every byte of it matters for a migration:
The version byte: which dialect wrote this table
Byte 0 identifies the writer: 0x03 is the classic dBase III+/Clipper
family, 0x83 the same with a .dbt memo, 0xF5 FoxPro 2.x with
an .fpt memo, 0x30 Visual FoxPro (which adds table flags, field
nullability, autoincrement and database containers), 0x8B dBase IV with
memo. Tools that ignore the dialect misread field flags, memo pointers — or refuse the
file entirely.
The codepage byte: where text migrations die
Byte 29 is the language driver ID: 0x03 means Windows-1252,
0x65 Russian cp866, 0x7D Hebrew Windows-1255 — but the value
DOS-era applications actually wrote is usually 0x00: no codepage
recorded at all. The bytes in Character fields are then whatever OEM page the
original PCs ran — cp437 or cp850 in the West, cp852 in Central Europe, cp866 for
Cyrillic, cp862 for Hebrew. Read them with the wrong page and every non-Latin character
is silently destroyed. This single byte is responsible for more ruined migrations than
any other in the format.
Companion files: the table is not just the .dbf
Memo fields live in .fpt/.dbt block files; Visual FoxPro
tables can carry a structural .cdx index whose expressions encode real
business rules; DBC-container tables keep long field names, triggers and validation in
the .dbc. Copy the .dbf alone and you have copied a skeleton.
Ghost rows and integrity math
Deleting an xBase record only flags it with * — until someone runs
PACK, the data remains. The analyzer counts those ghosts. It also checks
the arithmetic every intact DBF must satisfy — header length + records ×
record length ≈ file size — which instantly exposes truncated transfers and
corrupt record counts.
Frequently asked questions
Is my file uploaded anywhere?
No. The parser is ~400 lines of JavaScript running in your browser tab; the file is read with the FileReader API and never transmitted. You can verify this in your browser’s developer tools (Network panel — no requests fire when you drop a file), or run the analyzer with the network disconnected. Business data in DBF files is exactly the kind of thing that should not be uploaded to random websites.
Which formats are supported?
All mainstream xBase table formats: dBase III+/IV/5, FoxBASE, FoxPro 2.x, Visual FoxPro (including DBC-container tables, autoincrement and Varchar variants) and Clipper — including Clipper’s >255-character field convention. Advantage proprietary .adt tables, Paradox .db and the .dbc container itself are different formats; if you are dealing with those, talk to us.
What is the maximum file size?
The whole file is read into browser memory, so a few hundred MB is fine on a normal machine (DBF itself caps at 2 GB). For the deleted-record scan the analyzer processes the full data area; on very large files that scan is skipped automatically and the structural analysis still works.
The analyzer says my memo file is missing. What does that mean?
Your table stores long text (memo fields) in a companion file — .fpt for FoxPro, .dbt for dBase. The DBF itself only holds block pointers. If the companion was lost or separated from the table, those fields are gone. Drop the .fpt/.dbt together with the .dbf and the analyzer will confirm the pairing.
Can you help with a corrupted or unreadable DBF?
Usually, yes — truncated files, wrong codepages, orphaned memo pointers and broken indexes are recoverable more often than not. That work is part of our DBF data migration service, and a quick look costs nothing: send us the analyzer’s report (the report contains structure only, no data).