How to Use the Csv To Dbf: Step-by-Step Tutorial

The Csv To Dbf Converter runs entirely in your browser — your .csv file is never sent to any server, no account is required, and no data leaves your device. This tutorial walks through every step: opening the tool, loading a CSV, running the conversion, reading the stats panel, reviewing the inferred schema, auditing the column-name map, choosing an output codepage, and exporting a valid dBase III+ .dbf. It also covers the most common problems you will encounter with real-world CSVs and how to resolve them.

Connect on LinkedIn →

Step 1 — Open the Tool

Open the Csv To Dbf Converter. You will see a drop zone labelled Drop a .csv file here, or browse, a schema preview panel (empty until a file is loaded), and a Download DBF button (disabled until the conversion completes). The tool is a single page — no login, no setup, no network request made for your file.

If this is your first visit, glance at the trust badges in the header: All processing in your browser, No uploads stored, No login required. These are not marketing copy; they reflect that the entire conversion runs in the JavaScript engine of the tab you are looking at. You can verify this by opening your browser’s developer tools (F12 → Network), loading a CSV, and observing that no request carries the file contents.

Step 2 — Load Your CSV File

There are two ways to load a file:

1. Drag and drop. Drag a .csv file from your desktop, Finder, or file explorer onto the drop zone. The zone highlights while you hover. Release.
2. Browse. Click the browse link inside the drop zone. A file picker opens. Select your .csv and click Open.

Once loaded, a filename bar appears above the drop zone showing the selected file, for example 📎 orders.csv with a small × to clear the selection. The file is now in browser memory; it has not been uploaded anywhere.

Accepted file types: Any file with a .csv extension, or a plain-text file with comma, semicolon, tab, or pipe delimiters. The tool auto-detects the delimiter from the first line. If you have a fixed-width or JSON file, convert to CSV first — this tool expects a delimited text file with a header row.

File size: Up to approximately 200 MB on a desktop browser with adequate RAM. Mobile browsers or low-memory devices should stay well under that. If the file is too large, use a server-side Python conversion instead; browser memory is the practical ceiling.

Step 3 — Click Convert to DBF

With a file loaded, the Convert to DBF button becomes active. Click it. The tool reads the header row, samples every data row to infer column types and lengths, assembles the dBase III+ binary in memory, and reveals the preview panel below.

For a typical CSV of a few thousand rows and 10–20 columns, this completes in well under a second. For larger files, a progress indicator appears. The tool processes every row — it does not sample only the first N rows — because a single long value anywhere in the column changes the required field length, and a mistakenly undersized field would silently truncate data on write.

Step 4 — Read the Stats Panel

Once the conversion completes, a stats panel displays:

• Rows: the number of data rows (the header row is not counted).
• Columns: the number of fields in the output DBF.
• Codepage: the codepage selected for the output (Windows-1252 by default).
• Warnings: a count of any rows that required coercion, truncation, or replacement-character substitution during the write.

Scan the stats panel first. If the row count matches what you expected from the source CSV, and the warnings count is zero, the conversion is clean. If warnings are non-zero, expand the panel to see which rows and columns were affected — most commonly a Character column whose widest value exceeded 254 bytes and was truncated, or a cell containing bytes not representable in the chosen codepage.

Step 5 — Review the Schema Summary

Below the stats panel is a schema table. It lists each output DBF column with:

• Field name: the sanitised DBF name (up to 10 printable ASCII characters, uppercase).
• Type: the inferred DBF type — C (Character), N (Numeric), L (Logical), or D (Date).
• Length: the field width in bytes.
• Decimals: the decimal count, used only for Numeric columns.
• Sample: the value from the first data row, so you can spot-check the interpretation.

Skim the table and confirm each column’s type is what you expected. The two most common surprises are (1) a numeric ID that appears as Character because one row contains a stray non-digit (often a trailing space or a dash), and (2) a date column stored as Character because the source CSV mixes date formats. If you see either, fix the upstream CSV rather than accepting an unintended type — a downstream DBF consumer that expects a Numeric ID will reject a Character column with the same name.

Step 6 — Audit the Column-Name Map

DBF field names cannot exceed 10 printable ASCII characters. The converter sanitises every CSV header to fit this constraint and shows the mapping in a small rename panel next to the schema table. Typical renames:

• Customer Name → CUSTOMER_N (spaces become underscores, uppercased, truncated to 10).
• Order # → ORDER (the # is stripped).
• Total (USD) → TOTAL_USD (parens and space removed).
• 2024_revenue → _2024_REVE (a leading digit is prefixed with an underscore so DBF readers do not mistake it for a reserved identifier).

If two CSV columns sanitise to the same DBF name, a numeric suffix disambiguates them (for example, ORDER and ORDER2). The rename panel shows these disambiguations explicitly. Audit them — downstream code that refers to DBF fields by name will need to match the sanitised names, not the original CSV headers.

Step 7 — Choose the Output Codepage

Expand the advanced settings (below the Download button) to see the codepage selector. The default is Windows-1252 (language driver 0x03), which is the most broadly compatible codepage for FoxPro and Clipper consumers in Western locales. Change the codepage only if you know your target consumer expects something specific:

