The Complete Guide to Json To Dbf: Everything You Need to Know

JSON is the lingua franca of modern web APIs, JavaScript applications, and configuration files. DBF — the dBASE database format — predates JSON by two decades and remains the data substrate for QGIS attribute tables, ArcGIS shapefiles, FoxPro applications, and a long tail of legacy accounting, inventory, and records systems. The two formats are separated by a generational gap in tooling, but they meet in a surprisingly large number of practical workflows: GIS pipelines, legacy system integrations, and any environment where modern JSON output must feed a tool that speaks only dBASE.

The gap creates a concrete problem: a developer produces a JSON array of objects from an API, a database query, or a fake data generator, and a downstream tool — a GIS layer editor, a vintage FoxPro report generator, an archival records system — accepts only DBF. Manually writing a DBF file is non-trivial: the format specifies a fixed-width binary header, field descriptors with exact byte offsets, per-field type codes, and a padded record layout with a specific terminator. Converting JSON to DBF on the command line typically means installing a Python library like dbfread or simpledbf, writing a small script, and handling type inference by hand.

The JSON to DBF Converter on this site does the conversion entirely in your browser. Drop in a .json file containing an array of objects, and it writes a valid dBASE III .dbf file with field types inferred automatically from your data. No upload, no server processing, no login. This guide explains the DBF format, how the converter infers field types, what limitations matter, and the best practices developers should follow when producing DBF output for GIS and legacy systems.

Connect on LinkedIn →

What Is the DBF Format?

DBF is a binary, fixed-width, row-oriented database file format originally defined by the dBASE database management system in 1980. The format was extended by subsequent dBASE versions (III, IV, 5, 7), adopted by FoxPro and Visual FoxPro, and became the de facto attribute-table format for ESRI shapefiles — meaning that every shapefile you see in the wild carries a companion .dbf file holding the non-geometric attributes of each feature.

The physical structure of a DBF file is straightforward:

• File header (32 bytes). The first byte identifies the DBF version (0x03 for dBASE III without memo, 0x83 with memo, 0x30 for Visual FoxPro). The next three bytes are a YYMMDD last-update date. Bytes 4–7 hold the record count as a little-endian 32-bit integer. Bytes 8–9 hold the header length, and bytes 10–11 hold the record length — both little-endian 16-bit.
• Field descriptor array. Immediately after the file header, one 32-byte descriptor appears for each field. Each descriptor contains the field name (11 bytes, null-padded, ASCII, uppercase by convention), the field type (1 byte: C for Character, N for Numeric, L for Logical, D for Date, M for Memo, F for Float), the field length (1 byte), and the decimal count (1 byte, used only for numeric fields).
• Header terminator (1 byte). The descriptor array ends with a 0x0D carriage return byte.
• Records. Every record has the same fixed length, computed as the sum of all field lengths plus one byte for a deletion flag (the leading byte: 0x20 space for active records, 0x2A asterisk for deleted records). Fields are stored as ASCII or codepage-specific bytes, left-padded for numeric fields and right-padded with spaces for character fields.
• End-of-file marker (1 byte). The file ends with a 0x1A byte — the ASCII SUB character, retained from CP/M-era conventions.

JSON vs. DBF: Key Differences

Understanding the structural differences between the two formats explains why type inference is necessary and why certain JSON constructs do not translate directly.

• Readability. JSON is plain text, Unicode-aware, and human-readable. DBF is binary and historically tied to single-byte codepages such as CP437 (OEM US) or Windows-1252. Opening a DBF in a text editor shows readable field values interspersed with binary header bytes.
• Schema. JSON is schemaless at the file level — each object may have its own shape. DBF requires every record to have the same fields with identical types and lengths, fixed at write time. The converter derives a single schema by scanning all objects in the array.
• Field names. JSON keys may contain any Unicode characters and any length. DBF field names are limited to 11 ASCII bytes, uppercase by convention, and cannot contain spaces. The converter truncates long keys and uppercases them when writing to DBF.
• Type system. JSON values are strings, numbers, booleans, null, arrays, or objects. DBF supports Character, Numeric, Logical, Date, Memo, and Float. Nested JSON structures (arrays and objects) have no DBF equivalent and are serialized as Character fields.
• Character fields have a hard byte limit. DBF Character fields are capped at 254 bytes per record — a constraint set by the single-byte length field in the field descriptor. Longer strings require either truncation or promotion to a Memo field (stored in a separate .dbt file).
• Nulls. JSON null values have no direct DBF equivalent. The converter writes nulls as empty (space-padded) fields, which most DBF readers interpret as empty strings or zero.

