Prettify JSON until you can actually read it

Two spaces, unless you are handing the file to an ecosystem that has already decided otherwise. JavaScript, Prettier, npm, jq, Ruby, Rust and .NET all land on two; Python's json.tool, PHP's JSON_PRETTY_PRINT and the AWS CLI all write four; Go has no default because MarshalIndent makes you pass one. The practical rule is to match whatever the file's neighbours use, because a file that changes indentation shows up as a whole-file diff the next time anyone touches it.

No. RFC 8259 allows space, tab, carriage return and line feed between any two tokens and gives that whitespace no meaning, so indenting a document, aligning its values or folding a deep branch onto one line all produce the same parsed value. Re-minify anything this page prints and you get the bytes you started with, character for character — the layout is the only thing that moved.

It pads each key with spaces so every value inside one object starts in the same column, which turns an array of similarly shaped records into something you can read down like a table. Two things are worth knowing before you commit it: the padding is real bytes, and the column is set by the longest key in that object, so adding one long property name re-indents every sibling line and your next git diff shows the whole block as changed. Alignment caps at 32 characters here, so a single freak key cannot push the values off the screen.

Fold it before you read it: set Expand to 2 levels and the top of the document lays out normally while everything below stays on one line each, so you get the shape without 430,002 rows of detail. That is the measured figure — a 4.98 MB single-line array of order records becomes 430,002 lines at two-space indentation, and drawing all of them is what makes a browser tab stall. The pane here stops at 5,000 lines for that reason, while Copy and Download still hand over the whole thing.

Not here, because a number is never turned into a JavaScript number in the first place. Anything above 9,007,199,254,740,991 is stored as the nearest 64-bit float once JSON.parse touches it, and whether that shows depends on pure luck: 1275892450392698880 survives because a double happens to hold it exactly, while 1275892450392698881 comes back as ...880 and 12345678901234567890 comes back as 12345678901234567168. This page prints the literal you typed, so trailing zeros in 1.500 and every digit of a snowflake ID are still there afterwards.

Because no standard says what pretty-printed JSON should look like. RFC 8259 defines where whitespace may appear and stops there, so every implementation invents the rest: whether a space follows the colon, whether an empty object prints as {} or across two lines, whether a short array of numbers stays inline, and how a top-level scalar is treated. Those choices are why two formatters can both be correct and still disagree on almost every line of the same file.

Barely, and not enough to choose layout on: V8's JSON.parse reads the 8.35 MB indented form of a document and its 5.22 MB minified form in the same 18 milliseconds, because skipping whitespace is close to free next to building the values. The cost of indentation is bytes on the wire and in storage, not CPU at the far end, which is why the sensible split is pretty in the repository and minified in the request.