• CP437 (OEM US): very old DOS-era dBASE III readers, or command-line dBASE utilities.
• CP850 (OEM Multilingual): Western European DOS readers.
• CP936 (Simplified Chinese GBK): for CSVs containing CJK characters intended for a consumer that expects GBK-encoded DBF data.
• CP1251 (Cyrillic): for CSVs containing Russian, Ukrainian, Bulgarian, or other Cyrillic-script text.
• UTF-8: for modern FoxPro-extended readers and ArcGIS/QGIS shapefile tooling that writes a .cpg sidecar.

If you are writing the .dbf for a shapefile, also provide a companion .cpg file (a one-line text file naming the codepage) alongside the .shp, .shx, and .dbf so modern GIS tools can decode it correctly.

Step 8 — Download the DBF

Click Download DBF. The file is saved with the same base name as the input but with a .dbf extension — orders.csv produces orders.dbf. If you need a different filename, rename the file after download.

You can also click Copy Schema to Clipboard (if exposed by your build) to copy the inferred schema as a JSON blob — useful for documenting the field layout alongside the binary, or for feeding a downstream code-generation step.

Open the downloaded .dbf in your target application (FoxPro, Clipper tooling, ArcGIS, QGIS, or whatever consumes it) and confirm the field types, lengths, and first few rows match expectations. Catching a misinterpretation here is far cheaper than debugging a downstream pipeline.

Troubleshooting Common Problems

“My numeric ID lost its leading zeros.” A column sampled as entirely numeric becomes a DBF Numeric field, which strips leading zeros on write. If the zeros carry meaning (ZIP codes, SKUs, fixed-width identifiers), the column is semantically a string — even though it looks numeric. Pre-quote the column in the source CSV, or prefix every cell with a non-digit character that you strip downstream. The converter will then type it as Character and preserve the exact byte sequence.

“A date column is stored as Character instead of Date.” DBF Date inference requires every non-empty value in the column to match one of the recognised date patterns (ISO YYYY-MM-DD, slash-separated YYYY/MM/DD, or MM/DD/YYYY with a four-digit year). One cell in an unexpected format forces the entire column to Character. Normalise the dates upstream in the CSV (a quick awk or Python one-liner usually fixes it) and re-run the conversion.

“My accented text shows as question marks in the output.” This is a codepage mismatch. The source CSV contains bytes not representable in the default Windows-1252 codepage. Either switch to a codepage that covers your characters (CP1251 for Cyrillic, CP936 for Chinese, etc.), or switch to UTF-8 if your downstream consumer supports it.

“A Character column got truncated.” DBF Character fields are capped at 254 bytes. If the widest cell in your source column exceeds 254 bytes after encoding, the converter truncates on write and flags the affected rows in the stats panel. Split the oversized column upstream (into, for example, NOTES_A and NOTES_B), or accept the truncation for the rare case where that is the correct behaviour.

“Two columns collapsed into one after sanitization.” Two CSV headers sanitised to the same 10-character DBF name. The converter disambiguated them with a numeric suffix, but if your downstream code expects specific names, rename the CSV columns upstream to avoid the collision.

“My boolean column is a Character field showing ‘true’ and ‘false’.” DBF Logical inference requires every cell to be one of a small set of recognised truthy/falsy tokens (true/false, t/f, yes/no, y/n, 1/0). If your CSV uses non-standard tokens like Y and blank, or mixes conventions within the same column, it falls back to Character. Normalise the values upstream.

Worked Example

Here is a concrete walkthrough using a small CSV. Paste this into a file called orders.csv:

ORDER_ID,CUSTOMER,AMOUNT,SHIPPED
1001,Acme Corp,1250.00,true
1002,Widgets Ltd,  899.50,true
1003,Example Inc,3000.00,false

Convert using the tool:

1. Open the Csv To Dbf Converter.
2. Drag orders.csv onto the drop zone, or click browse and select it.
3. The filename bar shows: 📎 orders.csv.
4. Click Convert to DBF.
5. The stats panel shows: Rows: 3 · Columns: 4 · Codepage: Windows-1252 · Warnings: 0.
6. The schema table shows the four columns: ORDER_ID (N, length 4, decimals 0), CUSTOMER (C, length 11), AMOUNT (N, length 7, decimals 2), SHIPPED (L, length 1).
7. Because the CSV headers all fit within the 10-character constraint already, the column-name map is an identity map — no renames.
8. Leave the codepage at Windows-1252.
9. Click Download DBF. The file is saved as orders.dbf.

Inspect the output: Open orders.dbf in FoxPro, dBASE, or any DBF reader. You should see three records with four columns. ORDER_ID values are integers (1001, 1002, 1003). CUSTOMER values are space-padded strings trimmed on read. AMOUNT values preserve two decimal places. SHIPPED is a boolean column with T for the first two rows and F for the third.

Now try with a problematic column: Add a fifth column to the CSV with US ZIP codes that have leading zeros, for example 01234, 02345, 03456. Re-upload and convert. You will see that the ZIP column is typed as N (Numeric) and the leading zeros are lost on read (values become 1234, 2345, 3456). To preserve the zeros, pre-quote the column in the CSV ("01234") or rename the column with a non-digit prefix so the converter treats it as Character. This is the single most common gotcha when feeding CSV data into DBF consumers.

For a deeper explanation of the DBF format, the file header byte layout, type inference rules, and codepage handling, see the Complete Guide to Csv To Dbf.