Compare a JSON address with separate CSV columns

One export can store an address as a JSON object inside a cell while another provides separate city, street and postal-code columns. Comparing the entire JSON cell to “Billing City” cannot answer whether the cities match. First expose the object’s individual fields, then map each field to its counterpart.

Spreadsheet Comparison detects supported JSON object cells and exposes flattened fields for mapping. This is JSON inside a CSV or selected spreadsheet sheet, not a general-purpose importer for arbitrary standalone JSON documents.

Start with the shape of the data

This synthetic row contains an identifier and two separate address objects. Keeping those containers distinct is essential:

customer_id: C-204
billing_address: {"city":"Bath","postal_code":"BA1 1AA"}
shipping_address: {"city":"York","postal_code":"YO1 7HH"}

A flat export might instead contain Billing City, Billing Postcode, Shipping City and Shipping Postcode. Map the city field under billing_address to Billing City, and the city field under shipping_address to Shipping City. Reusing the leaf name “city” without its parent would lose the meaning you need.

Map values, not containers

Load both exports and inspect the fields available in the mapping interface. Select the address leaf values individually. Object containers are not scalar values and cannot serve as a substitute for a single city or postal-code field.

Then map the stable customer identifier and choose it as the key. The key finds the same customer on each side; the address mappings determine which values are compared for that customer. If customer IDs repeat for multiple locations, use an appropriate additional key field and review duplicate warnings.

Remember that JSON has types

JSON distinguishes strings, numbers, booleans, null, objects and arrays. Its object members are name/value pairs, while arrays are ordered sequences. These are format-level distinctions documented by RFC 8259.

For identifiers such as postal codes, a string like "02108" preserves a leading zero that a numeric value cannot express in the same way. Check what the source actually exported. A comparison tool cannot infer the zero after another system has removed it.

Do not assume an array of several addresses has the same meaning as one address object. This workflow is for exposed object fields. If the source nests collections or uses inconsistent structures, inspect the available fields and prepare a deliberate flat working export when necessary.

Watch for sparse and missing fields

Some customers may have a postal code but no street line; another row may contain a field absent from the first row. Review the detected fields across the imported data rather than assuming the first record describes every record. A missing property, JSON null and an empty string can carry different source meanings even when their imported display values look blank.

When absence itself is important, inspect the source representation before interpreting a blank result as proof of equivalence. This comparison is a field-value review, not a JSON schema validator or a formal test of semantic equivalence.

Quote JSON correctly inside CSV

A JSON cell contains commas and quotes, so its CSV representation needs another level of escaping. This synthetic CSV record is valid under the common quoting conventions:

customer_id,address
C-204,"{""city"":""Bath"",""postal_code"":""BA1 1AA""}"

The outer quotes keep the cell together, and doubled quotes represent the JSON quotes inside it. RFC 4180 documents quoting and escaped double quotes in CSV. If import produces extra columns, check the exporter’s quoting before changing mappings.

Finish by opening a known customer in the full row preview and checking both address contexts. The different-header guide explains how to review suggestions when several destination fields look alike.