Bulk edit for form-data and url-encoded request bodies

[stewartmuhanuzi]

Insomnia already has a bulk (text) editor for headers and query parameters, but not for request bodies. For form-data and url-encoded bodies you can only add fields one row at a time.

The case for it

I regularly work with endpoints taking 20+ form-data fields, including indexed array fields and a couple of file uploads:

park:Bwindi Impenetrable
lakes[0]:Victoria
lakes[1]:Bunyonyi
rivers[0]:Nile
rivers[1]:Kagera
mountain:Rwenzori
peak:Margherita
altitude:5109
surveyed_at:2025-01-15 09:30:00
summary:Montane rainforest on the Albertine Rift
...

Entering that by hand is 20+ rows of click-type-tab. Sharing it with a teammate means screenshots or a full collection export. Adjusting a few values means hunting through the list.

The current workaround, from #1745, is to switch the body type to "Other", paste, and switch back to Multipart, accepting a dialog that says your existing body will be lost. That works, but losing data to enter data isn't a great story.

This was requested in #1745 (Oct 2019, 5 👍, asking for both form-data and url-encoded). It was never triaged (it still carries needs-triage), and the stale bot closed it in 2022 without a maintainer ever weighing in. I'd like to pick it up rather than open a duplicate and let it go the same way.

Proposed format

Same idea as the existing header/parameter bulk editors, one pair per line:

name:value        enabled
//name:value      disabled

with a placeholder in the empty editor stating those rules.

One design note worth raising up front

I'd suggest this format differs deliberately from the three existing bulk editors, because they currently lose data on a round trip:

1. They skip disabled rows when serializing (if (header.disabled) continue) and then replace the whole array on parse, so toggling bulk edit on and off permanently deletes your disabled rows. The // prefix fixes that.
2. They .trim() values. That's correct for HTTP headers, which are whitespace-insensitive per RFC 9110. Form-data values are opaque bytes, so trimming silently corrupts them. Writing name:value with no space after the colon means the value never needs trimming, and the round trip is lossless.

Some rows can't be carried by the text format: file attachments, values containing newlines, and rows with a multiline content-type. Those would be held out of the buffer and restored at their original index, so switching modes never drops an attachment or changes multipart part order.

Happy to instead match the existing format exactly if consistency is preferred. I'd just rather raise the tradeoff than pick silently.

Scope

• form-data and x-www-form-urlencoded bodies
• A toggle in the body toolbar, alongside the content-type dropdown
• No changes to the existing header/parameter/mock-header editors

Bringing those three onto the same lossless format would be an obvious follow-up, but it changes existing behaviour, so it seems better as a separate PR than bundled into this one.

Status

I have this implemented and passing CI locally (lint, type-check, full unit suite), with unit coverage of the parse plus end-to-end tests asserting the bulk path produces a multipart body byte-identical to the equivalent key-value rows. Happy to open a PR if there's interest, or to adjust the approach first if any of the above is the wrong call.

[poojithap11]

Hi @stewartmuhanuzi

Thanks for the detailed feedback and for explaining your use case.

We understand that Insomnia currently supports bulk text editing for headers and query parameters, but not for multipart/form-data and application/x-www-form-urlencoded request bodies.

A feature request has been raised to add Bulk Edit support for form-data and URL-encoded request bodies, allowing multiple fields to be added or edited instead of having to create each field individually.

We've also included your feedback regarding requests with a large number of fields and the impact this has on your workflow.

Thank you.