How to filter json to create a public api response subset
- Step 1Load an internal record sample — Save a representative internal object or list as
.jsonand drop it on the dropzone. It reads in-browser; nothing uploads. - Step 2Decide whitelist or blacklist — For a public API, prefer Keep listed (whitelist) so forgotten fields stay hidden. If the public set is huge and only a few fields are internal, Remove listed (blacklist) is simpler. You choose with the two mode buttons.
- Step 3List your keys — In Keys (comma-separated) type the public-safe keys (for Keep) or the internal-only keys (for Remove) — e.g. Keep:
id, name, price, imageUrl; or Remove:cost, internalId, adminNote, auditLog. - Step 4Set Deep correctly — Leave Deep (all levels) on to apply the rule through nested objects and array elements. For a flat array of records, Deep on with Keep gives the intuitive result. For deeply nested objects in Keep mode, read the nested-whitelist note in edge cases first.
- Step 5Run and inspect — Click Filter Keys. In Remove mode the count is keys removed; in Keep mode it is keys excluded (everything not whitelisted). Inspect the preview to confirm only the public subset remains.
- Step 6Lock in the contract — Copy or download the subset, then turn it into a stable contract with JSON-to-TypeScript for a DTO type or the JSON Schema Generator for validation.
Keep listed vs Remove listed for a public subset
Two ways to reach the same goal. For public APIs, Keep (whitelist) is fail-safe on flat record lists.
| Mode | You list | Result | Best when |
|---|---|---|---|
| Keep listed (whitelist) | Public-safe keys | Only those keys survive; everything else is dropped | You want forgotten fields to stay hidden by default |
| Remove listed (blacklist) | Internal-only keys | Those keys are dropped; everything else stays | The public set is large and the secrets are few and known |
How Keep mode behaves by data shape
Critical for whitelisting: Keep mode keeps a key only at the level where it appears. Tested behaviour.
| Input shape | Keep [name, email] result | Why |
|---|---|---|
| Flat array of records | Each record keeps name,email; all other keys dropped | Intuitive — whitelisting works as expected on list items |
| Object whose top keys are NOT whitelisted | {} (empty) — the whole top level is dropped | Top-level keys are not in the whitelist, so none survive |
| Whitelisted parent + non-whitelisted children | Parent kept but emptied, e.g. { "data": {} } | Children are not whitelisted, so they are removed inside the kept parent |
| Whitelisted parent + whitelisted child | Parent and named child survive | Both keys are in the whitelist at their levels |
Cookbook
Whitelist and blacklist patterns on real-shaped internal records. Values are synthetic; this is what the result panel shows.
Whitelist a flat product list (the safe case)
ExampleOn a flat array of records Keep mode does exactly what you expect. Keys: id, name, price, mode Keep, Deep on.
BEFORE
[
{ "id": 1, "name": "Mug", "price": 9.5, "cost": 3.1, "internalSku": "X" }
]
AFTER (2 keys excluded per record)
[
{ "id": 1, "name": "Mug", "price": 9.5 }
]Blacklist internal fields (large public set)
ExampleWhen the public set is big and only a few keys are internal, Remove is simpler. Keys: cost, internalSku, adminNote, mode Remove.
BEFORE
{ "id": 1, "name": "Mug", "price": 9.5, "color": "blue",
"cost": 3.1, "internalSku": "X", "adminNote": "low margin" }
AFTER (3 keys removed)
{ "id": 1, "name": "Mug", "price": 9.5, "color": "blue" }The nested-whitelist gotcha
ExampleKeep on a nested object: a parent survives only if whitelisted, and is emptied unless its children are whitelisted too. Keys: data, mode Keep, Deep on.
BEFORE
{ "data": { "name": "Mug", "cost": 3.1 }, "meta": { "ts": 1 } }
AFTER (parent kept but emptied — `name`/`cost` not whitelisted)
{ "data": {} }Whitelist parent AND child to keep a subtree
ExampleTo retain a nested field in Keep mode, list both the parent key and the child key. Keys: data, name, mode Keep, Deep on.
BEFORE
{ "data": { "name": "Mug", "cost": 3.1 }, "meta": { "ts": 1 } }
AFTER (1 top key + 1 child excluded)
{ "data": { "name": "Mug" } }Whitelist a flat list of fields you also keep nested
ExampleWhen the same safe keys appear at every level, Keep + Deep retains them throughout. Keys: id, name, mode Keep, Deep on.
BEFORE
[ { "id": 1, "name": "A", "cost": 2, "owner": { "id": 9, "name": "Ada", "role": "admin" } } ]
AFTER
[ { "id": 1, "name": "A", "owner": { "id": 9, "name": "Ada" } } ]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.
Keep mode empties a nested object
By designIn Keep mode a parent object is retained only if its key is whitelisted, and its children only if theirs are. Whitelist a parent without its children and you get { "parent": {} }. To keep a subtree, list the parent and every descendant key you need — or use Remove mode for nested data.
Keep mode returns an empty object
By designIf none of a top-level object's keys are whitelisted, the result is {}. This is the fail-safe behaviour of a whitelist, but it surprises people testing Keep on a single nested object — verify on your real shape.
Casing mismatch in the whitelist
ExcludedMatching is case-sensitive. Whitelisting name will not keep Name. List every casing the data uses, or Keep mode will silently drop fields you meant to expose.
Lookalike internal key not removed (Remove mode)
PreservedListing id in Remove mode strips only id; internalId and costId survive. For a public API, prefer Keep mode so unlisted internal lookalikes never leak.
Internal field you forgot to blacklist
Leaks — fail riskIn Remove mode anything you do not list is exposed — so a forgotten internal key leaks into the public response. This is exactly why Keep (whitelist) mode is safer for public output.
Input is not valid JSON
Invalid JSONIf JSON.parse fails on the internal record, nothing is filtered. Repair it with the JSON Format Fixer first.
File over the 2 MB free limit
BlockedFree accounts cap JSON at 2 MB. Design the subset from a representative sample, or upgrade to Pro for larger files.
Output is pretty-printed at 2 spaces
By designThe subset is always 2-space-indented JSON. Minify it for the wire with the JSON Minifier if needed.
Run button disabled with no keys
ExpectedFilter Keys is disabled until you enter at least one key. In Keep mode an empty list would drop everything, so the run is simply not offered.
Array order preserved
PreservedWhether you Keep or Remove, array element order is unchanged. Only the key selection differs between elements.
Frequently asked questions
Should I use Keep or Remove mode for a public API?
Prefer Keep listed (whitelist) on flat record lists: anything you forget to list stays hidden rather than leaking. Use Remove listed only when the public set is large and the few internal keys are well known.
Why did Keep mode return an empty object?
Keep retains a key only at the level it appears. If none of a top-level object's keys are whitelisted, the whole object becomes {}. On nested data you must whitelist the parent and the children you want to keep.
Does Keep mode work normally on a list of records?
Yes. On a flat array of objects, Keep with Deep on keeps the whitelisted keys in each record and drops the rest — the intuitive behaviour.
How do I keep a nested field with Keep mode?
List both the parent key and the child key (and any further descendants). For example, to keep data.name, whitelist data, name.
Is matching case-sensitive?
Yes. name and Name are different keys. In Keep mode a casing mismatch silently drops the field, so list every casing your data uses.
Will Remove mode strip internalId if I list id?
No — matching is exact. id removes only id; internalId survives. This is another reason whitelisting is safer for public output.
What does the count mean in Keep mode?
It is the number of keys excluded — i.e. everything that was not in your whitelist, across the document.
Can I turn the subset into a type or schema?
Yes. Feed the result into JSON-to-TypeScript for a DTO, or the JSON Schema Generator for validation of the public contract.
Is my internal data uploaded?
No. Everything runs in your browser, so you can design the public subset from real internal records safely.
What is the file size limit?
2 MB per JSON file on the free tier. Use a representative sample or upgrade to Pro for larger files.
Does it keep field and array order?
Yes. Array order and the order of surviving keys are preserved.
Can I both whitelist some keys and blacklist others in one pass?
No — each run uses a single mode (Keep or Remove) and one key list. Chain two runs if you need a mix: e.g. Remove the obvious secrets, then Keep the public set.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.