Why a JSON formatter needs a token counter
Every other JSON formatter on the web optimises for one reader: a human. That is the right default in an editor and the wrong one in a prompt, because the model does not benefit from indentation and you are billed for every space of it.
This one shows both sizes at once. Format it to read it, minify it to send it, and the counter tells you what the difference is worth. On a deeply nested payload the gap is routinely thirty to fifty percent of the tokens.
Why sorting keys matters for caching
Prompt caching matches on an exact prefix. If your serialiser emits keys in insertion order, two logically identical payloads can produce different bytes and miss the cache entirely.
Sorting keys alphabetically makes serialisation deterministic, which turns an unreliable cache hit into a reliable one. On a workload where the same reference document is sent repeatedly, that is worth considerably more than the formatting itself.
Where to go from here
If your data is tabular rather than nested, JSON is probably the wrong format altogether — the data format optimizer compares it against CSV and four other serialisations, and the cheapest is usually not JSON.
For a payload you have already minified, the prompt optimizer catches the whitespace that survives outside the JSON itself.