JSON Formatter
Format JSON for review or transport, inspect its structure and byte size, and flag duplicate keys or precision risks before reuse.{{ summaryTitle }}
{{ summaryLine }}
{{ computation.values.formatted_text }}
Line stream
{{ computation.values.ndjson_text }}| Path | Pointer | Type | Detail | Preview | Copy |
|---|---|---|---|---|---|
{{ row.path }} | {{ row.pointer }} | {{ row.type }} | {{ row.detail }} | {{ row.preview }} |
| Check | Status | Evidence | Next step | Copy |
|---|---|---|---|---|
| {{ row.check }} | {{ row.status }} | {{ row.evidence }} | {{ row.next_step }} |
A JSON file can be hard to review for two very different reasons. Dense layout can hide the structure, while valid-looking data can still contain duplicate object names or numbers that another system reads differently. Indentation fixes the first problem; it does not settle the second.
JSON represents one value at its root. That value may be an object, array, string, number, Boolean, or null. Spaces and line breaks outside strings do not change the data, so the same value can be printed as readable multi-line text or compact transport text. Object member order is usually presentation rather than meaning, while array order remains part of the data.
Strict JSON does not allow comments. JSON with Comments, often called JSONC, is useful in editors and configuration drafts, but comments must be removed before the result is sent to a strict JSON receiver. Formatting also rebuilds text from parsed values, so it is not a source-preserving edit.
| Form | Useful for | Important boundary |
|---|---|---|
| Readable JSON | Code review, debugging, and hand editing | Whitespace changes, but parsed data should stay the same. |
| Compact JSON | Requests, storage, and command-line handoffs | Smaller text is not validation against a schema. |
| Sorted-key JSON | Stable visual comparison | Sorting alone is not a complete canonicalization or signing scheme. |
| JSON Lines | Streams with one independent JSON value per line | A root array must be split into its items; the brackets are not part of the stream. |
Duplicate names are especially risky because parsers disagree about whether to reject them, keep the first value, keep the last value, or expose every occurrence. Long integers and high-precision decimals pose a different risk: a browser may round them while parsing even though the original token looked exact. Treat both findings as reasons to repair or verify the producer before reusing the output.
How to Use This Tool:
Choose the output contract first, then format and review the parsed value before copying it elsewhere.
- Paste the source into JSON source and select Strict JSON or JSONC comments. A parse error must be fixed before any result is produced.
- Choose Review for two-space readable output, Transport for compact output, or Signature candidate for compact text with recursively sorted object keys. Use Custom when indentation or key order needs a different policy.
- Select a Line stream only when the receiver expects JSON Lines. Root array items requires an array at the root; a non-array produces a review warning instead of a false stream.
- Read Format audit before reusing the text. Repair duplicate names or risky numbers at the source, and confirm that the root type and byte size fit the receiving system.
Interpreting Results:
The formatted text is ready only when parsing succeeds. A Pass for syntax means one JSON value was parsed; it does not prove that required fields, types, or business rules are correct.
- Use the node paths to confirm that important values remain under the expected objects and arrays.
- Treat a duplicate-name or number-precision finding as a data-quality warning, even when readable output appears normal.
- For a signature or checksum workflow, apply the receiver's named canonicalization standard after this review. Sorted keys alone are insufficient.
Technical Details:
Formatting is a parse-transform-serialize operation. The source first becomes a JSON value, optional object-key ordering is applied recursively, and the value is serialized with the selected whitespace and escaping rules. Array order never changes.
Transformation Core:
| Stage | Rule | Consequence |
|---|---|---|
| Dialect handling | JSONC removes line and block comments outside quoted strings. | Comments do not appear in the result. |
| Parse | The cleaned text must parse as one JSON value. | Invalid syntax stops the transformation. |
| Key ordering | Preserve parsed order, sort A to Z, or sort Z to A at every object depth. | Object presentation may change; arrays retain their sequence. |
| Serialization | Indent with 0 to 8 spaces, optionally add a final newline, and optionally escape <, >, &, or / in strings. |
The emitted text follows the chosen receiver-facing style. |
| Line stream | Emit one compact value, or one compact line for each root-array item. | Root-array mode refuses to pretend that a non-array is a record stream. |
Formula Core:
Payload comparisons count the UTF-8 bytes in each text form. A non-ASCII character may occupy more than one byte, so character count and byte count are not interchangeable.
B is reported separately for the source, formatted text, and compact text. Counts are whole bytes with no rounding. Formatting can increase size through whitespace; compacting removes that whitespace but does not compress string content.
Diagnostic Rule Core:
| Check | Exact rule | Limit |
|---|---|---|
| Source size | Reject input larger than 2 MiB measured as UTF-8. | 2,097,152 bytes |
| Duplicate object names | Scan each parsed object scope and report repeated member paths. | Every detected repeat contributes one warning. |
| Unsafe integers | Flag parsed integers outside the browser's exact safe-integer range. | Exact agreement is not guaranteed beyond ±(253 − 1). |
| Precision-risk literals | Flag numeric tokens with more than 15 significant decimal digits. | Review even when the parsed number still looks plausible. |
| Node ledger | Traverse objects and arrays in result order. | First 300 nodes |
Duplicate detection examines the token stream before serialization because ordinary parsing may already have collapsed repeated names. The numeric checks are warnings rather than arbitrary repair rules; exact identifiers and decimal quantities are safer as strings or in a decimal-aware system when their precision must survive unchanged.
Privacy and Limits:
Formatting, inspection, file loading, and exports run in the browser, and the pasted source is excluded from the share URL. The page does not upload the JSON for processing.
- JSONC comments are intentionally removed.
- Duplicate-name warnings cannot restore a value that parsing would discard; repair the original source.
- The audit is not a JSON Schema validator, security scanner, or complete canonicalization implementation.
Worked Examples:
Compact array for a one-line handoff
With [true,null,"x"], Transport and Single compact line both produce [true,null,"x"]. The root remains an array, the output is 15 UTF-8 bytes, and the audit reports no findings.
References:
- The JavaScript Object Notation (JSON) Data Interchange Format, RFC Editor, December 2017.
- JSON Canonicalization Scheme (JCS), RFC Editor, June 2020.
- JSON Lines format documentation, JSON Lines.