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

The Dbf To Json Converter runs entirely in your browser — your .dbf 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 DBF file, running the conversion, reading the stats panel, reviewing the schema summary, handling deleted records, and exporting the JSON output. It also covers the most common problems you will encounter with real-world DBF files and how to resolve them.

Connect on LinkedIn →

Step 1 — Open the Tool

Navigate to /developer-tools/dbf-to-json/. The tool loads entirely in your browser. After the initial page load, converting a file makes no outbound network requests — you can verify this in your browser's DevTools Network panel while the conversion runs. This matters for DBF work because real-world .dbf files often contain sensitive data: personnel records, financial ledgers, client databases, or GIS attribute tables with location-linked personal information.

The tool is accessible from the Developer Tools hub, the command palette (press Ctrl+K or ⌘K and type "Dbf To Json"), or directly via the URL above.

Step 2 — Load Your DBF File

The converter accepts a standard .dbf file produced by dBASE III, dBASE IV, dBASE 5/7, FoxPro, Visual FoxPro, or any tool that writes the dBASE binary format — including the .dbf component of an ESRI shapefile.

Load the file using one of two methods:

• Drag and drop. Drag a .dbf file from your file manager, desktop, or Downloads folder and drop it anywhere on the blue-bordered drop zone. The zone highlights when a file is being dragged over it. You can also drop the file anywhere on the page — a full-screen overlay appears to catch the drop, which is convenient when working with long documents where scrolling to the drop zone would be tedious.
• Click to browse. Click the drop zone or the "browse" link inside it to open your operating system's file picker. Navigate to your .dbf file and select it.

Once the file is loaded, the filename appears in a bar below the drop zone. The drop zone itself hides to keep the interface clean. To replace the file, click the ✕ button in the filename bar — this clears the loaded file and returns the drop zone so you can load a different one.

The tool accepts only files with the .dbf extension. If you drop a file with a different extension (for example, a renamed .dat from an old FoxPro project), rename it to .dbf first. If your DBF uses Memo fields and you have a companion .dbt file, keep it in the same folder so that any downstream tool that consumes the output JSON can cross-reference memo pointers — this converter works on the .dbf alone and will emit the 10-byte Memo pointer as a string rather than resolving it to the Memo text.

Step 3 — Click Convert to JSON

Once a file is loaded, click the Convert to JSON button. The conversion pipeline runs immediately in the browser:

1. The file is read as an ArrayBuffer. A DataView is opened over the buffer to extract little-endian integers and byte-level fields.
2. The 32-byte file header is parsed — version byte, last-update date, record count, header length, record length, and codepage hint (byte 29).
3. The field descriptor array is walked. Each 32-byte descriptor yields a field name, type code (C, N, L, D, F, M), field length, and decimal count. A 0x0D terminator closes the descriptor section.
4. Starting at the declared header offset, each fixed-length record is sliced and decoded. The leading byte is inspected for deletion status (0x20 active, 0x2A deleted). Fields are interpreted according to their type code: Character fields are trimmed and decoded with the declared codepage, Numeric fields are parsed to JSON numbers, Logical fields become booleans, and Date fields (YYYYMMDD) become ISO YYYY-MM-DD strings.
5. The resulting array of objects is rendered into the output panel and held in memory for copy or download.

For a typical .dbf of a few thousand records and 10–20 fields, the conversion completes in well under a second. The button is disabled during processing to prevent accidental double-clicks.

Step 4 — Read the Stats Panel

After a successful conversion, a green stats panel appears with the key numbers you should check before relying on the output:

