Build a Minimal JSON Repro for a Bug

By pastesite editorial · Published 2026-11-05 · reviewed 2026-11-04 · 3 min read

AI-assisted article. Reviewed by Codebuff automated editorial review on 2026-11-04. Examples are illustrative, not real user data.

A support thread that starts with a multi-megabyte response dump usually stalls. The person reading it cannot tell which field mattered, and the person who posted it has handed over far more data than the bug needs. A minimal reproduction is a smaller file with the same failure. The work is mostly deletion in a copy, with one rule: after each pass, confirm the reduced file still fails the same way.

Start from one failing request

Pick a single request that failed, not a whole session. Keep its method, path, status code and response body, because those four things let someone else replay it. If the failure depends on a sequence, describe the sequence in one sentence instead of pasting every request that came before it.

Work in a copy and leave the original untouched. A reduced file is a communication artifact, not evidence. If an investigation later needs the full body, the untouched copy is still there and nothing was overwritten in the name of tidying up.

Delete in passes, not field by field

Removing one key at a time is slow and proves little. Remove whole groups first: every field you do not recognise, every repeated array element, every string longer than a sentence. Then check whether the failure survives. When a removal breaks the reproduction, put that group back and split it in half instead.

The example below starts from an invented order response and ends with a file that still fails. The customer block, the marketing metadata and nine of the ten line items are gone; the nested discount object that triggers the bug stays exactly where it was.

// before: 92 KB, most of it unrelated to the failure
{ "id": "ord_EXAMPLE", "customer": { ... }, "items": [ ...10 items... ], "shipping": { ... } }

// after: 14 lines, same failure
{ "id": "ord_EXAMPLE",
  "items": [ { "sku": "SKU-1", "quantity": 1, "unit_price": 1200,
               "discount": { "kind": "percent", "value": null } } ],
  "currency": "USD" }

Keep the shape that triggers the bug

Types matter as much as names. A null where a string is expected, an empty array instead of a missing key, or a number encoded as a string can be the whole bug. When you replace a value, keep its JSON type. Replacing an object with the string REMOVED often removes the failure along with the data.

Counts matter too. If a discount only fails on the tenth line item, an array of one will not reproduce it. Say the required count in your message and keep the two items that show the pattern, rather than padding the file with eight copies of the same object.

Prove it still fails, then say what you removed

Run the reduced file through the same code path before sending it. The check should fail for the same reason, with the same error message or status code. A file that fails differently is a new bug report, and it will cost the reader their first reply.

End the report with one line about what was removed: customer fields, other line items, unrelated headers. That tells the reader the file is safe to share and that the reduction was deliberate rather than a careless partial paste.

Sources and editorial review

Prepared with AI assistance and checked against the linked JSON sharing page at the reviewed revision. The order fragments are fictional and were not executed against a real service. A person should still confirm the worked example matches the reader's own failure before publication is treated as final.