What a minified webhook payload hides until you indent it

A partner webhook was failing and I had the payload in front of me as one line of text, roughly forty kilobytes wide. Somewhere in that line was the reason a handler was rejecting it. I could scroll horizontally for a while, or I could admit that I cannot read a single-line nested object and that squinting at it is not a debugging strategy.

The first useful thing was not a clever tool. It was indentation. Two spaces, braces on their own lines, arrays broken out. Once the payload was readable I could see the shape: a line_items array, a nested shipping object, a metadata blob. The second useful thing was an error that told me where the JSON stopped making sense. "Unexpected token at character 9137" is far more actionable than a generic parse failure, because character 9137 is a place I can go look.

The case for doing this with rules

Pretty-printing JSON is a solved, fully specified problem. There is no ambiguity about what valid means, no fuzzy case where a judgement call improves the answer, and no reason to ask a model to decide how many spaces to indent. I kept this one deterministic on purpose.

A deterministic formatter has a property I care about for this job: it cannot be talked out of reporting a syntax error. It walks the input, and when it hits a trailing comma, an unescaped control character, or a mismatched brace, it stops and points at the position. It also cannot quietly "help" by repairing my data, which would be the worst possible behaviour for a debugging tool. If the payload is malformed, I want to know it is malformed, not receive a plausible-looking cleaned version that hides the bug I am trying to find.

The output is a clean, indented document and, when the input is broken, a clear error with its location. JSONBeauty does exactly that: paste raw or minified JSON, get a 2-space-indented version plus a clear error if it is malformed, with the error location. Copy-ready, and the feature list says no upload, which matters when the paste is a real customer payload with real identifiers in it. I would rather not send that to a server just to add whitespace.

The error location is the part I kept getting wrong by hand

I used to find malformed JSON by bisection: delete half the payload, parse, repeat. It works, it is tedious, and it is embarrassing the third time in a week. A positional error replaces all of that. "Character N" or a line-and-column pointer turns a guessing game into a single lookup, and it also tells me something about the producer: a trailing comma usually means a serializer was hand-rolled, a raw newline inside a string means something skipped escaping, a truncated document means a timeout upstream.

That second-order information is why I wanted the location and not just a pretty version. The whitespace makes the document readable; the error location makes the failure diagnosable. They are different features, and I would miss the second one more.

What it deliberately does not do

This is where I have to be blunt, because "validate" in the tagline gets over-read. JSONBeauty pretty-prints and reports syntax errors. It does not validate the document against a JSON Schema, it does not check that quantity is a positive integer, it does not diff two payloads, it does not convert to YAML or CSV, and it does not repair malformed input. Those are different jobs with different failure modes, and claiming them here would be dishonest.

A clean indentation tells you the syntax is well-formed; it tells you nothing about whether the contents are what your handler expects. I have shipped code that parsed perfectly and still failed because a field arrived as a string instead of a number. That is a schema problem, and no amount of whitespace will catch it.

So treat the output as formatting help and a syntax check, not a live audit of your API contract and not a certification that a payload is correct. It is decision-support for the ten minutes you spend staring at a response, and the "no upload" property means the paste stays with you. If your current workflow is "paste the blob into an online formatter and hope the site is trustworthy", a local, deterministic, copy-ready step is a small upgrade with a much smaller trust surface.

FAQ

Does it validate against a JSON Schema?

No. It pretty-prints with a 2-space indent and reports syntax errors with their location. Schema validation is a separate job.

Will it fix malformed JSON for me?

No. It reports that the input is malformed and where. Repairing data would hide the bug you are trying to find.

Is my payload uploaded anywhere?

The feature list says no upload; it works on what you paste and gives copy-ready output. It is decision-support for reading a payload, not a live audit of your API.