• Records (active). The number of active records in the DBF — the count that would be visible to a typical DBF reader. Compare this against the expected row count in the source system; a mismatch suggests the file was truncated or that the header's record count does not match the actual byte length.
• Records (deleted). The number of soft-deleted records — rows present in the file but marked with a leading 0x2A byte. A non-zero number here means the source DBF has never been packed (physically compacted). Legacy systems often run for years without packing, so this is common.
• Fields. The number of columns in the DBF schema. This equals the count of 32-byte field descriptors in the header.
• Codepage. The codepage the converter applied to Character fields. If your DBF has non-ASCII characters and the codepage shown is not what you expect, re-open with the correct codepage forced (advanced settings) before relying on the JSON.
• File size. The size of the input .dbf. Compare against the on-disk file size — a mismatch here is rare but can surface if the file was transferred over a text-mode protocol that corrupted binary content.

Step 5 — Review the Schema Summary

Below the stats panel, a schema table lists every field alongside its DBF type, length, decimal count, and a sample value. This is the single most important table to review before using the JSON — it tells you how the converter interpreted each column, which may differ from how the legacy system intended the data to be read.

The cases to look for:

• Numeric ID columns with leading zeros. If the source DBF stores IDs in a Numeric field, leading zeros are lost during parse ("0042" in the fixed-width field becomes the JSON number 42). If leading zeros matter to your downstream system, check whether the source field is actually Character in disguise, or post-process the JSON to left-pad to the field's declared length.
• Character-typed date fields. Many legacy systems store dates as fixed-width Character strings rather than genuine D fields. The converter preserves them verbatim. If the downstream system expects ISO dates, post-process with a small script to reformat.
• Date fields with " " (all-space). An empty D field in classic DBF is stored as 8 ASCII spaces. The converter emits these as JSON null. If you see null values in an otherwise fully-populated date column, those rows had no date assigned in the source system.
• Memo field pointers. A Memo field (M) holds a 10-byte pointer into the sibling .dbt file. Without the .dbt, the JSON output contains pointer strings rather than readable text. If your DBF uses Memo fields, deliver the .dbt along with the .dbf to any downstream consumer.
• Unusual type codes. 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 fall back to Character for rare codes. If the schema table shows Character for a field you expect to be numeric, the source file is using a Visual FoxPro extension the converter did not recognise.

If the schema table is empty, the file's field descriptor section was empty or malformed. Pass the file through the DBF Validator to confirm the header integrity before further debugging.

Step 6 — Decide About Deleted Records

By default, the JSON output contains only active records — the same rows a typical DBF reader would show. If the stats panel reports zero deleted records, skip this step. If deleted records are present, you have a decision to make.

• Active only (default). Use this when the DBF is being migrated to a modern system that treats deleted records as truly absent — for example, feeding shapefile attributes into a web map where the accompanying geometries have already been filtered.
• Include deleted. Toggle the "Include deleted records" control before exporting. Each record in the output gains a metadata flag (typically _deleted: true or false) so downstream code can filter, audit, or preserve the history. Use this for audit work, legal-hold scenarios, and any migration where the source system still considered deleted rows recoverable.

Always look at a few deleted rows before discarding them. A legacy operational system may have soft-deleted a row for an entirely recoverable reason — duplicate-entry cleanup, for example — while still relying on it for historical reporting. Treating soft-deletes as hard-deletes during migration is a common and easily-missed data-loss failure mode.

Step 7 — Copy or Download the JSON

The output panel shows the JSON array, pretty-printed for readability. Two export controls sit above it:

• Copy to Clipboard. Copies the full JSON array to the system clipboard. Use this when you are about to paste into another tool — a REST client, a database shell, a code editor — without bothering with an intermediate file.
• Download JSON. Saves the JSON to a .json file in your browser's default downloads folder. The filename is derived from the input file: customers.dbf becomes customers.json.

After exporting, spot-check the JSON before using it in production:

• Pass the file through the JSON Validator to confirm it parses cleanly. Well-formed DBFs produce well-formed JSON, but cross-checking is cheap insurance.
• If you want the JSON indented with a specific spacing for diff tooling, run it through the JSON Formatter.
• Confirm the record count of the output array matches the active-record count reported in the stats panel.
• Spot-check a few rows with non-ASCII text (accented characters, Greek, Cyrillic, CJK) to confirm the codepage was applied correctly. Garbled characters indicate a codepage mismatch — re-open the source with a different codepage and re-export.

