fetch() and curl express the same request in different shapes, and the mapping is mostly mechanical.
The method becomes the method option; GET is the default and can be omitted. Each -H header becomes an entry in the headers object. The body becomes body: a -d string goes straight in, but because curl's -d implies application/x-www-form-urlencoded, fetch needs that Content-Type stated explicitly unless the command set another. A -F multipart upload becomes a FormData object built up field by field; the browser sets the multipart boundary, so you do not set Content-Type yourself.
Two differences catch people out. First, fetch does not carry cookies by default the way a shell session might; sending them needs credentials: "include". Second, fetch cannot disable TLS certificate verification, so a -k command has no faithful browser equivalent.
Everything else is a direct translation from the parsed request, which is why a tool that has already parsed the curl command can generate the fetch call for you.
Where the translation stops being mechanical
Flag-for-option mapping covers most of a command. What does not carry across is everything the browser adds on its own: cookies from the jar, an Origin header, and a preflight request the original curl call never had to make.
A translated request that fails in the browser but worked in the terminal has usually not been mistranslated. It has been moved into an environment with rules the terminal does not enforce.