Inspect JSON, validate it, then convert it safely

Start with synthetic data that has the same shape as your real input. Paste this example into JSON Formatter:

[{"id":"001","name":"Ada","active":true,"note":null},{"id":"002","name":"Grace","active":false}]

The first record has note set to null; the second has no note property. Both IDs are strings so their leading zeros are part of their value. Formatting makes these differences easier to see, but does not establish that required fields or business rules are satisfied.

UtilByte rejects duplicate object keys, malformed strict JSON, and numeric values it cannot convert safely, including negative zero. Comments and trailing commas are not accepted. Keep exact identifiers and high-precision decimal values as quoted strings when that is the contract of your data source; do not simply quote every number to hide a validation failure.

Open JSON Schema Validator with the example as the JSON input. Replace its sample schema with the following draft-07 schema, then choose Validate JSON:

{"$schema":"http://json-schema.org/draft-07/schema#","type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"name":{"type":"string"},"active":{"type":"boolean"},"note":{"type":["string","null"]}},"required":["id","name","active"],"additionalProperties":false}}

The example passes: id, name, and active are required; note may be a string or null and may be absent. A record with active set to the string "true" fails because the schema requires a boolean. A record with an unexpected property fails because additionalProperties is false.

The validator does not insert defaults, turn strings into numbers, or remove extra fields. It returns the first validation error. Correct the source or revise the schema deliberately, then validate again; a pass only establishes agreement with the supplied schema.

Copy the validated input into JSON ↔ CSV, choose JSON to CSV, and select Comma. The Cells setting determines whether the conversion is intended for readable spreadsheet text or for preserving JSON values with a matching importer.

In Text (spreadsheet) mode, the example produces columns id, name, active, and note. Converting that CSV back to JSON in Text mode yields strings for every cell: the first active is "true", and both note values are empty strings. UtilByte does not guess that a numeric-looking string is a number.

Select JSON cells (preserve types) when you need null, missing properties, booleans, arrays, and nested objects to remain distinct. This mode JSON-encodes both headers and values. An empty CSV field means a missing property; a JSON null value means null.

Convert the original example, copy its output, switch to CSV to JSON, and keep the delimiter and JSON-cell mode unchanged. The two records recover their original supported JSON values, including the difference between null and absent note fields. Property order and whitespace are presentation details, not a byte-for-byte archive of the input.

JSON-cell CSV is not ordinary spreadsheet CSV. Do not expect another application to understand this encoding automatically. If a receiving system accepts JSON, sending the original validated JSON can avoid this intermediate representation altogether.

Text export enables Prefix formula-like cells for spreadsheets by default. For example, exporting a name value of =SUM(A1) adds an apostrophe, producing '=SUM(A1) as the cell text. This changes the value and the apostrophe remains when importing it back into UtilByte.

Keep the protection enabled when exporting untrusted text for spreadsheet use. If your destination requires the original exact string, understand its formula handling before disabling the setting. JSON-cell mode has a different encoding and does not use this text-mode protection; it is not a substitute for a spreadsheet safety policy.

For application code, paste the original JSON into JSON to TypeScript instead of inferring types from a Text-mode CSV round trip. Otherwise you would infer string for active after the conversion had already discarded its boolean type.

The result is an exported Root type alias. In this example it contains an array union of two object shapes: one has note typed as null, and the other has no note property. It does not merge them into a single object with an optional note. Review that union against the real API contract before using it.

Empty arrays become unknown[]. Mixed arrays produce unions, and a date-looking string remains a string. One sample cannot establish all possible values, optional fields, enums, or future response variants. Generated TypeScript is a compile-time aid; it performs no runtime validation of a network response. Keep schema checks at the boundary where untrusted data enters your application.

These JSON workflows accept at most 1,000,000 input characters and 64 nesting levels. File import is limited to 1,000,000 bytes, which differs from the character limit for non-ASCII text. CSV supports comma, semicolon, and tab delimiters, up to 10,000 records and 200 columns. JSON-to-CSV input must be a nonempty array of objects.

A schema is limited to 64,000 characters. Type inference has a stricter 32-level nesting limit and rejects arrays with more than 30 distinct inferred shapes. Conversion and schema validation run in a worker with a five-second timeout and a Cancel control, so smaller representative inputs are easier to diagnose.

Before using an export, compare record counts, required keys, a leading-zero ID, a boolean, a null, and an absent field. If the destination is a spreadsheet, check those values after its import as well. Keep the source until the receiving system has accepted the result.

The implementation is available in src/lib/json-safe.ts, src/lib/data-workflows.ts, and src/lib/schema-validation.ts in the open-source repository. Existing tests/data-reliability.test.ts covers duplicate-key and precision rejection, text and JSON-cell conversion, schema behavior, and type inference. These checks describe the implementation; they do not certify a separate application’s importer.