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

DBF is the dBASE database file format — a binary, fixed-width, row-oriented container that predates JSON by two decades and still anchors a long tail of working software. If you touch geographic data, a shapefile ships with a sibling .dbf carrying attribute rows. If you inherit FoxPro code, an insurance ledger from the 1990s, a QuickBooks export, or a parcel-records system at a county assessor's office, the working data is almost certainly DBF. JSON is everywhere modern APIs, JavaScript frameworks, and document databases live. Converting between the two is a routine developer task that sits exactly on the fault line between legacy and modern data.

The friction is concrete: a developer receives a .dbf file from a client, a GIS teammate, or an archival system, and needs to feed its rows into a web API, a JavaScript front end, or a document store. The DBF format is binary with a fixed header, typed field descriptors, and a byte-aligned record layout. Reading it correctly requires understanding the 32-byte file header, the 32-byte-per-field descriptor array, type codes, codepage handling, and the soft-deletion convention where removed rows are marked with an asterisk rather than physically deleted. Most command-line approaches involve installing a Python library like dbfread or simpledbf, writing a small script, and hoping the file's codepage is one the library guesses correctly.

The Dbf To Json converter on this site does the full pipeline entirely in your browser. Drop a .dbf file (from dBASE, FoxPro, Visual FoxPro, or the attribute component of an ESRI shapefile) onto the page and it parses the header, walks the field descriptors, reads every record, interprets field types, surfaces soft-deleted rows, and emits a clean JSON array of objects ready to copy or download. No upload, no server processing, no login. This guide explains the DBF format, how the converter interprets it, what edge cases matter, and the best practices developers should follow when extracting DBF data into a modern JSON pipeline.

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 through dBASE III, IV, 5, and 7, adopted by FoxPro and Visual FoxPro, and became the de facto attribute-table format for ESRI shapefiles — every shapefile you encounter in the wild ships with a companion .dbf file carrying the non-geometric attributes of each feature.

The physical structure of a DBF file is as follows:

• File header (32 bytes). The first byte identifies the DBF version (0x03 for dBASE III without memo, 0x83 with memo, 0x30 for Visual FoxPro, and several lesser-used variants). 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 is 0x20 (space) for active records or 0x2A (asterisk) for soft-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.

DBF vs. JSON: Key Differences

Understanding the structural differences between the two formats explains why the conversion produces the output it does and why certain DBF constructs become JSON strings rather than their natural typed equivalents.

