A Codrenix Toolbox guide

A practical way to format and validate JSON

A hands-on guide to reading, checking, and safely sharing JSON from APIs, settings files, and exports.

By Codrenix Team · Published November 5, 2026 · Updated November 5, 2026

JSON is easy to produce and surprisingly easy to break. A missing comma in a deployment setting, an unexpected null in an API response, or a pasted quotation mark can turn a readable object into an error that takes longer to find than to fix. A formatter helps reveal structure; a validator confirms syntax. Used together with a few careful checks, they make JSON easier to inspect without pretending that valid syntax guarantees correct data.

Start with the exact source

Copy the complete value from the place that produced it, rather than a screenshot or a manually retyped excerpt. A partial response may omit the opening bracket or the comma that actually caused the failure. If the source is a browser console, select the raw response when possible; if it is a settings file, keep a separate untouched copy before experimenting. That gives you a trustworthy baseline and makes it easier to undo an accidental edit.

Check whether you copied one JSON value or a stream of several values. Standard JSON expects one top-level object, array, string, number, boolean, or null; two adjacent objects are not one valid document. Some logs display a sequence of JSON records, one per line, which needs a line-aware reader rather than a single-document formatter. Knowing which format you have prevents a good tool from appearing to reject data that was never meant to be one document.

Format to make the shape visible

Minified JSON saves bytes but hides relationships. Indentation makes nested arrays, sibling properties, and repeated records visible, so a person can scan a response without counting braces. For example, a 4 KB product response may contain 18 products, each with a price object and a stock array; pretty printing makes it much quicker to notice that only one product has an unexpected extra field. Formatting changes whitespace, not the underlying values.

Choose an indentation width that suits the task, usually two spaces for compact configuration files or four for a printed review. Consistency matters more than a particular number. Avoid treating the formatted version as a semantic diff: object property order may change in some pipelines, and long strings remain long. If the result will be committed, check the repository's existing style so a formatting-only change does not create hundreds of distracting lines.

Use validation errors as a map

When validation fails, read the reported line and column as a starting point, not a verdict about the exact character to delete. Parsers often stop at the first place where the grammar becomes impossible, while the actual mistake is one line earlier. A missing comma after a property can make the next property name look invalid. Inspect a few characters on both sides, then check whether the surrounding object or array has the expected commas, quotes, and closing delimiter.

JSON strings require double quotes, property names must be quoted, and trailing commas are not allowed in strict JSON. Comments are also outside the standard, even though several programming languages accept them in configuration files. If a team uses JSONC or JSON5, verify that the consumer supports that dialect before removing comments or changing syntax. A file can be accepted by an editor extension and still be rejected by the production parser.

Check the character immediately before the reported position for a missing comma.
Match each opening brace or bracket with its correct closing character.
Keep numbers, booleans, and null unquoted when they are meant to be values.

Separate valid syntax from correct meaning

A successful parse only says the document follows JSON grammar. It does not say that an order has a real customer, that a date is in the right time zone, or that a quantity is within an allowed range. Before relying on the data, compare its structure with the application's schema or a known-good example. Check required keys, expected types, allowed values, and whether a field may be absent, null, or an empty string; those cases often mean different things to software.

Be especially deliberate with numbers that resemble identifiers. A postal code such as 02139 loses its leading zero if represented as a number, while a large account number can exceed the exact integer range of some runtimes. Such values are usually safer as strings. Likewise, a timestamp needs a stated unit and time zone, and a decimal monetary amount may require a currency and a precise rounding rule. Formatting cannot make those decisions for you.

Inspect large responses without losing context

For a large API response, first format a small representative sample, then search for the record or property that seems unusual. If there are 5,000 rows, opening every nested branch is rarely the fastest route. Search by a stable identifier, inspect neighboring fields, and compare the record with one that works. If the response is sensitive, remove or replace names, tokens, addresses, and payment details before pasting it into a browser-based tool.

When repeated objects appear, compare their shapes rather than just their values. One record may have a missing key, a string where the others have a number, or an empty array where the application expects at least one entry. Preserve a minimal failing example that still reproduces the problem, but do not assume that a short sample explains a bug caused by a rare record much farther down the response. Record where the sample came from and what was omitted.

Make edits in a reversible workflow

Keep the original text, format a working copy, and change one suspected issue at a time. Validate after each edit so the next error is not hidden behind the first. Once syntax passes, run the application's own tests or schema checks; a browser formatter is not a substitute for the system that consumes the file. For deployment settings, make a small change in a staging environment before applying it to production, especially when a value controls access or billing.

Before sharing a corrected file, compare it with the original and make sure only intended values changed. Formatting may create a large visual diff, so a structured JSON comparison can be useful when the goal is to detect changed values rather than whitespace. If the file contains secrets, do not paste it into a public issue or retain it in a shared clipboard history. Clean test values are safer than redacting credentials after they have already been exposed.

Worked examples

Find a missing comma in a service setting

Inspecting the previous line matters because the parser reports where it became confused, not necessarily where the omission happened. After the syntax check succeeds, confirm that 30 is the intended timeout unit and that a retry limit of 4 is supported by the service.

Input

A 14-line configuration has a timeout value on line 8 followed by a retryLimit property on line 9, with no comma between them.

Output

The validator points near retryLimit; adding a comma after the timeout value produces valid JSON.

Preserve an identifier with a leading zero

The JSON is valid either way, but the numeric version has already lost information. A formatter cannot infer the missing zero; compare with the authoritative customer record and then check the receiving schema expects a string.