Missing, null or empty: write a JSON field contract before importing

Start with four records that look similar in a table

A contact export contains four fictional customer IDs. One object has no phone member, one has phone set to null, one has an empty string and one has a nonempty string. All four objects are valid JSON. The job is to preserve the intended action, not to make their columns look alike. Keep a read-only copy of the original payload and a small working sample.

An absent member is a fact about object structure. Null is an explicit JSON value. An empty string is a string containing no characters. The words unknown, clear and unchanged are application decisions; they do not follow automatically from those three representations.

[{"id":"C-101"},{"id":"C-102","phone":null},{"id":"C-103","phone":""},{"id":"C-104","phone":"5550104"}]

RFC 8259: JSON values and objects ↗

Write the decision beside the destination field

For a fictional address-book migration, the team could decide that omission leaves an existing phone unchanged, null clears it, an empty string is rejected for review, and a nonempty string replaces it. This is an example contract, not a rule to apply to an unknown API. A different destination may use null for unknown or reject it entirely.

Record the contract version, field type, allowed states and reviewer. Use the same sample for a new record and for an existing record if create and update operations have different behavior. Avoid running a live update merely to discover what null means; use documentation and an authorized test environment first.

1. Find the destination documentation for this exact operation.
2. Give each allowed state a meaning and a pass/fail expectation.
3. Test the four synthetic records in an isolated test path.
4. Compare the saved result with the expected state, not only a successful HTTP response.

Inspect the structure without assigning meaning

KitForma JSON Formatter can make the four-record payload easier to read. It does not enforce your field contract. Use Text Diff when reviewing a small edited copy, but inspect the changed values as well as the added and removed lines. Deleting a null member is a semantic edit even if the document becomes shorter.

When you need a review table, add a separate state column such as absent, null, empty or value in your migration script. Retain the raw JSON as the authoritative source. Do not invent a real phone number to satisfy a required field or replace all missing states with a single default.

Know what disappears during JSON-to-CSV conversion

The current KitForma JSON-to-CSV tool writes missing and null values as empty cells. An existing empty string also appears empty. A CSV-to-JSON round trip therefore cannot tell those three original states apart. This is a limitation of that conversion path, not evidence that the original records were identical.

For the sample, preserve id, phone_state and phone_value in an explicitly prepared review export. A reviewer can filter phone_state without guessing from blank cells. After approval, construct the destination payload from the recorded contract; do not treat the review CSV as a lossless archive.

id,phone_state,phone_value
C-101,absent,
C-102,null,
C-103,empty,
C-104,value,5550104

Q: Is an empty string the same as null?

No. The empty string has string type; null is a separate value. Your application may choose to treat them alike, but that rule must be explicit. Check type and presence separately when the difference affects updates or reporting.

Q: Can I recover the difference from an already flattened CSV?

Not reliably when all three states became the same empty cell. Use the original JSON, an audit log or a new export that includes state. Mark unresolved records for review instead of claiming that a guessed reconstruction is exact.