CSV to DBF Converter

Common Use Cases

• Legacy FoxPro and dBase applications — Older business systems built on Visual FoxPro, dBase IV, or Clipper often have no CSV import path. DBF is the only format these applications accept natively, making this conversion unavoidable in maintenance scenarios.
• Esri Shapefile attribute tables — Every .shp file ships with a paired .dbf that stores feature attributes. If you have attribute data in CSV form, converting it to DBF is the correct way to attach it to a shapefile without reprojecting through ArcGIS or QGIS import workflows.
• Manufacturing and logistics on Clipper-based systems — Clipper-compiled applications, particularly common in inventory management and warehouse software from the 1990s, still run in many production environments. They consume DBF directly, with no migration budget in sight.
• Crystal Reports and older BI templates — Some Crystal Reports templates built against dBase data sources expect a .dbf file as their primary data connection. Replacing the underlying DBF with a refreshed CSV-converted version avoids full report redesign.
• Data migration staging — When migrating from modern SQL exports to a legacy ERP or government system, DBF is sometimes required as the intermediate staging format before the system's own import routine takes over.
• Local government and archival systems — County assessors, land registries, and municipal archival platforms in some jurisdictions still use DBF as their interchange format. Exporting from a modern spreadsheet and converting here avoids any server-side dependency when the data is sensitive.

Example Conversion

Input: inventory.csv — 1,240 rows, 7 columns: ItemCode, Description, Quantity, UnitPrice, Warehouse, LastUpdated, Active.

Output: inventory.dbf — 1,240 records in dBase III+ binary. The generated field descriptors look like this:

The most likely confusion point here is fixed-width padding: DBF does not support variable-length character fields. If your Description column has one value that is 30 characters long, every record's DESCRIPTIO field occupies exactly 30 bytes — even the three-word entries. This inflates file size compared to CSV when data is sparse, but it is a hard constraint of the format. The other surprise: LastUpdated and Description both get their field names silently truncated to 10 characters, which matters if you have two columns whose names only differ after the tenth character — they will collide and one will overwrite the other in the output. If that applies to your data, rename the columns in the CSV before converting.

About This Tool

The CSV to DBF Converter produces a valid dBase III+ binary file (version byte 0x03) from any well-formed CSV. The tool reads the header row to generate field descriptors, scans each column to infer whether the type should be C (character) or N (numeric), sets field widths to the maximum value length found in the data, and assembles the binary header, field descriptor array, and fixed-width record block in memory before offering a download.

DBF is not a format you choose because it is good — you choose it because something downstream requires it. If your target system is Visual FoxPro, ArcGIS shapefile tooling, or a Clipper-compiled application, DBF may be the only path forward. If you are working entirely within modern tooling, stay with CSV — there is no reason to introduce a binary fixed-width format into a pipeline that does not need it.

Because everything runs client-side using the Web File API and JavaScript ArrayBuffer, the tool is suitable for inventory lists, employee records, or any other data you would not want transmitted to a third-party server. The file is never uploaded anywhere.

How It Works

CSV vs DBF: Which Format Is Right Here?

CSV is plain text, universally readable, and trivially inspectable with any text editor, spreadsheet, or command-line tool. DBF is a binary fixed-width format from the dBase era — structured, typed, and opaque to anything that does not explicitly support it.

The practical rule: use CSV everywhere you have a choice; use DBF only when a specific system demands it. DBF's fixed-width record structure makes random-access reads faster on spinning disk, which mattered in 1984 and is almost never relevant today. What does still matter is compatibility: FoxPro applications cannot open a CSV natively, Esri shapefiles require a paired .dbf, and Clipper runtimes have no alternative path.

One genuine advantage DBF has over CSV is embedded type enforcement. A N(10,2) DBF field guarantees every value is numeric to two decimal places — something a CSV cannot express without a schema sidecar. If your downstream system uses those type declarations to drive behavior (format masks, sort order, calculation routines), stripping them out by staying in CSV will break things. That is not a reason to prefer DBF; it is a reason to convert when the destination requires it.

If your end goal is Excel rather than a legacy application, a spreadsheet tool is a better fit. If you are working in the other direction — extracting data from an existing DBF — use the DBF to JSON converter instead.

Limitations

• Field name truncation is silent by default — Column names longer than 10 characters are truncated without error. If two columns share the same first 10 characters (e.g., CustomerName and CustomerNotes both become CUSTOMERNA), the second will silently collide with the first in the output field map. Check the field descriptor table after converting.
• dBase III+ format only — This tool produces version byte 0x03. FoxPro memo fields (M type), dBase IV extended headers, and Visual FoxPro-specific field types (I, B, V) are not produced. If your target application requires a newer DBF variant, verify compatibility before use.
• Date columns are treated as character strings — DBF has a native D (date) field type, but it requires values in exactly YYYYMMDD format (no dashes, no slashes). Because CSV date formatting is inconsistent, this tool converts all date-like columns as C fields rather than risk silent data corruption. Reformat your date column to YYYYMMDD before converting if your target application needs a true D field.
• Fixed-width overhead on sparse data — If one row has a 200-character notes field and all others are under 30 characters, every record will consume 200 bytes for that column. The resulting DBF may be significantly larger than the source CSV.
• Non-ASCII characters in field values — DBF stores characters as raw bytes without a declared encoding. Values with accented characters, CJK, or Unicode beyond Latin-1 will be stored as-is, but the consuming application may misinterpret them if it assumes a specific code page (commonly CP1252 or CP850 in legacy dBase software).