curl to Fetch and Axios Converter

This is a one-way conversion tool that generates JavaScript code for the browser Fetch API and Axios from an input curl command. The interface provides a curl command input field and an output area that toggles between Fetch API and Axios tabs.

You can click the sample button to load a standard example containing a POST method, Content-Type, Authorization header, and JSON string body.

This tool only performs one-way conversion from curl commands to JavaScript Fetch or Axios code, with no reverse conversion supported.

When you provide input, the converter extracts the URL, HTTP method, headers, and request body from supported arguments to generate two editable starter templates synchronously.

What is created here is strictly code strings; this tool does not execute the input curl command, run the generated JavaScript code, initiate HTTP requests to the target URL, or conduct API connectivity checks.

The output is not a finished, production-ready network process, but a starter boilerplate intended for developers to inspect and adjust according to their browser, Node.js runtime, or target API specifications.

Specific processing limits are strictly enforced for bounded client-side operation: the maximum input size is 200,000 UTF-16 code units, parsed tokens are capped at 10,000, and headers are limited to 100 (including any implicit Content-Type header).

Generated Fetch and Axios outputs are each limited to 500,000 code units. If any limit is exceeded, the tool does not truncate or partially convert; it halts immediately, displays an error message, and clears the output.

These boundaries are product guardrails designed for synchronous page rendering rather than universal protocol limits. The tool provides no performance, security, or error-free execution guarantees across arbitrary runtime environments.

While curl commands are typically executed within a shell, environments such as Bash, zsh, PowerShell, and cmd have differing rules for quoting, escaping, and expansions.

This tool is not a full POSIX shell or command interpreter; it uses a custom, deterministic tokenizer. Whitespace sequences separate arguments, but spaces and newlines enclosed in single or double quotes are preserved verbatim.

Adjacent quoted chunks and empty quoted tokens (such as "" or '') are recognized as distinct argument values, allowing explicit empty data arguments.

Inside single quotes, all characters—including backslashes—are preserved as literal text. Inside double quotes, a backslash is removed only when preceding $, backtick, ", \, or a newline (\LF and \CRLF line continuations are cleanly stripped); before any other character, backslashes are retained.

