Format JSON From curl Output

curl prints HTTP response bodies directly to standard output by default, with no formatting and no headers unless you pass the --include flag explicitly. For JSON APIs this means the response body arrives as a single line of text that is parseable but unreadable. Pasting this raw output into FixTools produces a fully formatted view in milliseconds because the tool calls JSON.parse on the input and then JSON.stringify with an indent argument. The validation step also catches the common case where an upstream error has caused the API to return an HTML error page instead of the expected JSON, and reports the parse failure rather than silently producing broken output.

A common source of confusion is the progress meter that curl prints by default to standard error when the output is not a terminal. If you copy from a script that redirects standard error into standard output without the --silent flag, the progress meter may be interleaved with the response body and corrupt the JSON. The fix is to always use --silent for scripting, or --silent --show-error if you still want to see actual network errors. FixTools cannot recover from a body that has progress meter text spliced into the middle, so the parse error in that case is correctly attributed to the contamination rather than to the original response.

curl also handles HTTP redirects only when you pass the -L or --location flag explicitly. Without it, a 301 or 302 response produces an empty body and a redirect header, and pasting an empty body into a formatter is not useful. Always include -L when you are exploring an API endpoint and you do not know whether it redirects. For paginated APIs that return Link headers pointing to the next page, combine curl -L --silent with a --header flag for authentication and a small shell loop to walk pages, then paste each page response into FixTools to inspect the structure.

Windows terminals introduce an additional wrinkle: PowerShell and the legacy cmd shell often translate the Unix line endings in curl output to Windows CRLF endings, which strict downstream parsers can reject. JSON.parse is tolerant of any whitespace between tokens including carriage returns, so the FixTools formatter handles this correctly. If you also need to feed the response into a stricter consumer such as a database COPY command or a strict canonical hash, run the response through a normalisation step that strips carriage returns. dos2unix is the classic Unix tool for this conversion, and PowerShell has an equivalent through [System.IO.File]::ReadAllText followed by .Replace.

When the API itself returns an error, the response body is sometimes JSON describing the error and sometimes a plain text or HTML message. Format what arrives, even if it looks unexpected: a formatted JSON error response usually reveals a structured error code and message that maps to API documentation, and a non-JSON response that fails to parse points to a different layer of failure such as an HTTP gateway returning a generic 502 page. The shape of the failure narrows the debugging surface quickly. Always include curl --include to capture the HTTP status alongside the body when you suspect an error, because the status code is the single fastest way to distinguish a parsing problem from an API-level rejection.