How to slim api responses by filtering unwanted json keys
- Step 1Save a sample response — Grab one representative response from the endpoint (curl, your browser's network tab, or a saved fixture) and save it as
.json. Drag it onto the dropzone — it reads in-browser, no upload. - Step 2List the keys to drop — Type the fat fields you do not need into Keys (comma-separated) — e.g.
description, metadata, _links, audit, debug. Spaces around names are trimmed automatically. - Step 3Stay on Remove listed — Keep the default Remove listed mode so the keys you typed are the ones removed and everything else survives. (Keep listed is the inverse whitelist mode — useful, but covered separately.)
- Step 4Decide Deep on or off — Leave Deep (all levels) on to strip a noisy key from nested objects and from every array element. Turn it off only if you want to drop a top-level wrapper key but keep its nested contents.
- Step 5Filter and read the count — Click Filter Keys (enabled once you have a file and at least one key). The panel shows the slimmed JSON, a
N keys removedcount, and you can compare the new byte size against the original file size shown above the dropzone. - Step 6Export the slim shape — Copy or download the result as
.filtered.json. Use it as a cache seed or fixture, or as the target schema for a JSON-to-TypeScript type that documents your slimmed contract.
Typical fields to trim from verbose responses
Common bloat in REST payloads and what listing them as Remove keys does. Matching is exact and case-sensitive.
| Key listed | Removed | Kept (lookalikes) | Why trim it |
|---|---|---|---|
| description | description everywhere | shortDescription, desc | Long prose rarely needed on a list screen. |
| _links | _links (HATEOAS blocks) | links, selfLink | Hypermedia links the client never follows. |
| metadata | metadata at all levels | meta, metaData | Internal bookkeeping the UI ignores. |
| audit | audit / nested audit blocks | auditedAt | Created/updated-by trails not shown to users. |
| debug | debug repeated in each item | debugId | Dev-only diagnostics that bloat every element. |
Where the savings come from
How the Deep toggle interacts with list-shaped responses — the common payload-reduction scenario.
| Response shape | Deep on | Deep off |
|---|---|---|
| Array of N items, each with a fat key | Fat key removed from all N items | Items untouched — array elements are nested, so only a top-level key would be hit |
| Single object with nested blocks | Nested noisy keys removed too | Only the top-level key is dropped; nested blocks remain |
Object wrapping a data array | Keys inside each data item removed | Drops the whole data key if you list it; otherwise no change |
Cookbook
Before/after slices of real-shaped REST responses. Sizes are illustrative; the result panel reports the actual byte count for your file.
Trim a product list for a mobile grid
ExampleThe grid needs id, name, price, thumbnail — not the marketing copy or hypermedia. Keys: description, specs, _links, Deep on.
BEFORE
[
{ "id": 1, "name": "Mug", "price": 9.5, "thumbnail": "m.jpg",
"description": "A 350ml ceramic...", "specs": { "ml": 350 }, "_links": { "self": "/p/1" } }
]
AFTER (3 keys removed)
[
{ "id": 1, "name": "Mug", "price": 9.5, "thumbnail": "m.jpg" }
]Strip a debug block from every list item
ExampleA staging API leaks a per-item debug object. Deep mode removes it from all elements at once. Keys: debug.
BEFORE
[
{ "id": 1, "v": "a", "debug": { "ms": 12, "node": "eu-1" } },
{ "id": 2, "v": "b", "debug": { "ms": 9, "node": "eu-2" } }
]
AFTER (2 keys removed)
[
{ "id": 1, "v": "a" },
{ "id": 2, "v": "b" }
]Keep lookalike keys you still need
ExampleListing id removes only id — productId and categoryId survive because matching is exact. Keys: id.
BEFORE
{ "id": "row-7", "productId": 42, "categoryId": 3, "name": "Mug" }
AFTER (1 key removed)
{ "productId": 42, "categoryId": 3, "name": "Mug" }Drop a whole wrapper with Deep off
ExampleWhen you only want to peel off a top-level _meta envelope and leave the payload alone, Deep off is enough. Keys: _meta, Deep OFF.
BEFORE
{ "_meta": { "page": 1, "total": 99 }, "data": [ { "id": 1, "_meta": { "x": 1 } } ] }
AFTER (1 key removed — nested _meta survives because Deep is off)
{ "data": [ { "id": 1, "_meta": { "x": 1 } } ] }Remove HATEOAS links across the document
ExampleHypermedia _links blocks the client never uses, removed from the envelope and each item. Keys: _links, Deep on.
BEFORE
{ "_links": { "self": "/orders" },
"items": [ { "id": 1, "_links": { "self": "/orders/1" } } ] }
AFTER (2 keys removed)
{ "items": [ { "id": 1 } ] }Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
Response file is not valid JSON
Invalid JSONA truncated copy from the network tab, a JSONP wrapper like callback({...}), or a trailing comma will fail JSON.parse. Strip the wrapper or repair it with the JSON Format Fixer first.
Lookalike key not removed
PreservedListing id removes only id; productId, userId, and orderId stay. This is usually what you want for slimming — list extra exact names if you also need them gone.
Casing mismatch
Not removedMatching is case-sensitive. If one endpoint uses Description and another description, list both.
Deep off on an array response
ExpectedArray elements are nested, so with Deep off a top-level array of items is effectively untouched (there are no top-level object keys to remove). Keep Deep on to trim fields inside list items.
Key already absent in this sample
By designIf a key you list is not in this particular response, it is ignored and contributes 0 to the removed count. Other responses from the same endpoint may still contain it.
This does not reduce the live API payload
Client-side onlyTrimming here produces a smaller document, but the API still sends the full response over the wire. To realise the saving in production you must apply the same field removal in a BFF, gateway, or service-worker transform — this tool models the target shape.
Large response over 2 MB
BlockedFree accounts cap JSON files at 2 MB. A heavy paginated dump may exceed that — process a single page or upgrade to Pro.
Output is pretty-printed, not minified
By designThe result is always 2-space-indented JSON. For a true size comparison against a minified wire payload, run the output through the JSON Minifier.
Null/empty fields stay unless listed
PreservedRemoving keys does not clean up null or empty values left behind in other fields. To drop nulls after slimming, use the JSON Null Stripper.
Frequently asked questions
Does this actually make my API faster?
It produces a smaller document so you can measure and model the win, but the live API still sends the full response. You realise the saving by applying the same key removal in a BFF, gateway, or edge worker — this tool defines the target shape.
Will removing id break my client?
Only if your client relies on id. Matching is exact, so listing id removes just id and leaves productId/userId intact. List exactly the keys your client does not read.
Can I trim fields inside every item of a list?
Yes — keep Deep (all levels) on. It removes the listed keys from each element of an array, not just the top level.
Why is description gone but shortDescription kept?
Matching is exact, not substring. description and shortDescription are different keys; list both if you want both removed.
How do I measure the size reduction?
Note the original file size shown above the dropzone, then compare against the slimmed output. For a fair comparison to a minified wire payload, minify the result with the JSON Minifier.
Can I keep only the few fields I need instead?
Yes, switch to Keep listed mode — but it behaves differently on nested data, so read the public-API subset guide first.
Is the output minified?
No. Output is pretty-printed with 2-space indentation. Run it through the JSON Minifier for a compact version.
Does it preserve the order of my fields and items?
Yes. Array order and all unlisted keys are kept exactly; only listed keys are removed.
What about a JSONP or wrapped response?
It must be plain JSON. Remove any callback(...) wrapper or HTML before loading, or JSON.parse will fail.
Can I generate a type from the slimmed shape?
Yes — feed the result into JSON-to-TypeScript to get an interface that documents your slimmed contract, or JSON Schema Generator for a JSON Schema.
Is my production data sent anywhere?
No. Parsing and filtering happen in your browser, so you can paste real responses safely.
What is the file size limit?
2 MB per JSON file on the free tier. Larger files need Pro or splitting into pages.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.