DBF to CSV Converter

A format from 1983 that you still run into

dBASE gave the world the .dbf table, and the format proved far more durable than the software. FoxPro and Clipper adopted it, thousands of accounting, inventory, payroll and point-of-sale systems wrote their data in it, and it is still the container every GIS shapefile uses for its attribute table. Forty years on, a fixed-width header declaring each column’s name, type and width followed by fixed-width rows turns out to be an unusually good way to make data outlive the program that produced it.

Which is why people still arrive with one. Either something exported it — because .dbf was the natural choice when that software was written — or a shapefile lost its companion files and the attribute table is what survived. CSV is what you want next: readable in anything, importable everywhere, and no longer dependent on a format only legacy tools speak.

The code page problem, which is where most converters fail

A .dbf predates the idea that a file should declare its text encoding. What it has instead is a single byte in the header — the language driver identifier — naming the code page the text was written in. Ignore that byte, assume everything is one encoding, and every Hebrew, Cyrillic, Greek or accented name in the file comes out as mojibake. That is the single most common complaint about DBF exports, and it is entirely avoidable.

This reads the byte and decodes accordingly, across the Windows, DOS and Mac code pages that dBASE and FoxPro actually used in practice — Hebrew, Cyrillic, Greek, Turkish, Baltic, Central European, Thai, Chinese, Japanese and Korean among them. When the header names nothing, UTF-8 is tried first and a legacy fallback that maps every possible byte second, so the conversion can never die two-thirds of the way through on a single awkward character. The CSV is then written with a byte-order mark, because Excel reads unmarked UTF-8 as mojibake and undoing correct decoding at the last step would be a strange way to finish.

Deleted rows, and why they are still in your file

dBASE never actually removed a deleted record. It set a flag on the row and moved on, leaving the data in place — which means a table that has been in use for twenty years may still contain records deleted a decade ago. Every database and GIS tool hides them, and this converter does too: exporting them would hand back data whose owner deliberately deleted it, which is not a conversion, it is a recovery no one asked for.

Types are carried across as far as CSV permits. Numbers stay numbers instead of becoming space-padded text, logical columns become True and False, and dates are rewritten as ISO 2024-01-31 so they sort correctly and cannot be misread as one date order or the other. Cells that dBASE filled with asterisks because the value overflowed the column are treated as missing rather than exported literally.

Where to go from here

For a spreadsheet with typed cells rather than text, DBF to XLSX writes a real worksheet, though with a lower row ceiling since building one costs considerably more. If you want to query the data instead of browse it, run this CSV through CSV to SQLite and you have a database you can put SQL against. And the whole conversion is on the API at /api/convert/dbf-to-csv if you have an archive of tables to work through.