JSON Formatter Guide

What this reference covers

Use JSON Formatter when a response is difficult to read, a configuration file fails to parse, or a test fixture needs consistent indentation. This guide explains the parsing contract and the changes that formatting can introduce. It is not a schema validator, a secret scanner, or a promise that the receiving application will accept your data. Keep an untouched copy before using Format, Minify, or Repair, especially when the failure you are investigating depends on the original bytes.

Valid JSON is not the same as valid JavaScript

JSON object keys and string values require double quotes. Comments, single-quoted strings, trailing commas, and the JavaScript value undefined are not standard JSON. A top-level array, string, number, Boolean, or null can be valid JSON even when your application expects an object. That distinction explains why a formatter can accept a document that an API subsequently rejects.

For example, {"enabled":false,"note":null,"id":"001"} contains three deliberately different types. Changing false to "false" produces a string rather than a Boolean. Removing note is not the same as retaining an explicit null. Turning "001" into 1 removes information that may be meaningful to an order system. Formatting should make these decisions visible, not make them for you.

Troubleshooting syntax errors without destroying evidence

Read the first reported error, then inspect the surrounding text rather than changing unrelated fields. An error near the end often comes from a missing closing bracket earlier in the document. A copied server log may include a timestamp before the JSON or a stack trace after it. Remove that surrounding material only in a working copy, preserving the original response separately.

Check whether you copied an actual response body or a quoted representation of one. A string containing escaped JSON is still a string after the first parse. Parse a nested representation only when its contract explicitly requires that operation; repeated decoding can turn intended text into a different structure. Error wording and offsets can vary between browser engines, so report the browser and a small synthetic reproducer rather than relying on one error message alone.

Protect exact identifiers and numbers

The formatter uses JavaScript JSON parsing and serialization. JavaScript's largest safe integer is 9007199254740991. A larger numeric identifier can lose precision during parsing, before indentation is even applied. In a standard JavaScript number round trip, the numeric token 9007199254740993 can become 9007199254740992. This is a language-level example, not a measured cross-browser performance claim.

Represent exact account, order, and database identifiers as strings in the producing system. Quoting a value after it has already rounded cannot recover the missing digits. Numeric spelling may also change: 1.0 can serialize as 1, and exponent notation may be rewritten. For signed payloads, financial source records, or byte-for-byte fixtures, retain the original text and use a parser suited to the required precision. A visually tidy result is not evidence of numerical fidelity.

Duplicate keys and structural changes

An object such as {"mode":"draft","mode":"published"} has duplicate property names. JavaScript parsing keeps the later value; serialization cannot reconstruct both original entries. If duplicate keys are part of a security investigation or parser compatibility test, formatting is the wrong preservation step. Inspect the raw text with a suitable duplicate-key checker instead.

Object key presentation is not a business ordering guarantee, either. Numeric-looking keys can appear in a different order after serialization. Arrays, by contrast, represent ordered elements: do not sort an array merely to make a visual comparison easier unless the receiving contract permits it. Keep a raw-text comparison and a semantic comparison separate, and note which one your regression test actually uses.

Choose Format, Minify, or Repair deliberately

Format and Minify both serialize a parsed value. Format makes nesting easier to inspect; Minify removes unnecessary formatting whitespace. Neither preserves the original bytes, strips confidential fields, validates a business schema, or repairs a broken authorization token. Compare the resulting values and types, not just the visual layout or character count.

Repair is a separate action that attempts common syntax fixes. It can change meaning while making a document parseable. Review every repair against the original, then run the receiving application's test. Never repair the only copy of malformed input that is supposed to reproduce a parser error. A repaired example is a new fixture and should be labeled accordingly.

Large inputs and the tree-view limit

The tree view is limited to 1,500 nodes. A truncated tree is not a complete visual inventory of the document. Do not infer that an unshown field is absent. Search or inspect the complete source using a workflow suitable for its size, and keep the original available while investigating.

Larger inputs use a browser worker where supported, but this does not make memory unlimited. Source text, parsed objects, formatted output, and interface state can coexist in memory. A file's compressed download size is not a reliable estimate of that working set. Start with a reduced synthetic sample, close unrelated memory-heavy tabs, and move to a local command-line workflow when the browser becomes unresponsive. There is no universal safe file-size guarantee across desktop and mobile devices.

A safe handoff procedure

Begin with synthetic data that preserves the structure of the failure. Replace secrets, real email addresses, private URLs, and customer identifiers before copying the fixture into an issue, chat, or repository. Redaction is your responsibility; successful formatting does not prove that confidential fields have been removed. Review nested objects and arrays, not just the first screen of output.

Record the original content type, the expected schema or test, any fields intentionally removed, and whether identifiers must remain strings. Run the receiving test separately and verify that the same failure still occurs. Use Diff Checker for an explicit before-and-after comparison. When starting from CSV, use CSV to JSON Converter and check quoted fields and header collisions before formatting.

Browser privacy checks and support

Public tool processing is designed to happen in the browser. That does not mean opening the website creates no network traffic: page delivery, code downloads, security services, and optional analytics are separate from the tool's input. Review Data handling and the local-file privacy check before working with sensitive material. A network observation is evidence for that tested session, not a guarantee about every future release.

For support, provide the tool URL, browser version, action taken, expected outcome, and the smallest non-sensitive example that reproduces the issue. State whether the problem concerns syntax, rounding, duplicate keys, the tree limit, or a repair result. Do not attach production credentials or a full customer response.

Technical references

The parsing behavior is documented in MDN's JSON.parse reference. The integer boundary is documented in Number.MAX_SAFE_INTEGER. These references describe JavaScript behavior; this page does not claim an independently completed compatibility benchmark for every browser version.