Free online DB to DBF converter

A legacy GIS, accounting, or reporting program may require a standalone .dbf table while the data is stored in a .db database. Conversion exports selected records into the older dBase format, but it does not preserve the source database's full structure.

What the DB format is

.db is a generic database filename extension, not one universal format. In this context it may identify a SQLite database, a proprietary application database, Berkeley DB, or another database engine. The creating application or database signature must be identified before choosing a conversion method.

SQLite files commonly contain multiple tables, indexes, views, constraints, and triggers in one file. A SQLite-specific converter cannot read every file named .db. For a suspected SQLite file, run sqlite3 source.db ".tables"; a table listing confirms that the SQLite command-line tool can open it. Use sqlite3 source.db ".schema table_name" to inspect the table structure.

What the DBF format is

.dbf is the table format associated with dBase and FoxPro. It stores rows and columns in a standalone file and is supported by many older accounting, GIS, spreadsheet, and desktop database applications. A shapefile normally uses a DBF file for its attribute table.

DBF is suitable when the receiving application expects a simple table without a database server. A typical DBF file represents one table, not an entire relational database. Common legacy dialects restrict field names to 10 characters and provide basic character, numeric, date, and logical fields. Tables, relationships, indexes, views, triggers, constraints, permissions, and application logic from the source are not carried over.

How to convert DB to DBF

For a one-time conversion, use the converter on 101convert.com without installing software. Upload the .db file, select DBF when the source type is recognized and the required table can be selected, start the conversion, and download the result. A generic .db file may not be identifiable; in that case, open it with the application that created it and export the required table as CSV or use that application's DBF export.

For a SQLite database, a controlled script gives better control over table selection and data types. Install the Python package:

pip install dbf

The following example exports three columns from a customers table:

import sqlite3
import datetime
import dbf

source = sqlite3.connect("source.db")
rows = source.execute(
    "SELECT id, name, created FROM customers"
).fetchall()

output = dbf.Table(
    "customers.dbf",
    "id N(10,0); name C(80); created D"
)
output.open(mode=dbf.READ_WRITE)

for customer_id, name, created in rows:
    created_date = (
        datetime.date.fromisoformat(created[:10])
        if created else None
    )
    output.append((customer_id, name, created_date))

output.close()
source.close()

Change the SQL query and DBF definition to match the source. Use C(length) for text, N(width,decimals) for numbers, D for dates, and L for logical values. Convert timestamps, nulls, JSON, and other non-DBF values explicitly rather than allowing them to be guessed as text.

A graphical alternative is to export the selected table to CSV from the source application, then open the CSV in software that supports dBase output and choose File → Save As or File → Export with DBF or dBase selected. Confirm the delimiter, character encoding, date interpretation, decimal separator, and numeric columns before saving. CSV is only an intermediate table, so it does not preserve indexes, relationships, or database types reliably.

Quality and compatibility limits

Conversion is normally lossy. A source database with several tables requires a separate DBF file for each exported table. Foreign keys, joins, formulas, indexes, permissions, triggers, and application logic must be recreated separately.

BLOBs, long text, JSON, high-precision decimals, timezone-aware timestamps, and Unicode characters may be truncated, rounded, rejected, or converted to text. Older dBase programs may not support long field names, large character fields, memo fields, null values, or newer date-time variants. Use the DBF dialect and code page required by the destination program; UTF-8 support varies, and many older programs expect a legacy encoding such as Windows-1252.

After conversion, compare source and output row counts, inspect nulls, dates, decimal precision, accented characters, and maximum text lengths, then open the file in the actual destination application. Keep the original .db file because DBF cannot generally reproduce the complete source database.