Format JSON for Debugging, See Past [object Object]

In JavaScript, when you concatenate an object with a string or pass it to a function expecting a string, the engine calls the object's toString() method. The default toString() on plain objects returns "[object Object]". This happens in template literals, string concatenation, and some logging frameworks that stringify their arguments before writing them to a log sink. The actual data is still present in memory; the display mechanism is simply using the wrong serialization method. The fix is to explicitly convert the object to a JSON string before displaying it, so the full structure becomes readable text.

The correct pattern for logging a JavaScript object's complete structure is console.log(JSON.stringify(obj, null, 2)), which converts the object to a formatted JSON string with 2-space indentation. If the object has already been serialized to a JSON string by an API client, a database driver, or a message queue consumer, you already have a raw JSON string that can be copied directly. In either case, pasting the resulting JSON into FixTools produces the full structure with syntax highlighting, making it far easier to identify a field with an unexpected value than reading a dense monospaced console output line-by-line.

Debugging with formatted JSON delivers the most value when data has more than two or three nesting levels. A flat object with five keys is easy to read in any form. An API response with arrays of objects, each containing nested sub-objects and further arrays, is nearly impossible to read unformatted. Proper indentation aligns each key to its nesting level, making parent-child relationships between fields visually obvious. It becomes straightforward to confirm that a specific path like response.data.items[0].user.address.city exists, has the right type, and contains the expected value without writing a test first.

Several spec edge cases surface specifically during debugging. JavaScript serialises Date objects to ISO 8601 strings via the Date.prototype.toJSON method, but the parsed JSON does not contain a Date type, so the round-tripped value is a string and any code expecting a Date instance throws. Large integers beyond Number.MAX_SAFE_INTEGER (2^53 - 1) lose precision silently: a Twitter or Stripe identifier like 9007199254740993 becomes 9007199254740992 when round-tripped through JSON.parse and JSON.stringify. Trailing commas, comments, and NaN are not allowed in strict JSON, so when JSON.stringify(obj) silently omits a field, the source object likely had undefined, a function, or a Symbol value at that key, none of which are representable in JSON. Knowing these edge cases turns mysterious bugs into one-line diagnoses.

Debugging workflows benefit from pairing the formatter with structured logging conventions. Pino, Bunyan, and Winston emit one JSON object per log line, where each object includes a timestamp, log level, message, and arbitrary context fields. To investigate a specific request, copy the relevant log lines, paste them into FixTools one at a time (each line is its own document), and read the formatted view of each. For Kubernetes pods, kubectl logs piped through grep extracts the lines of interest, and FixTools formats the JSON payload of any single line for human inspection. This pattern scales from local development to production incident investigation because the same log format works at every tier, and the debugging tool stays the same regardless of where the log originated.