How the Conversion Works

The JSON to DBF Converter parses your JSON file, infers a schema from the data, then writes a binary DBF file byte-by-byte using a Uint8Array buffer. The pipeline has four stages.

Stage 1 — JSON parse and shape validation. The uploaded file is read into a string using the Web File API, then parsed with JSON.parse. The root value must be an array; if it is an object or a scalar, the converter reports an error. Every element of the array must be a flat object (no nested arrays or objects as values). Elements that violate this shape either trigger an error or, depending on context, are serialized to a JSON string for storage in a Character field.

Stage 2 — Schema inference. The converter takes the union of keys across all objects — the superset of fields that will appear in the DBF. For each field, it scans every value across all records to determine the dBASE field type. The inference rules are deterministic and documented in the next section. After scanning, the converter knows the field name, type code (C, N, L), length, and decimal count for every column.

Stage 3 — Header construction. The 32-byte file header is assembled with the current date, the record count, the computed header length (32 + 32 × field count + 1), and the computed record length (1 + sum of field lengths). The field descriptor array is constructed one descriptor at a time, each 32 bytes of null-padded name, type code, length, and decimal count. A 0x0D terminator byte closes the header.

Stage 4 — Record serialization. For each input object, the converter writes a fixed-length record. The leading byte is 0x20 (active). Each field value is formatted according to its type: numeric values are right-aligned and left-padded with spaces; character values are written as-is and right-padded with spaces; logical values become T or F; null values become spaces. A final 0x1A byte closes the file. The complete Uint8Array is wrapped in a Blob with application/x-dbase MIME type and offered for download.

The entire pipeline runs in the browser's JavaScript engine. The JSON file is read into memory and never transmitted to any server. For a JSON file with a few thousand records and 10–20 fields, conversion typically completes in well under a second.

Field Types and Inference Rules

Field types are assigned by scanning all values present for a given key across every record. The rules are:

• Logical (L). Assigned when every non-null value is a JSON boolean (true or false). Length is fixed at 1 byte, storing T or F.
• Numeric (N). Assigned when every non-null value is a JSON number. Field length is derived from the widest textual representation across the data set; decimal count is inferred from the value with the most digits after the decimal point. Integers produce decimal count 0; 3.14159 produces decimal count 5.
• Character (C). The default when values are strings or when types are mixed across records. Field length is set to the byte length of the longest value (truncated at the 254-byte DBF maximum). Mixed-type fields — e.g., a column with both numbers and strings — are promoted to Character, with numeric values written as their string representation.
• Null handling. A field with all-null values defaults to Character length 1. A field with some nulls and otherwise-consistent types uses the non-null type; null records are written as space-padded fields.

The converter displays a schema summary after processing — field name, type code, length, and decimal count — so you can confirm the inference before downloading. If the inferred schema is wrong (for example, an ID column with a leading-zero code has been typed as Numeric, causing loss of the leading zero), adjust the input JSON to force string values and re-convert.

Character Encoding and the 254-Byte Limit

The DBF format predates Unicode. Classic dBASE III files store bytes interpreted by the current codepage — typically CP437 on DOS or Windows-1252 on Windows. Strings containing characters outside the basic ASCII range (accented Latin characters, Greek, Cyrillic, CJK) may be displayed as mojibake in a DBF reader that uses a different codepage than the writer.

The converter writes strings as UTF-8 bytes. Readers that understand UTF-8 (QGIS with a .cpg sidecar file specifying UTF-8, modern FoxPro extensions) will display the data correctly. Readers that assume a single-byte codepage will misdisplay multi-byte characters. If you are writing DBF for a known legacy system, verify its codepage expectation before delivering the file.

The per-field 254-byte cap is a hard structural limit of classic DBF. The converter truncates Character values that exceed 254 bytes and displays a warning listing the affected fields. If a column routinely contains longer text values, a classic DBF file is the wrong format — either use a Memo field (not supported by this converter, but available in dBASE IV and FoxPro .dbt extensions) or switch to JSON to CSV, which preserves full string length without field limits.

Common Use Cases

Feeding attribute data into QGIS and ArcGIS. An ESRI shapefile is a set of files (.shp, .shx, .dbf, and optional .prj/.cpg) where the .dbf carries non-geometric attributes. If you generate geospatial records programmatically from an API or a JSON data source, converting the attribute table to DBF lets QGIS or ArcGIS ingest it alongside the geometry file.

