JSON and data guides
JSON5 vs JSON repair vs formatting: choose deliberately
Use formatting for valid JSON, JSON5 for a known dialect, and repair only when inferred changes can be reviewed.
Formatting preserves a valid value
Formatting changes presentation such as indentation. A formatter cannot interpret arbitrary broken syntax without making extra decisions.
Run validation first when consuming an API response. If the input is not valid JSON, determine whether it is a dialect or damaged data.
JSON5 has intentional syntax extensions
JSON5 permits comments, single-quoted strings, trailing commas and some unquoted names. Those features are not standard JSON.
Select JSON5 when the source contract says JSON5, then export standard JSON for a consumer requiring RFC 8259 syntax.
// JSON5 input
{name:'Ada',active:true,}
// Standard JSON output
{"name":"Ada","active":true}Repair infers missing syntax
Repair can add punctuation or close strings and containers. An apparently valid result may not express what the original author intended.
Inspect the repair diff before using the result. If a network payload was truncated, retrieve the full source instead of inventing the missing records.
Review data and precision
Duplicate keys and unusual numeric values need a separate decision. Standard JSON excludes NaN and Infinity; JSON5 parsers may use native JavaScript numbers.
Nav Tools rejects unsafe JSON5 integers and non-finite values rather than presenting rounded or substituted data as faithful conversion. Verify the downstream format too.