Outside quotes, a plain backslash escapes the immediately following character. The parser strictly rejects shell expansions, including environment variables ($VAR), command substitution (... or $(...)), ANSI-C quoting ($'...'), unquoted shell operators (&&, |, ;, redirects), pathname globs (*, ?), brace expansion ({}), tilde expansion (~), comments (#), and multiple commands.

Quoted or escaped literal symbols are accepted, but curl's own URL globbing syntax ({} or []) is rejected, except within valid IPv6 host authorities.

Inputs containing NUL characters are rejected.

A leading curl keyword is strictly required as the first argument. Supported arguments are limited to separated options: -X or --request, -H or --header, -d, --data, --data-raw, --data-binary, and -u or --user.

Combined options like -XPOST or --data=value, unknown options like -L or -i, and options with missing values are strictly rejected with explicit errors.

The tool never guesses missing parameters, never treats an unknown option value as a target URL, and never injects a fallback placeholder URL when none is specified.

The tool accepts exactly one absolute http or https URL. Commands lacking a URL, containing multiple URLs, extra positional arguments, non-HTTP schemes (such as ftp://), embedded user credentials (http://user:pass@example.com), raw spaces, control characters, unescaped backslashes, or URL globs are rejected immediately.

The URL is safely stringified into the JavaScript template, but path or query string semantics are not decomposed or automatically restructured.

The HTTP method extracted from -X or --request is validated against ASCII HTTP token syntax. The six standard Fetch methods normalized to uppercase are DELETE, GET, HEAD, OPTIONS, POST, and PUT.

Uppercase custom methods and uppercase PATCH work across both Fetch and Axios; only non-uppercase custom methods (such as lowercase patch) retain casing in Fetch while failing in Axios.

Browser-forbidden methods (CONNECT, TRACE, TRACK) are rejected, though full security is not guaranteed. If no method is specified and a body is present, POST is implicitly assigned.

Specifying a body with GET or HEAD is rejected with an explanatory error because the browser Fetch API prohibits request bodies on GET and HEAD requests.

Headers are split at the first colon, requiring the raw header name to be a valid ASCII HTTP token without trimming (spaces before the colon are invalid).

Raw header values are inspected prior to HTAB or space trimming: any values containing CRLF, NUL, illegal control characters, or characters outside the Latin-1/ByteString range (code units > 255) are rejected, though horizontal tabs (HTAB) are permitted.

Duplicate header names (evaluated case-insensitively) are rejected rather than silently overwritten or combined. In curl, a header with an empty value after the colon (-H "Header:") indicates header deletion rather than sending an empty value, and is rejected here; semicolon syntax (-H "Header;") is unsupported.

To avoid record __proto__ omission across runtimes, Fetch headers are emitted as an array of [name, value] pairs, whereas Axios headers remain an object with computed JSON string keys.

Neither full security nor actual transmission by browsers or libraries is universally guaranteed. The total header count cannot exceed 100, including any implicit Content-Type.

Only one body argument is permitted; passing multiple body options causes an error rather than ampersand concatenation. The raw body string is preserved verbatim without JSON parsing or form encoding, ensuring that large numbers, duplicate keys, and original formatting remain intact.

File references and standard input using @file or @- are rejected in -d, --data, and --data-binary, but --data-raw allows a leading @ as literal text.

When body data is provided without an explicit Content-Type header, application/x-www-form-urlencoded is implicitly added; explicit headers take precedence without automated JSON detection.

The -u or --user flag requires a username:password format separated by the first colon (colons within the password are permitted), and accepts ASCII printable characters only.

Non-ASCII characters, missing colons, or duplicate Authorization headers trigger errors rather than silent overwriting.

When embedding the URL, method, header keys, header values, and body into generated code, the tool serializes them using JSON.stringify logic.

All string literals, backslashes, quotes, and newlines are safely escaped, preventing arbitrary user input from breaking out of JavaScript code delimiters.

Rather than treating all headers as objects, Fetch outputs an array of [name, value] pairs to prevent runtime __proto__ omission, while Axios emits headers as an object with quoted computed properties ([JSON.stringify(key)]: value) so that identifiers containing hyphens, dots, underscores, or keywords avoid syntax errors.

The request body is never processed with JSON.parse or form-encoded during conversion, even if the content appears to be JSON. This preservation guarantees that large integers beyond Number.MAX_SAFE_INTEGER, duplicate object keys, scientific notation, and exact whitespace indentation are preserved unchanged.

Developers should separately validate payload structure using syntax linters or formatters if required.

The Fetch output creates a url constant and an options object containing method, headers, and body. In the response boilerplate, statuses 204, 205, and HEAD requests are treated as having no body (null).

For other responses, the body is read as text first, and JSON.parse is attempted only if the content is non-empty and the Content-Type header contains json, falling back to raw text on parse failure.

If response.ok is false, an error containing the status code is thrown. This provides a robust starting point, though streams, binary downloads, or custom status codes require manual user implementation.

The Axios output constructs an options object (method, url, headers, data) passed to axios(config) and logs response.data. An identity transformRequest: [(data) => data] is included when a body is present to prevent Axios from automatically trimming or serializing raw strings.

If a non-uppercase custom method is specified, it remains valid in Fetch, but the Axios output displays an unsupported method error and produces empty output (without guessing Axios adapter capabilities), while the Fetch output remains intact.

Both Fetch and Axios templates are generated together synchronously. When copying generated code, delayed completion results are guarded so late completions cannot overwrite newer state.

The copy success indicator automatically expires after approximately 2 seconds, and resets earlier whenever the input is modified, tabs are switched, or content is cleared, even if the resulting output string remains identical.

If clipboard access is denied or encounters an error, instructions are displayed prompting the user to manually select and copy the text.

The generated code templates transcribe supported curl arguments into JavaScript configuration objects, but they cannot guarantee functional equivalence across runtime environments.

The most prominent discrepancy is CORS (Cross-Origin Resource Sharing). While command-line curl executes outside browser security boundaries, Fetch and Axios running in a browser are bound by the same-origin policy.

Cross-origin requests depend on preflight checks and server-side Access-Control-Allow-Origin headers; a request that succeeds seamlessly via curl may fail completely in client-side JavaScript without explicit server authorization.

Browser security models strictly regulate cookies and request headers based on origin rules and credentials settings. Forbidden request headers—specifically Host, Content-Length, Cookie, and Connection—cannot be set or modified from the request headers object in client-side JavaScript.

While some headers such as Referer can be controlled through dedicated request options like referrer or referrerPolicy, setting forbidden headers directly on the headers object is prohibited.

Although this tool faithfully outputs valid header strings into your code template, the browser networking layer may silently ignore or override them during transmission.

Furthermore, behaviors governing cookie persistence, automatic redirect following, compression negotiation, custom TLS certificates, client certificates, HTTP proxies, and HTTP protocol versions (HTTP/1.1 vs HTTP/2 or HTTP/3) differ fundamentally between curl and browser APIs.

When executing Axios, the underlying transport layer differs between browser environments (XMLHttpRequest or Fetch adapter) and Node.js (http/https native modules), leading to divergent CORS enforcement, header allowances, and timeout behaviors.

The generated templates do not detect or configure your target runtime environment; they provide a common boilerplate. Developers must manually verify target API requirements, authentication schemes, CORS headers, redirect rules, timeouts, and payload expectations.

The external axios package must be installed in destination projects, and developers must independently audit and test all network code before deployment.

Whenever the input curl string changes, tokenization, syntax validation, request modeling, and code generation for both Fetch API and Axios execute in a single synchronous pass on the client.

Switching between the Fetch and Axios tabs simply displays the already generated output. The tool does not use Web Workers, streaming parsers, debounce timers, or server-side conversion APIs.

When an error is encountered—such as unsupported options, syntax violations, or exceeding character limits—both output panes are cleared and an associated error message is rendered immediately, preventing the accidental copying of outdated or mismatched code snippets.

The interface displays current input character counts alongside defined limits and utilizes accessible ARIA live regions to announce errors and clipboard operations to assistive technologies.

Output tabs provide distinct accessible labels, rendering parse failures via assertive live announcements and copy confirmations via polite announcements.

The "Copied" status automatically expires after approximately 2 seconds, and delayed completion results are guarded to prevent stale updates.

If the input command is modified, tabs are switched, or content is cleared, the success indicator resets immediately even if the resulting output string remains identical.

Because rendering and screen-reader behaviors vary across operating systems and browsers, developers should directly review the generated code in the output pane.

Any API tokens, passwords, session cookies, or personally identifiable information embedded in the input curl command will appear as literal strings in the generated templates.

While the string transformation runs entirely within local browser memory without transmitting data over the network, this does not guarantee confidentiality against browser extensions, clipboard monitoring utilities, screen recordings, or physical shoulder surfing.

Users should always replace confidential credentials with dummy placeholders prior to conversion, and subsequently inject real secrets using environment variables or dedicated secret management systems in their final codebase.

Before integrating generated code into production, developers should conduct visual reviews and rigorous syntax checks within their development environment.

In particular, verify CORS compatibility and forbidden header restrictions for browser Fetch, verify dependency installation and execution environment for Axios, and confirm authentication and response parsing formats across both.

The tool strictly limits its role to transcribing valid curl arguments into safe JavaScript strings, eliminating repetitive boilerplate setup; final verification and architectural decisions remain the sole responsibility of the developer.