• Readability. DBF is binary and historically tied to single-byte codepages (CP437 OEM US, Windows-1252, or a codepage specified in the header's language-driver byte). JSON is plain text, Unicode-aware, and human-readable.
• Schema. DBF requires every record to have the same fields with identical types and lengths, fixed at write time. JSON is schemaless at the file level — each object in the output array reflects the DBF schema, but nothing in the format prevents downstream consumers from re-shaping the data.
• Field names. DBF field names are limited to 11 ASCII bytes, uppercase by convention. JSON keys may contain any Unicode characters and any length. The converter preserves the DBF field name verbatim as the JSON key by default, so downstream code sees the same names a DBF reader would.
• Type system. DBF supports Character, Numeric, Logical, Date, Memo, and Float. JSON values are strings, numbers, booleans, null, arrays, or objects. The converter maps DBF types to the closest JSON equivalent — numbers parse to JSON numbers, logicals to JSON booleans, dates to ISO YYYY-MM-DD strings — with documented fallbacks for malformed values.
• Nulls. DBF has no dedicated null representation. Empty fields are space-padded; numeric nulls are often stored as all-space or zero. The converter emits null for space-padded fields and attempts a best-effort distinction between zero and empty for numeric columns.
• Deleted records. DBF soft-deletes rows — they remain in the file with a leading 0x2A byte. JSON has no equivalent concept. The converter surfaces deletion status as a metadata flag so downstream code can filter or preserve deleted rows as the use case requires.

How the Conversion Works

The Dbf To Json converter reads your .dbf file byte-by-byte using the Web File API and a DataView over the raw ArrayBuffer. The pipeline has four stages.

Stage 1 — File header parse. The first 32 bytes are read as the DBF file header. The version byte identifies the dialect (dBASE III, FoxPro, Visual FoxPro, etc.); the record count, header length, and record length are extracted as little-endian integers. An unrecognised version byte triggers a warning but does not stop parsing — most DBF readers are permissive.

Stage 2 — Field descriptor scan. Starting at offset 32, the converter reads 32-byte descriptors until it encounters the 0x0D terminator. For each descriptor it extracts the field name (null-terminated within the 11-byte slot), the type code, the field length, and the decimal count. The result is an ordered list of column definitions — the schema of the DBF.

Stage 3 — Record walk. Records are read starting at the offset declared in the header length field. For each fixed-length record, the converter inspects the leading byte to determine deletion status, then slices each field by its declared length and interprets the bytes according to the field's type code. Character fields are trimmed and decoded; numeric fields are parsed to JSON numbers; logical fields are mapped to booleans; date fields are parsed to ISO strings. A malformed field value produces a JSON null rather than halting the pipeline.

Stage 4 — JSON assembly. The converter builds a JSON array of objects — one object per active (or, optionally, per all) record, with one key per field. The array is presented for preview, copy to clipboard, or download as a .json file. A schema summary and a parse-status panel are rendered alongside the output so you can verify the field count, record count, and any warnings before using the result.

The entire pipeline runs in the browser's JavaScript engine. The .dbf file never leaves your machine — it is read directly from the drop target into memory. For a typical .dbf of a few thousand records and 10–20 fields, parsing completes in well under a second.

Field Types and How They Map to JSON

Every DBF field descriptor carries a single-byte type code. The converter maps each to a JSON value as follows:

• Character (C). Stored as fixed-length bytes right-padded with spaces. The converter trims trailing spaces and decodes the bytes using the file's declared codepage (with UTF-8 and Windows-1252 fallbacks). Output: a JSON string. Empty fields become null.
• Numeric (N). Stored as ASCII decimal strings — for example, the number 42 in a 5-byte field with 0 decimal count appears as " 42". The converter trims whitespace and calls parseFloat; if the result is a valid number it becomes a JSON number. Fields with decimal count > 0 retain fractional digits. Empty numeric fields become null.
• Logical (L). Stored as a single byte: T/Y for true, F/N for false, or ? / space for unknown. The converter emits JSON true, false, or null respectively.
• Date (D). Stored as 8 ASCII bytes in YYYYMMDD format. The converter reformats to the ISO YYYY-MM-DD string used by modern JSON APIs. All-space or unparseable date fields become null.
• Float (F). Handled identically to Numeric by nearly every DBF reader — the distinction only matters to certain dBASE IV dialects. The converter treats F the same as N.
• Memo (M). In a classic DBF file, a Memo field holds a 10-byte pointer into a separate .dbt file where the actual text lives. The converter emits the pointer as a JSON string when no companion .dbt is supplied; the actual Memo text cannot be recovered from a .dbf alone.

The converter displays a schema summary panel after parsing — field name, type code, length, decimal count, and a sample value per column — so you can confirm the interpretation before exporting. If a column is being misread (for example, a numeric ID with leading zeros showing as an integer), you can consult the summary to diagnose the issue before the JSON is used downstream.

Deleted Records and the Soft-Deletion Flag

DBF never physically removes records — it marks them with a leading 0x2A byte (the asterisk character) and leaves the bytes in place. Packing the file physically removes deleted rows, but packing is an explicit operation and is not performed by most users, so real-world DBF files frequently contain a meaningful number of soft-deleted records. A DBF consumed by a legacy reporting tool may be showing only active rows; a DBF handed to you for migration may carry history that the original system still considers recoverable.

The converter handles this explicitly. By default the JSON output contains only active records, matching what a typical DBF reader would display. A toggle exposes deleted records — these appear in the output with a boolean _deleted metadata key (or the naming convention your build uses) set to true, so downstream code can filter, audit, or preserve them as the use case requires. The record count in the schema summary distinguishes active from total so you can confirm at a glance whether the source contained deletions.

For migration work, always review the deleted records before discarding them. A common failure mode during legacy migrations is treating soft-deleted rows as truly absent when the original system still relied on them for audit trails or point-in-time reporting. If the deleted rows carry historical significance, the downstream system needs its own soft-deletion column — not a silent drop.

Character Encoding and Codepage Handling

The DBF format predates Unicode. Byte 29 of the file header is a language-driver ID that specifies a codepage — a numeric hint like 0x01 (CP437 OEM US), 0x03 (Windows-1252 Latin), or 0x57 (CP1252 ANSI). A significant fraction of real-world DBF files have byte 29 set to zero, meaning "unspecified," which in practice means "Windows-1252 if you are on Windows, something else otherwise."

The converter reads byte 29 and applies the declared codepage if it recognises the ID. If byte 29 is zero or unknown, the converter falls back to a short sequence: try UTF-8 (valid on modern FoxPro extensions and GIS tooling that writes a .cpg sidecar), then Windows-1252 (the de facto Western Windows default), and flag ambiguous results in the parse-status panel.

Shapefile attribute tables commonly ship with a sibling .cpg file containing a single text line naming the codepage — for example, UTF-8 or WINDOWS-1252. If you have access to a companion .cpg, open it in a text editor and confirm its contents match the codepage the converter is guessing. If not, do a spot-check of fields containing accented characters, Greek, Cyrillic, or CJK content — mojibake is the telltale sign of a codepage mismatch.

Common Use Cases

Ingesting shapefile attributes into a JavaScript or Node pipeline. An ESRI shapefile is a set of files (.shp, .shx, .dbf, and optional .prj/.cpg) where the .dbf carries the non-geometric attributes. Converting the .dbf to a JSON array lets a web app or GeoJSON-assembling script consume the attribute rows without pulling a full GIS library into the build. The JSON output maps one-to-one onto a GeoJSON properties object.

Migrating a legacy FoxPro or dBASE application. Vintage FoxPro systems in insurance, accounting, and records management remain deployed. Migration work usually starts with dumping the database to JSON for ingestion into a modern data store — Postgres, MongoDB, or a cloud data warehouse. Converting the underlying .dbf files to JSON is the first step.

Feeding JSON APIs from archival data sets. Government records offices, county assessors, and legacy academic databases store data as DBF files with a multi-decade provenance. Exposing that data through a modern API requires an intermediate JSON representation. Converting the DBF in your browser avoids uploading possibly-sensitive records to a third-party server.

Debugging a DBF-producing pipeline. A developer writing code that generates DBF files (for example, exporting an attribute table for a custom GIS pipeline) can use the converter as a quick sanity check. Dropping the output .dbf onto the converter and inspecting the JSON reveals whether field types, lengths, and values are what the code intended.

Documenting legacy data for audit or compliance. Auditors and compliance reviewers often need a human-readable representation of historical DBF data. Converting to JSON produces a diff-able, grep-able artefact that can be checked into version control alongside the original binary for posterity.

Best Practices

Validate the DBF before converting. A .dbf file with a corrupted header or a truncated record section produces confusing JSON output. Pass the file through the DBF Validator first to confirm the header is well-formed and the record count matches expectations.

Inspect the schema summary before exporting. The converter renders a schema table showing field name, type, length, decimal count, and a sample value. Skim this before downloading — the common surprises are a numeric ID typed as Character (because the file author chose C to preserve leading zeros) or a date column stored as Character instead of D.

Decide explicitly whether you want deleted records. The default is active-only, matching conventional DBF consumers. For migration or audit work, toggle deleted records on and review them before discarding — the original system may still treat them as recoverable history.

Confirm the codepage matches your expectation. If your DBF contains accented characters, Greek, Cyrillic, or CJK text, spot-check those fields in the JSON output for mojibake. If the bytes look wrong, re-open the file with the correct codepage forced — the converter exposes the codepage override in its advanced settings.

Post-process with a JSON validator or formatter. After exporting, confirm the file parses cleanly with JSON Validator and, if you need indented output for diff tooling, pass it through JSON Formatter. Catching a malformed JSON artefact at export time is far cheaper than debugging a downstream parse error.

Keep the original .dbf. JSON is derived; the DBF is the source of truth until you have validated the full round trip. Retain the original until your downstream pipeline has consumed the JSON successfully.

Limitations and Edge Cases

Memo (.dbt) files. A Memo field holds a 10-byte pointer into a separate .dbt file where the actual long text lives. Without the .dbt, only the pointer can be recovered, and the JSON output will contain pointer bytes rather than readable text. If your DBF uses Memo fields, deliver the .dbt sidecar alongside — this converter works on the .dbf alone and cannot fabricate the missing content.

Visual FoxPro extensions. Visual FoxPro added Currency (Y), DateTime (T), Integer (I), and Double (B) types beyond classic DBF. The converter handles the most common variants but may emit Character representations for uncommon type codes. For faithful round-trip work with Visual FoxPro data, consult the schema summary and consider post-processing in a library that targets the FoxPro dialect specifically.

Packed files. If a DBF has been explicitly packed (deleted records physically removed), the soft-deletion toggle will have no effect — there are no deleted rows to surface. This is not a bug; the source file no longer contains the deleted data.

Mixed codepages. Extremely old or hand-edited DBFs occasionally mix codepages between fields, particularly when data has been migrated across systems. The converter applies a single codepage per file. If one field looks wrong while others look right, the source file is likely internally inconsistent and requires field-level decoding.

Very large files. The converter reads the entire .dbf into browser memory. Files of several hundred megabytes may exceed the available memory of low-RAM devices or mobile browsers. For bulk conversion work, a Python script using dbfread or simpledbf is more appropriate.

Binary artefacts in Character fields. A Character field occasionally contains bytes that are neither valid in the declared codepage nor printable ASCII — typically the result of a bug in the original DBF writer. The converter emits these as replacement characters in the JSON string and flags the record in the parse-status panel so you can investigate.