JSON number precision when formatting and minifying

A formatting task should not become a numeric conversion

Suppose an API returns the identifier 9007199254740993. You want to make the response readable, not do arithmetic. A workflow that decodes every JSON number into a JavaScript Number and then serializes it can turn that ID into 9007199254740992. The problem occurs during numeric conversion, before indentation is added.

JavaScript's largest safe integer is 9007199254740991. Some larger integers are representable, but consecutive integers are no longer all distinguishable. JSON text itself does not require its readers to use JavaScript's binary floating-point representation.

The JSON formatter and validator keeps the original token text while changing whitespace. It does not rebuild your document from decoded number values. This preserves the input spelling; it cannot recover digits that an upstream system already rounded.

A raw token is not the same thing as a number value

A token is the exact sequence of characters in the source. A value is what a reader interprets those characters to mean. Two spellings can describe the same mathematical value without being interchangeable for an audit trail, an exact-text comparison, or a downstream reader.

Why keep each spelling?

• 9007199254740993: A large ID beyond the consecutive safe-integer range of JavaScript Number. Rounding changes the identifier.
• 0.123456789012345678901: A long decimal whose written digits need not survive conversion to a binary floating-point number.
• 4.0: The same mathematical value as 4, but a different spelling. Keeping .0 preserves the source notation, not a distinct JSON decimal type.
• 1e+30: Exponent notation, including the lowercase e and explicit +, is part of the original token.
• -0: The minus sign is preserved. Other consumers may normalize negative zero to 0.

Preserving 4.0 does not introduce a decimal data type or enforce a unit of measure. Preserving 1e+30 does not guarantee that the next application can store it accurately. If you control an API, agree on a representation with its consumers; a string ID or a decimal-aware parser may be appropriate. Do not change field types without that agreement.

One document, three views

This small response uses the same fixture as the worked example on the JSON tool. The formatted and minified blocks below are produced by the application's actual helpers, not by a separately written approximation.

{"id":9007199254740993,"decimal":0.123456789012345678901,"scale":4.0,"exponent":1e+30,"negativeZero":-0}

{
  "id": 9007199254740993,
  "decimal": 0.123456789012345678901,
  "scale": 4.0,
  "exponent": 1e+30,
  "negativeZero": -0
}

{"id":9007199254740993,"decimal":0.123456789012345678901,"scale":4.0,"exponent":1e+30,"negativeZero":-0}

Minifying this formatted example returns the original compact input exactly. Whitespace inside quoted strings would remain data, not removable layout. Property order, numeric notation, and escape spelling are preserved; this is not key sorting or canonical JSON for signatures.

Valid syntax is a starting point, not a schema check

The validator checks strict JSON syntax. It rejects comments, trailing commas, incomplete values, and single-quoted strings. For example, the following array has a trailing comma; formatting and minifying refuse it rather than silently remove that comma.

{"items":[1,2,]}

• Line 1, column 15: Expected a JSON value; empty input and trailing commas are not allowed.

A syntax pass does not validate a JSON Schema, check an ID against a database, enforce required fields, or prove that the receiving system can represent the values. Those are separate checks at the system boundary.

Duplicate keys deserve a decision

This document passes the syntax check but contains two values under the same name:

{
  "status": "draft",
  "status": "published"
}

• Line 1, column 19: Duplicate key "status" is preserved. Other JSON consumers may keep only its last value.

The formatter keeps both entries. That is source preservation, not a recommendation to send duplicates: another consumer may keep only the last value or reject the object. Resolve the ambiguity with the data producer before relying on the result.

Repeat the check with the tool

1. Copy the original input above into the JSON formatter. Keep an untouched copy of your source.
2. Choose 2 spaces and select Format JSON. Compare the output with the formatted example, especially the ID and the four other number tokens.
3. Select Minify JSON. The tool transforms the current source, so pasting the formatted result back into the source first also checks the round trip shown here.
4. Try the invalid example. The tool should report a location and prevent formatting or minification, not repair the source.

For a document or incident note, Copy fenced JSON wraps the output in a Markdown code block. Then use the Markdown formatter and preview to put the example beside an explanation. Share made-up or redacted data rather than private payloads.

Method and limits

The examples are rendered with formatJson, minifyJson, and validateJson, the same helpers used by the tool. Validation uses jsonc-parser with comments and trailing commas disabled. Formatting applies text edits; minification joins original source-token slices. Neither output path reconstructs the document from JavaScript number values.

The current input limit is 200,000 characters and 49 nesting levels. File imports are limited to 1,000,000 bytes, and formatted output to 2,000,000 characters. Oversized input is rejected rather than truncated. These are tool limits, not limits of the JSON language.

Choose a local command-line or application workflow with the required capacity for larger data, and check its number handling before trusting a parse-and-serialize round trip. Whitespace-only formatting protects the source you have; it does not make invalid, ambiguous, or already-rounded data correct.