Define the output contract before converting the CSV
The safe way to convert CSV to JSON is to decide what every output key and value should mean before touching the full export. A converter can arrange rows into objects, but it cannot know whether a blank cell should become an empty string, null, an omitted property, or an error.
For example, consider an order export with order_id, quantity, promo_code, and note. The value 000184 must remain an identifier with its leading zeros. quantity may eventually need to be a JSON number. A missing promotion code might be accepted as "", while a missing note might need to be null. Those are API rules, not CSV syntax rules.
Write a short contract beside the work:
- Record the exact, case-sensitive key expected for each column.
- Mark each key as required or optional.
- State the required JSON type: string, number, Boolean, array, object, or null.
- Define what a blank source cell means for that specific key.
- Identify one value that can be traced from source row to test response.
Keep the original export unchanged. Make a small, synthetic fixture with five to eight rows, including a normal row, a leading-zero ID, a blank cell, a note containing a comma, and a note containing a doubled quote. This fixture exposes structural mistakes without putting customer records into a debugging page.
Clean and test the header row first
Headers become object keys when the first-row-as-header option is enabled, so a bad header can corrupt every converted row. Check for duplicates, blank names, trailing spaces, and spelling differences before processing data.
Two columns both named price cannot be represented as two independent properties in one ordinary JSON object. In the current converter, the later value replaces the earlier value when duplicate header names are assembled into an object. A blank header produces an empty key. Rename ambiguous columns at the source or in an authorized working copy, and document the mapping, such as unit_price and shipping_price.
Also count the columns in the fixture. When a data row has fewer cells than the header, the current conversion fills the missing mapped positions with empty strings. When a row has extra cells beyond the header width, those extra values have no header key and are not included in the object. Either condition may still produce valid JSON, so syntax alone will not reveal it.
Convert a representative fixture in the browser
Open the CSV ⇄ JSON converter and paste the synthetic fixture into the CSV side. Choose the one-character delimiter used by the source and leave “First row is header” selected when the first line contains keys. Then run CSV → JSON.
The local component handles quoted commas, quoted line breaks, and doubled double quotes inside a quoted field. It rejects an unclosed quoted field and a quote that begins after unquoted text in the same field. This behavior is useful for finding malformed samples, but it does not certify every CSV dialect produced by every vendor.
Inspect the first object immediately. The converter preserves CSV cells as JSON strings. It does not infer that 2 is a number, that false is a Boolean, or that an empty field should be null. This is often helpful for identifiers, because 000184 stays intact, but an API expecting a numeric quantity will still require an explicit, field-specific transformation in application code.
The page processes pasted text; it does not upload or open a CSV file. If the source is a CSV, TSV, XLSX, or XLS file, the CSV and Excel preview tool can display sheets and help identify an obvious column shift before a small authorized sample is copied. That viewer is preview-only: it does not edit the workbook, expose encoding or delimiter controls, or turn a search into an export filter.
Check empty values and types field by field
Do not run a global replacement from "" to null. An empty string, a null value, and a missing property can trigger different application behavior. Apply the contract one key at a time after the structural conversion.
Return to the order example. promo_code: "" may mean that the buyer entered no code. note: null may mean that no note exists. Omitting note could instead tell a patch endpoint to leave an existing note unchanged. The receiving API documentation or schema must settle that distinction.
Use the same discipline for types. Convert only the columns documented as numeric or Boolean. Keep account IDs, postal codes, invoice numbers, and other fixed-width identifiers as strings unless the contract says otherwise. Check decimal handling in the receiving application rather than assuming that a text value such as 125.50 will preserve the required financial meaning after an automatic number conversion.
Paste the resulting sample into the JSON formatter and validator for a separate syntax check. That tool can report whether the text parses as JSON and make its nesting readable. It cannot validate the API schema, required properties, permissions, enum values, or business rules.
Verify the exact payload in a safe destination
A successful conversion is the beginning of verification, not the end. Compare the fixture and JSON side by side, then send only a small approved sample to a sandbox, dry-run endpoint, or validation command supplied by the receiving system.
Before that test, check all of these points:
- The number of JSON objects equals the number of intended data rows.
- Every object has the expected set of unique keys.
- The leading-zero identifier still matches the source.
- The quoted comma and embedded quote remain in one value.
- Each blank field uses the contract’s chosen representation.
- Numbers and Booleans have been transformed only where required.
If the API rejects the sample, separate syntax failures from contract failures. A parser error points to invalid JSON. A missing-field, type, enum, authentication, or business-rule error means the text may be valid JSON but unsuitable for that endpoint. Fix the mapping or source rule, regenerate the same fixture, and repeat the small test before expanding the batch.
Protect sensitive data throughout this process. Browser-side handling does not control clipboard history, browser extensions, screen capture, device management, or organizational policy. Use invented values for structural testing and move real records only through an approved environment.
Frequently asked questions
Why are numbers from my CSV still quoted in JSON?
The current converter preserves cell values as strings and does not infer types. This protects identifiers with leading zeros. Convert only the fields that the receiving contract explicitly defines as numbers.
Should every empty CSV cell become null?
No. Empty strings, null values, and omitted properties can have different meanings. Define the rule per field from the API documentation, then transform only those fields.
What happens when two CSV headers have the same name?
The later value can replace the earlier one when the object is created. Make headers unique before conversion and record how each renamed column maps to the destination field.
Can the converter open my Excel workbook and update it?
No. The CSV to JSON page works with pasted text. The related spreadsheet page can preview supported files, but it does not edit the workbook. Neither page updates an XLSX file in place.
Does valid JSON mean the API will accept the payload?
No. JSON validation checks syntax. The API can still reject wrong keys, types, permissions, enum values, dates, or business rules. Test a small fixture in the destination’s approved validation path.