JSON Formatter With Line Numbers

Software collaboration runs on shared coordinate systems. Git references commits by hash, pull requests reference files by path and lines by range, and chat tools support code blocks that wrap inline content into a referenceable form. JSON discussion, by contrast, often happens without any agreed coordinate system: developers describe field positions by path (data.results[2].address.city), by relative position (the third item), or by approximation (somewhere near the bottom). When the same JSON document is being discussed by multiple people in different windows, these descriptions create constant low-grade friction. A line-numbered formatter gives JSON discussion the same coordinate system that text editors give source code discussion, which lets a single short reference like "line 247" replace several sentences of contextual description.

Line numbers in formatted JSON depend on the indent setting. The same logical document produces different line counts when formatted with 2-space versus 4-space versus tab indentation, because the rendered text wraps differently and the total number of lines varies with leading whitespace width. For a stable line number coordinate system, agree on an indent setting before the discussion starts. The FixTools default of 2-space indent matches Prettier and most JavaScript projects, so it is a reasonable team default. If your project uses 4-space JSON indent, use that consistently across your team formatting workflows and your line number references will translate identically between collaborators.

Parse error messages from any JSON parser include a line and column position for the first error encountered. The FixTools formatter surfaces this position in the error display when input fails to parse, and the position maps directly to the gutter in the formatted output (or to the input view if the parse fails before formatting completes). This dual mapping accelerates the fix loop: the parser reports the position, the line number gutter shows where to look, and the fix is applied at the exact byte without searching. For long JSON documents with deeply nested structures, this is dramatically faster than the alternative of "syntax error somewhere in the file" that older parsers used to produce.

For pull request reviews of JSON files, the GitHub and GitLab diff views already include line numbers, so the line-numbered formatter is most useful for content that is not in a file yet. Examples include API responses copied into a comment for discussion, log lines extracted from a debugging session, or fixture data being proposed for inclusion in a future test. In each case, formatting the snippet with line numbers in FixTools and pasting the formatted output as a code block in the review comment gives reviewers the same coordinate system that they would have for a committed file. This makes ad-hoc JSON references first-class participants in the review conversation rather than awkward attachments.

Line numbers also help with documenting JSON Schema validation errors. When a tool such as Ajv or the VS Code JSON language server reports a schema validation error, it typically includes a JSON Pointer reference to the failing position (for example, /data/results/0/address/postalCode). Pasting the source into a line-numbered formatter and using the Pointer path to navigate visually gives both the path-based reference (for the validation tool output) and the line-based reference (for human discussion). This dual coordinate system is the most powerful way to discuss schema validation findings because it bridges the machine-friendly Pointer format and the human-friendly line number format in a single view.