JSON Formatter

ECMA-404 (the JSON Data Interchange Standard), which is the same spec the platform JSON.parse implements. That means six value types only: object, array, string, number, true, false, and null. Numbers must be base-10 with no leading zeros (other than the literal 0), no NaN, and no Infinity. Strings must be double-quoted with the standard escape set. Whitespace between tokens is allowed; trailing commas, comments, and unquoted keys are not. Calcoid does not add a permissive layer on top, so anything that parses here parses everywhere a strict JSON parser runs.

ECMA-404 forbids them. The grammar for an object reads as { } or { member (, member)* } with no optional comma after the final member, and the same shape applies to arrays. JavaScript object literals tolerate a trailing comma since ES5, which is why JSON written by hand often grows one accidentally. JSON does not, and a strict parser is required to reject it. If you need to keep trailing commas in your config files, use JSON5 or JSONC (see the next answer) and strip them before parsing as strict JSON.

Not in strict JSON. ECMA-404 has no production for // line comments or /* block comments */, and JSON.parse will throw on either. The two common workarounds are JSON5 (a superset that adds comments, trailing commas, single quotes, unquoted keys, and hex literals) and JSONC (JSON with Comments, used by VS Code settings, tsconfig.json, and similar tools, which adds comments and nothing else). Calcoid sticks to strict JSON because the formatter is meant for data interchange. If your input has comments, run it through a JSON5 or JSONC stripper first and then format the cleaned output here.

Pretty-print when a human will read or diff the JSON: config files in a repo, API responses you are debugging, fixtures in tests. Minify when the JSON travels over a network or sits in storage: response bodies, localStorage values, message-queue payloads, log shipping. The minified version of a typical 2-space pretty-printed payload is about 30 to 60 percent smaller before any HTTP compression, and that compounds across cache hits and CDN bandwidth. For payloads that already get gzip or brotli on the wire, the win shrinks but does not disappear, because the smaller pre-compression input still compresses faster and to a slightly smaller output.

Two main uses: clean diffs and stable hash comparison. JSON.stringify preserves insertion order, so two semantically identical objects with different key orders produce different strings and different SHA-256 hashes. Sorting keys recursively gives you a canonical form where the same data always serializes to the same bytes, which makes git diffs of generated JSON readable, makes ETags and content hashes deterministic, and makes 'are these two API responses equal' a one-line string comparison instead of a deep object walk. Order-sensitive consumers (a handful of legacy SOAP-style APIs, some HMAC-signed request schemes) are the only case where you should not sort.