Prettifying JSON is a rendering decision, not an edit. The parser reads your text into a value, and the formatter writes that value back out with newlines and indentation. The bytes change; the data does not. That distinction matters because it is the guarantee that lets you paste a formatted document back into production with no thought: object key order is preserved as written, numbers keep their value, strings keep their exact contents including whitespace inside quotes, and nothing is reordered or dropped.
This runs entirely in your browser tab. The text is parsed by the JavaScript engine already loaded in the page, formatted, and written back into the editor. No network request carries it anywhere, which you can prove rather than assume: load the page, disconnect from the internet, and format anyway. It still works, because everything needed is already here.
That architecture is the point rather than a detail. The JSON people format is almost never a toy example. It is an API response they are debugging, which means it routinely carries bearer tokens, session identifiers, customer email addresses, internal database IDs and the shape of a private API. Those are exactly the things that should not become a line in somebody else's request log, and a tool that never receives them has nothing to log.
Two formatting choices are worth making deliberately. Indentation width is cosmetic but consistent with your codebase matters for diffs: two spaces is the common default in JavaScript projects, four elsewhere, and a tab if your linter says so. Sorting keys alphabetically is a bigger decision. It makes two documents comparable at a glance, and it destroys an ordering the author may have chosen deliberately, so sort a copy when you are comparing and leave the original alone when you are shipping it.
What formatting cannot do is repair a document that is not valid JSON. If the parser refuses, you have a syntax error and no amount of reformatting will hide it. Trailing commas, single quotes around strings, unquoted keys, comments and NaN are all common in hand-written configuration and none of them is legal JSON. The validator names the position; fixing it is a one-character job once you know where to look.
A practical habit: format before you diff, never after. Two documents that differ only in whitespace produce a diff full of noise that hides the one line that actually changed. Formatting both to the same shape first turns that into a diff you can read in seconds, which is the whole reason the tool exists.