JSON to DBF Converter

Common Use Cases

• Shapefile attribute table rebuild — QGIS and ArcGIS store feature attributes in a .dbf sidecar file. When attribute data lives in a REST API or GeoJSON export, this tool lets you rebuild the .dbf from JSON without touching the geometry files.
• FoxPro and dBASE legacy integrations — Older accounting, inventory, and payroll systems built on Visual FoxPro often still require .dbf imports. Exporting from a modern JSON API and re-importing via this tool bridges the gap without a custom ETL script.
• Government and municipal data portals — Many open data portals publish datasets in JSON format, but downstream GIS workflows or legacy desktop tools at city and county agencies expect DBF. Converting locally avoids sending potentially sensitive civic data through a third-party web service.
• Audit-trail exports for legacy reporting — Finance and compliance teams running Crystal Reports or similar tools tied to dBASE-compatible drivers can receive JSON event logs converted to DBF and load them without changing their reporting infrastructure.
• Field data collection round-trips — Survey tools like Survey123 and KoboToolbox export JSON. If the downstream analysis step runs in a DBF-aware tool such as MapInfo or an older ESRI desktop product, this converter closes the format gap without an intermediary CSV step.
• Quick one-off data handoffs — A developer who needs to hand tabular JSON to a colleague with only DBF-reading software can do the conversion here without writing a Python script or installing a command-line tool. If you regularly produce DBF from flat structured data, also see our JSON to CSV converter for cases where the downstream system will accept either format.

Example Conversion

Input: A parcels.json file exported from a city parcel API — 1,240 records, each with fields like parcel_id, owner_name, assessed_value, vacant, and last_updated.

Output: parcels.dbf — a dBASE III file with five fields: PARCEL_ID as C(10), OWNER_NAME as C(23), ASSESSED_V as N(9,0), VACANT as L(1), and LAST_UPDAT as C(10).

The most common confusion point here is field name truncation. DBF field names are limited to 10 characters, so assessed_value becomes ASSESSED_V and last_updated becomes LAST_UPDAT. If two JSON keys collide after truncation and uppercasing — for example start_date_1 and start_date_2 both becoming START_DATE — the converter will append a numeric suffix to deduplicate them. Check the field mapping table after conversion to confirm the final names before opening the file in QGIS or ArcGIS.

Date values stored as ISO strings ("2024-11-01") are treated as character fields by this tool. If your GIS software requires native DBF date type D, pre-format the values in your JSON as 8-character strings in YYYYMMDD order and the tool will still store them as C(8). A true D type field is rarely needed unless the downstream app explicitly sorts or filters on the date column.

About This Tool

The JSON to DBF Converter reads a .json file, parses it as an array of objects, infers a DBF field type for each JSON key, and writes a binary dBASE III file directly in your browser. The output is compatible with QGIS, ArcGIS, MapInfo, Visual FoxPro, and any application that can open standard .dbf files. No server receives your data at any point.

Field types are assigned by scanning all values for a given key: all-boolean values produce a L (Logical) field, all-numeric values produce an N (Numeric) field with decimal count inferred from the data, and everything else produces a C (Character) field sized to the longest value. If a character value exceeds 254 bytes — the DBF maximum — it is truncated and a warning is shown. For structured data with longer text blobs, the JSON to CSV converter will preserve the full content without field length limits.

DBF is not the right format for every tabular dataset. If your downstream system will accept CSV, prefer CSV — it is easier to inspect, has no field-length limits, and is supported universally. DBF is the correct choice specifically when the receiving software requires it: GIS attribute sidecars, FoxPro import wizards, and certain legacy ODBC drivers that do not have a CSV fallback.

How It Works

JSON vs DBF — When to Use Each

JSON is the better format for almost every modern application: it supports nested objects, arrays, arbitrary string length, Unicode natively, and is readable in any text editor. Every REST API, web framework, and data pipeline tool works with JSON without configuration. If you control the full stack, keep your data in JSON.

DBF exists because GIS tools — particularly the Shapefile specification designed by ESRI in the early 1990s — baked in the format as the attribute table standard, and that dependency has never been cleanly replaced. QGIS, ArcGIS Desktop, MapInfo, and many CAD/GIS import wizards still read and write .dbf files as part of the Shapefile bundle (.shp, .shx, .dbf). For anything outside that specific ecosystem, DBF adds friction without benefit.

The sharpest practical difference: JSON lets a field hold a 50,000-character string or a deeply nested object; DBF caps character fields at 254 bytes and cannot represent nested data at all. If your JSON source contains arrays, objects-within-objects, or long text, you must flatten and truncate before conversion — there is no lossless round-trip from complex JSON to DBF.

Limitations

• Top-level array required — The JSON file must be a flat array of objects ([{…},{…}]). A top-level object, array of arrays, or mixed-type array will produce an error. Wrap single-record objects in an array before converting.
• 128-field maximum — dBASE III supports at most 128 fields per record. JSON objects with more than 128 keys will have the excess fields silently dropped. A warning is shown listing the truncation.
• No native date type — Date values are stored as C (character) fields unless every value in the column is exactly 8 characters in YYYYMMDD format, in which case the tool writes a D type field. ISO 8601 strings with separators (2024-11-01) are stored as C(10) and will not sort or filter correctly as dates in GIS tools.
• Character field truncation at 254 bytes — Any string longer than 254 bytes is cut off. This is a hard limit of the DBF format. Multi-byte UTF-8 characters count toward the byte limit, not character count, so a field with 200 Chinese characters may be truncated much earlier than expected.
• Mixed-type columns default to character — If a JSON field contains both numbers and strings across different records, the whole column is typed as C. The tool does not attempt to coerce mixed columns. Clean the data before converting if you need a true N field.
• No memo (M) field support — Long text that would normally use a DBF memo field (.fpt or .dbt sidecar) is not supported. This tool produces self-contained single-file output only.