DBF to CSV Converter
Stuck with a .dbf file from a dBase, FoxPro, or Clipper application — or pulled from an ESRI shapefile — and need the data in something your spreadsheet or pipeline can actually read? This tool parses the binary DBF format and exports a clean .csv file entirely in your browser, with no uploads and no server involved.
Common Use Cases
- Migrating legacy dBase / Clipper applications — Teams retiring a FoxPro or Clipper system often need to export its tables to CSV so the data can be imported into a modern database like PostgreSQL or loaded into Excel for review before migration.
- Extracting attribute tables from ESRI shapefiles — Every shapefile ships with a companion
.dbfholding the attribute data. GIS analysts regularly need that attribute table in CSV to join with external datasets or import into QGIS, pandas, or Power BI without loading the full shapefile. - Reading municipal and government open-data exports — Many county assessor offices, census tools, and older GIS portals still publish data as
.dbfarchives. Converting to CSV is the first step to making that data usable in any modern tool. - Sensitive HR or financial records in local environments — Legacy payroll and accounting software built on dBase stores employee and financial tables in DBF. Because this tool runs entirely in the browser, the file never leaves the device — important when data contains PII or regulated financial records.
- Feeding ETL pipelines from old point-of-sale or inventory systems — Older retail and warehouse management systems exported inventory snapshots as DBF. Converting these to CSV lets you pipe the data into a modern Parquet pipeline or a cloud data warehouse without a proprietary reader.
- One-off data rescue from unmaintained software — When a vendor goes out of business or support ends, DBF files are often the only remaining artifact of years of operational data. This tool lets you extract that data without finding a working copy of the original application.
Example Conversion
Input: parcels.dbf — an ESRI shapefile attribute table with 14 columns (PARCEL_ID, OWNER, ADDRESS, ZONING, ACRES, ASSESSED_V, YEAR_BUILT, and 7 more), 22,400 records, encoded in CP1252 (Windows Latin-1), exported from ArcGIS 10.3.
Output: parcels.csv — a UTF-8 encoded comma-separated file with a header row using the original field names and all 22,400 data rows. Numeric fields like ACRES and ASSESSED_V are written as plain numbers; date fields like YEAR_BUILT are written in YYYYMMDD format as stored in the DBF.
The most likely confusion point in this conversion is character encoding. DBF files rarely declare their encoding explicitly — older dBase III and FoxPro files typically use DOS code pages (CP437 or CP850), while files created on Windows tools use CP1252. This tool reads the header's language driver byte where present, but many files omit it. If field values containing accented characters or special symbols appear garbled in your CSV, the original file used a DOS code page; the practical fix is to open the CSV in Excel and specify the encoding manually during import, or to use an encoding converter to re-encode the output.
A second subtle issue: DBF field names are capped at 10 characters. A column that was ASSESSED_VALUE in the source application becomes ASSESSED_VA in the DBF and in the resulting CSV header. If you're joining this CSV to another dataset by column name, check truncated headers carefully before assuming a mismatch.
About This Tool
The DBF to CSV Converter parses the binary DBF file format in your browser using JavaScript ArrayBuffer and DataView APIs — no server, no library download, no proprietary reader required. It reads the file header to discover the record count, field definitions, and data offset, then walks each record and serialises the values to RFC 4180-compliant CSV.
The tool supports DBF versions 0x03 (dBase III Plus), 0x04 (dBase IV), 0x05 (dBase V), 0x83 (dBase III with memo), 0xF5 (FoxPro with memo), and 0x30/0x31 (Visual FoxPro). Field types C (Character), N (Numeric), F (Float), D (Date), L (Logical), and M (Memo) are all handled. Deleted records — those marked with a 0x2A deletion flag — are skipped and reported in the warnings panel.
CSV is the right output format here because it opens in every spreadsheet, database importer, and scripting environment without a driver. DBF, by contrast, requires either a legacy runtime or a specialised reader. That said, if your end target is a columnar analytics store, consider converting the resulting CSV to Parquet afterward — Parquet will be significantly smaller and faster to query on large datasets.
This tool is particularly useful for GIS practitioners who need the .dbf attribute table from a shapefile without loading the geometry, and for anyone maintaining data from Borland Delphi, Clipper, or ACCPAC applications that are no longer in production.
How It Works
.dbf file from a dBase, FoxPro, Clipper, or ESRI shapefile export. The file is read into an ArrayBuffer locally — nothing is sent to a server at any point.C/N/D/L/M/F), and length — building the column layout. Finally it walks all data records, skipping deleted rows, and trims trailing whitespace from character fields (DBF pads all fields to fixed width with spaces).DBF vs CSV: Which Format and When
DBF is a binary, fixed-width, self-describing format — it stores field names, types, and lengths in the file header, meaning a reader doesn't need any external schema. That structure made it ideal for embedded database applications in the 1980s and 1990s. CSV is a plain-text, delimited format with no built-in type information — every value is a string until the consuming application interprets it.
In practice, DBF wins on nothing in a modern workflow. No major database, spreadsheet, or analytics tool opens DBF natively in 2026 without a plugin or ODBC driver, while every tool on the planet reads CSV. The only reason to stay in DBF is if you're actively writing back to an application that requires it — if you're only reading the data, CSV is unambiguously the right extraction target.
The one real loss in conversion is type metadata: a DBF N field with 2 decimal places becomes a string like 123.45 in CSV, and downstream tools must re-infer that it is numeric. For most use cases this is a non-issue, but if you are loading the CSV into a typed database, define the schema explicitly rather than relying on automatic type inference — especially for numeric fields that could look like integers in some rows.
Limitations
- Memo fields are exported as empty strings — DBF memo fields (
Mtype) store their content in a separate.fptor.dbtfile. This tool only reads the.dbffile itself, so memo content cannot be extracted. The field name will appear in the CSV header, but the column will be blank. - Character encoding is not auto-detected — If the DBF's language driver byte is missing or generic, the tool reads bytes as Latin-1 (ISO-8859-1). Files encoded in DOS code pages (CP437, CP850) will show garbled characters in fields containing non-ASCII text such as accented letters or box-drawing characters.
- Field names are capped at 10 characters — This is a DBF specification limit, not a tool limitation. Column names longer than 10 characters were silently truncated when the original DBF was created, so that truncation will be reflected in the CSV headers.
- Very large files may be slow in-browser — DBF files over ~50 MB with millions of records will process correctly but may take several seconds since all parsing runs on the main JavaScript thread. Files above 200 MB are not recommended for browser-based conversion.
- Visual FoxPro NullFlags and _NullFlags columns — VFP adds a hidden
_NullFlagsfield to tables that support nullable columns. This tool will include that field in the CSV output with its raw binary value. You can safely delete that column after conversion.
🔒 Privacy & Security
All processing is performed locally using the Web File API and JavaScript ArrayBuffer. Your file is never sent to a server — suitable for sensitive or private content including HR records, financial tables, or regulated data exports.