Not every curl flag survives the trip to fetch

A curl command copied out of browser DevTools looks simple enough: curl -X POST https://api.example.com/users -H "Authorization: Bearer abc123" -H "Content-Type: application/json" -d '{"name":"Ada"}'. Converting the shape of it is easy. The hard part is that several flags and headers which work perfectly in curl either do nothing or are actively rejected once the same request runs inside a browser — and they fail quietly rather than loudly.

Which flags are actually recognised

The converter understands -X / --request for the method, -H / --header for headers, -d / --data / --data-raw / --data-binary / --data-urlencode for the body, -u / --user for basic auth, and --url for an explicit URL.

It also accepts -L / --location, --compressed, -s / --silent and -k / --insecure without producing anything, because each is either automatic in fetch or has no browser equivalent at all.

Every other flag is silently dropped. There is no error and no warning — --proxy, -A, --cookie and the rest simply vanish. This is the single most important thing to know about the tool, because a long DevTools command can lose parts of itself and still produce output that looks complete. Read the generated code against your original rather than assuming everything came across.

Cookies and forbidden headers fail silently in the browser

A curl command copied from DevTools usually carries a Cookie header, and often User-Agent, Host or Accept-Encoding too. The converter passes them through as ordinary headers because that is what they look like, but the browser will refuse to send them: these are forbidden header names that only the browser itself may set. Your fetch call runs, the header is dropped, and nothing tells you.

Cookies need a different mechanism entirely. Rather than a copied Cookie line, fetch uses the credentials option, and the values are easy to get backwards:

• same-origin — the default. Cookies are sent automatically to your own origin, so a same-origin request needs no configuration at all.
• include — required for cross-origin requests. The server must also return Access-Control-Allow-Credentials: true and name your exact origin, since a wildcard is not permitted with credentials.
• omit — never send them.

Basic auth is a header, not a credentials setting

Worth separating clearly, because the two get conflated: -u user:pass has nothing to do with the credentials option. Basic auth is encoded into an ordinary Authorization header, which the converter emits directly, and it works the same way in fetch as in curl. The credentials option governs cookies only.

JSON bodies are detected and pretty-printed

When the headers declare Content-Type: application/json and the body parses as JSON, the converter reformats it with indentation so the result is readable rather than one long escaped line. If the body is not valid JSON, it falls back to escaping it as a plain string. Data from --data-urlencode is joined with & and stays a string.

What to do after converting

The practical workflow is short. Delete the headers the browser controls — Cookie, User-Agent, Host, Accept-Encoding, Connection — since they will be ignored anyway and only obscure what your request actually sends. Then set credentials deliberately based on whether the call is same-origin or cross-origin. Finally, drop -L and --compressed from your thinking entirely: fetch follows redirects by default and decompresses response bodies automatically. See JSON to TypeScript for typing the response once the request works.