Debug a JSON/YAML workflow with small, verifiable examples
Format an API response, preserve IDs when converting YAML or CSV, and compare the result before using it in your app.
When configuration stops working, changing formats repeatedly can hide the original mistake. A useful workflow is to reduce the input to a small sample, check its syntax, and compare the data types before copying anything back into an application. Here is a reproducible exercise using fictional product data.
1. Format the response before editing
Open JSON Formatter, paste this input, choose two-space indentation, and click Format:
{"code":"0012","price":125,"active":true,"tags":["desk","sale"]}
The output should still contain the string "0012", the number 125, the boolean true and an array with two strings. Formatting changes whitespace, not the intended data. If you paste {"price":125,} instead, parsing fails because strict JSON does not accept a trailing comma. Remove the comma and format again. Parser error wording depends on the browser; this tool does not highlight a particular source line.
Before using real API data, remove access tokens, customer names and other secrets. A short invented response is usually enough to reproduce a syntax issue.
2. Convert YAML without losing an identifier
In YAML Converter, use:
code: "0012"
price: 125
active: true
tags:
- desk
- sale
Click YAML → JSON. Expect the same four fields and types as in the JSON example. Quoting 0012 makes the intention explicit: it is an identifier, not a quantity. Converting back may change indentation and quoting. YAML comments and presentation are not part of JSON data, so a round trip is not a way to preserve an annotated configuration file exactly.
3. Check CSV quoting separately from number conversion
Try this in CSV to JSON with type inference off:
code,note
0012,"hello, world"
Expect one object with code equal to the string "0012" and note equal to "hello, world". The comma inside quotes belongs to the note, not a third column. With type inference off, values remain strings. Turn inference on only if your downstream application expects numbers or booleans, then check every identifier and unusually large number again.
4. Compare before replacing production data
Use Text Diff to inspect a before/after sample. Different indentation creates textual differences even when the parsed values agree, so check syntax, field names, values and data types separately. A syntax-valid object can still miss a required field or violate an application schema.
Keep the original file, test a small fixture in the application that consumes it, and replace production configuration only after that check succeeds. These browser tools parse whole values in memory; very large files can make a tab unresponsive. JavaScript number parsing can also lose integer precision beyond its safe range. Use strings for exact identifiers rather than treating formatting as a precision-preserving archive.