Legacy accounting and inventory systems. FoxPro and dBASE IV remain deployed in vertical-market software for accounting, insurance, records management, and point-of-sale. Modern ETL pipelines often produce JSON; converting that output to DBF allows it to be ingested by a legacy reporting tool or archival system without writing custom adapter code.

Quick one-off data handoffs. A developer who needs to hand tabular JSON to a colleague running software that only reads DBF can do the conversion here without writing a Python script or installing a command-line tool. Common scenarios: delivering data to a GIS consultant, preparing a file for import into a legacy records system, or producing a regression-test fixture for a DBF-consuming application.

Archival and digital-preservation work. Libraries, archives, and government records offices frequently receive modern data in JSON but store it alongside legacy collections whose format is DBF. Converting incoming data to the archive's working format keeps the collection uniform and avoids future format drift.

Regression fixtures for DBF-consuming code. A developer maintaining a tool that parses DBF needs small, hand-crafted test files. Writing a JSON array with the desired records and converting it to DBF is faster than learning a DBF-writing library for a one-off test fixture.

Best Practices

Validate the JSON structure before converting. The converter expects an array of flat objects. If you are not certain the file matches that shape — for example, the JSON came from an automated export that may include nested structures — use the JSON Validator first to confirm the file parses cleanly. An early validation saves debugging a confusing DBF output.

Inspect the schema summary before downloading. The converter displays a field summary with inferred types and lengths. Skim this table before downloading. Common surprises: an ID column typed as Numeric (when leading zeros mattered), a date column stored as Character (because it was a string in JSON), or a field marked Character 254 because one record happened to exceed the limit.

Force types explicitly in the source JSON. The converter infers types by scanning values. To force a column to a specific type, control the JSON: wrap all values in quotes to force Character; ensure every value is a JSON number to force Numeric; use true/false consistently to force Logical. Mixed types across records will always fall back to Character.

Uppercase and shorten field names in the JSON. DBF field names are 11 bytes, ASCII, uppercase by convention. The converter will truncate and uppercase long JSON keys, but starting with DBF-friendly names (CUST_ID, ORDER_NUM) makes the output schema predictable and avoids silent collisions where two long JSON keys truncate to the same 11-byte prefix.

Supply a .cpg sidecar for UTF-8 DBFs. If your DBF output will be read by QGIS, ArcGIS, or a modern FoxPro environment, deliver a sibling text file named <name>.cpg containing the single line UTF-8. Without this, many GIS tools assume Windows-1252 and misdisplay non-ASCII characters.

Verify with the DBF Validator. After conversion, pass the output through the DBF Validator to confirm the header is well-formed, record count matches expectations, and field definitions are what you intended. This catches cases where the source JSON had structural quirks that the converter tolerated but a downstream reader may not.

Limitations and Edge Cases

Nested objects and arrays. DBF has no concept of nested data. If a JSON value is an object or an array, the converter serializes it to a JSON string and writes it into a Character field. The string may exceed 254 bytes and be truncated. For data with any real nesting, flatten the structure in the source JSON (use JSON to CSV for an intermediate flat representation) before converting.

Date types. Classic DBF has a dedicated D (Date) type stored as 8-byte YYYYMMDD. The converter does not emit D fields — ISO date strings in JSON are stored as Character. If your downstream system expects genuine D fields, post-process the DBF with a library that can alter the field descriptor in place.

Memo fields. DBF Memo fields hold text values longer than 254 bytes by referencing a separate .dbt file. The converter does not emit Memo fields — it truncates overly long Character values instead. For datasets with long text columns, DBF is not the correct output format.

Very large files. The converter reads the entire JSON file into browser memory and assembles the entire DBF in a single Uint8Array. Files with hundreds of thousands of records may exceed available memory on low-RAM devices. For large-scale batch conversions, a Python script using dbfpy or simpledbf is more appropriate.

Numeric precision. DBF Numeric fields are stored as ASCII decimal strings with a fixed total length and decimal count. Very long integers (more than 18 digits) or high-precision decimals exceed the format's practical range and will be truncated. For scientific or financial data requiring exact decimal representation, consider emitting a CSV and post-processing with a native DBF writer that supports extended precision modes.

Field-name collisions. Two JSON keys that share the same first 11 ASCII characters after uppercasing will produce duplicate DBF field names, which most readers handle poorly. The converter does not currently disambiguate — the last-written descriptor wins. Rename your JSON keys to avoid collisions if this matters.