JSON to FormData Converter
JSON and form submissions use different data models. Choose how nested objects, arrays, nulls, and scalar values should become form fields.
Paste a request model, frontend state object or API example. The top-level value must be an object so property names can become form field names.
Value handling
Flattened fields, FormData code, form-encoded output or multipart preview will appear here.
JSON and Form Data Do Not Describe the Same Shapes
JSON has objects, arrays, numbers, booleans, strings, and null. Browser FormData is an ordered list of names whose values are strings or Blob/File objects. There is no built-in FormData type for a nested object and no universal rule that says how an array should be flattened.
That gap is where most integration bugs happen. Decide the field naming convention from the server contract first, then generate the request body to match it.
Pick a Field Naming Convention the Server Actually Parses
Names such as profile.role andprofile[role] are conventions used by frameworks and form parsers. HTTP does not assign nesting semantics to either one. A server can just as easily treat the brackets or dot as literal characters in the field name.
Literal JSON keys can also collide with a flattening convention. A source key named profile.role becomes ambiguous when a dot is also being used to mean “nested property.” Rename the field, choose a different contract, or confirm how the receiving parser resolves that ambiguity.
Arrays Can Lose Structure When They Are Flattened
Repeated: tags=api tags=forms Brackets: tags[]=api tags[]=forms Indexed: tags[0]=api tags[1]=forms JSON text: tags=["api","forms"]
All four patterns exist in production APIs. Repeated names match the underlying entry-list model well for simple scalar arrays. Brackets and numeric indexes put extra structure into the field name. JSON text keeps the whole array together but requires a second JSON parse on the server.
Arrays of objects need extra care. Repeating child names can lose the boundary between item 0 and item 1. Indexed names or a JSON field are usually easier to interpret when object grouping matters.
Let the Browser Add the Multipart Boundary
When Fetch sends a FormData body, the browser serializes the entries and generates the multipart boundary. SettingContent-Type: multipart/form-data by hand usually leaves out that generated boundary, so the server cannot split the parts correctly.
Leave the Content-Type header unset for browser FormData unless you are deliberately constructing the multipart body yourself. A manual multipart preview is useful for reading the framing, not for copying a fixed boundary into Fetch code.
URL-Encoded Forms and Multipart Forms Solve Different Problems
application/x-www-form-urlencoded is compact and works well for ordinary text fields, OAuth token requests, and older form endpoints. Spaces are represented as +, and other bytes are percent-encoded using the form encoding algorithm.
multipart/form-data is built from separate parts and can carry file content as well as text fields. A URL-encoded body cannot represent a browser File or Blob part in the same way.
A Filename String Is Not a File Upload
{ "avatar": "/tmp/photo.jpg" } contains a path string, not the bytes of the photo. Browser uploads need a File or Blob object. cURL file upload has its own file-reading syntax such as --form avatar=@photo.jpg.
Generated cURL fields use --form-string so an input value beginning with @ stays text instead of unexpectedly reading a local file. Add an actual file part separately when that is what the endpoint expects.
Missing, Empty, and null Can Mean Different Things
JSON has a real null value. Form fields do not have one universal typed null representation. An update endpoint may treat an omitted field as “leave unchanged,” an empty string as “clear it,” and the text null as five ordinary characters.
Pick the null rule from the endpoint semantics, not from how tidy the generated request looks. The same warning applies to empty strings; dropping them can change meaning when the server distinguishes an empty value from a missing field.
Large Numeric IDs Are Safer as JSON Strings
JSON number syntax allows integer literals beyond JavaScript's exact safe-integer range. JSON.parse() produces a JavaScript Number, so a large database ID can lose digits before any form encoding happens.
If every digit is an identifier rather than a quantity, send it as a JSON string at the source. Turning an already-rounded Number back into text cannot recover the missing digits.
Duplicate JSON Names Disappear During Normal Parsing
{
"tag": "first",
"tag": "second"
}JavaScript keeps one tag property after parsing, so the two source members cannot later become two form fields. Duplicate names are flagged before the main parse so that overwrite risk stays visible.
Specifications Behind the Encoding
Defines FormData as an ordered entry list and the append() behavior for string and Blob/File values.
Defines how a FormData request body is serialized and how the multipart/form-data boundary is generated.
Defines multipart boundaries, Content-Disposition form-data parts, field names, and file parts.