Troubleshooting Common Problems

"Invalid DBF — header version byte not recognised." The first byte of the file is not one of the known DBF version bytes (0x03, 0x83, 0x30, and related values). Causes: the file is not actually DBF, the file was truncated at the start, or the file is a rare DBF dialect the converter does not handle. Open the file in a hex viewer and confirm byte 0 matches a known DBF version; if it does but conversion still fails, pass it through the DBF Validator for a more detailed diagnosis.

"Record count mismatch between header and file length." The header claims N records but the file length implies a different count. This usually means the file was truncated during transfer or extraction. Re-download or re-extract from the archive. If the file is an authoritative original, the header is simply wrong — the converter will still extract readable records up to the end of the byte stream, but a warning is displayed.

Non-ASCII text appears as mojibake in the JSON. The codepage the converter selected does not match the codepage the writer used. Check the stats panel for the detected codepage. If a companion .cpg sidecar file exists, open it in a text editor and confirm its content matches what the converter chose. If not, re-open the DBF with a different codepage forced via the advanced settings.

Numeric fields show JSON strings instead of numbers. The source DBF used the Character type (C) rather than Numeric (N) for the field — common in older systems where the author wanted to preserve leading zeros or currency-symbol prefixes. This is a source-file choice, not a converter issue. Post-process the JSON to cast if you need typed numbers downstream.

Date fields emit null for rows that have dates in the source system. The source system likely stored dates as Character rather than D, and the Character value is not in YYYYMMDD format. Check the schema summary: if the date column is typed Character, the converter preserved the raw string. If it is typed D and contains null, the source field was all-space for those rows.

Memo field values look like garbage bytes rather than text. Memo content lives in a sibling .dbt file, not the .dbf. The 10-byte pointer is all this converter can surface. To resolve Memo text, use a DBF library that accepts the .dbt alongside the .dbf — this browser-based tool reads the .dbf alone.

A shapefile .dbf has fewer records than the .shp. QGIS and ArcGIS match attribute rows to geometry rows by index. If the .dbf row count is shorter than the .shp feature count, the GIS tool drops features silently. Regenerate the attribute table from the source so the record count matches.

Worked Example

The following example walks through a complete conversion using a small, representative DBF — the kind of file you would find as the attribute table of a simple shapefile or as an export from a legacy FoxPro inventory system.

About the sample: Imagine a file named orders.dbf with 3 active records and 1 soft-deleted record, written by a vintage FoxPro inventory tool. Its field descriptors define four columns: ORDER_ID (Numeric, length 4, decimals 0), CUSTOMER (Character, length 20), AMOUNT (Numeric, length 7, decimals 2), and SHIPPED (Logical, length 1). The deleted row was marked for removal but the file has never been packed.

Convert using the tool:

1. Open the Dbf To Json Converter.
2. Drag orders.dbf onto the drop zone, or click browse and select it.
3. The filename bar shows: 📎 orders.dbf.
4. Click Convert to JSON.
5. The stats panel shows: Records: 3 (active) · 1 (deleted) · Fields: 4 · Codepage: Windows-1252.
6. The schema table shows the four columns with their types and sample values from the first record.
7. Leave the deleted-records toggle off for a typical migration run.
8. Click Download JSON. The file is saved as orders.json.

Inspect the output: The JSON array has three objects, one per active record. Each object has the four keys ORDER_ID, CUSTOMER, AMOUNT, SHIPPED. ORDER_ID values are JSON integers. CUSTOMER values are strings with trailing spaces trimmed. AMOUNT values are JSON numbers with two decimal places preserved. SHIPPED values are JSON booleans.

Now try with deleted records included: Re-open the file (or toggle the deleted-records control and re-export). The output array now contains four objects. Each object gains a _deleted field (or the naming convention your build uses): false for the three active rows and true for the soft-deleted one. This is the output shape you want for audit and migration work where history must be preserved.

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