A curl command someone pasted from a bug report or an API doc page is a shell command, not JavaScript. Converting it means parsing the flags — -X/--request for the method, -H/--header for headers, -d/--data/--data-raw/--data-binary for the body, -u/--user for basic auth — and rebuilding the equivalent request options object:
curl -X POST https://api.example.com/orders \
-H "Content-Type: application/json" \
-d '{"item":"widget","qty":3}'
↓
fetch('https://api.example.com/orders', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: '{"item":"widget","qty":3}',
})-u/--user becomes a Basic auth header, not a fetch option
curl -u user:pass https://... has no direct fetch equivalent — the Fetch API doesn't have a credentials-shorthand option the way curl does. It gets translated into what curl itself actually sends on the wire: an Authorization: Basic <base64(user:pass)> header. One real edge case worth knowing: base64-encoding the credentials in the browser uses btoa, which only handles Latin1 text — a password with non-Latin1 characters in it won't encode cleanly this way, the same limitation curl's own -u flag has when the terminal encoding doesn't match.
Only one direction is supported, on purpose
This only goes curl → fetch/axios, not the other way. The reverse doesn't have one correct answer — the same fetch call can be written a dozen equivalent ways (destructured options, a helper wrapper, chained .then() vs await), so there's no single grammar to parse JavaScript back into. Converting a known, bounded curl flag syntax into code is well-defined; converting arbitrary JavaScript back into curl isn't.
What doesn't translate
--compressed, cookie jars (-b/-c), and multipart form uploads (-F) aren't covered — each of those maps to a meaningfully different amount of code infetch/axios (a FormData object, a cookie-handling layer) rather than a one-line option, so they're out of scope for a flag-to-option translator. If your command uses one of those, the URL/method/headers/body still convert — you'll just need to add that part by hand.
Importing a Postman collection works the same way
A Postman v2.x collection export (JSON) converts through the same code path — each request in the collection becomes the same method/URL/headers/body shape a parsed curl command produces, folders included (nested request groups get flattened). The one gap: only the collection's raw body mode is read. form-data, urlencoded, and binary bodies aren't representable as a single request body string without picking a specific encoding, so those requests come through with an empty body — check the original collection for those specifically.