cURL Command Generator

Introduction

A curl command is a plain-text description of an HTTP request. It spells out the method, target URL, headers, authentication, body, and transfer switches in the exact order a shell can run. The hard part is rarely the first word curl. It is the small details around quoting, duplicate headers, encoded form fields, retries, and shell differences that turn a request from "close enough" into something you can trust.

This generator builds that command for Bash or Zsh, PowerShell, and Windows CMD from the same request settings. It can start from presets, import many existing curl commands, and show the result as a runnable command, a field summary, and a structured JSON snapshot. That makes it useful for API examples, incident reproduction, internal documentation, support handoffs, and cross-platform request sharing.

It is most helpful when the request is real enough to deserve precision but not yet tested enough to trust from memory. A JSON API call with bearer auth, a form submission that needs URL encoding, and a Windows-friendly version of a Bash example all look similar at first glance. They stop looking similar as soon as the quoting rules, body encoding, or retry behavior change.

The safety boundary matters. This page generates text locally and does not send the request itself, but sensitive values can still appear in the rendered command, copied exports, screenshots, shell history, or the page URL because current form state is mirrored into query parameters. Use placeholders until the command is ready to run in a controlled environment.

Technical Details

The generator builds the request in a fixed order. It first checks that the base address is an absolute http or https URL, then appends any raw query string, parses manual headers, applies authentication, encodes the request body, assembles transfer flags, and finally quotes every part for the selected shell. That order matters because later choices can override earlier ones. A dedicated User-Agent or Referer value replaces a header with the same name, and a JSON body can add its own Content-Type header when one is missing.

Body handling is explicit rather than guessed. JSON mode parses and minifies the text before emitting --data-raw, which helps catch malformed JSON before you copy the command. Raw mode sends the text as-is with --data-raw. Form URL-encoded mode splits pairs on newlines or ampersands and emits repeated --data-urlencode arguments, which is the curl form most likely to preserve spaces and punctuation correctly for application/x-www-form-urlencoded requests. Multipart uploads are outside the page's output scope.

Authentication is also rule-driven. Basic auth becomes -u or --user. Bearer auth becomes an Authorization header. API-key mode injects a named header such as X-API-Key. The page also lets you choose short or long flag style, optionally combine one-letter short flags, and force an explicit method flag even when curl could infer the method from the body.

Transfer behavior comes from the advanced controls. You can follow redirects, ask for compressed responses, include response headers, stay quiet except for errors, show verbose output, add trace timestamps, disable keep-alive, keep the response body when 400+ responses should still count as failures, set retry counts and retry delay, choose HTTP/2 or HTTP/3, limit transfer rate, and quote an output file path for the chosen shell. Bash or Zsh uses single-quote escaping with optional backslash continuations. PowerShell uses single quotes with doubled apostrophes and backtick continuations. CMD always stays single-line and uses double quotes. When an output path starts with ~/, the rendered path expands to $HOME for Unix-like shells and %USERPROFILE% for CMD.

The importer is quote-aware and recovers many common curl patterns, including request method flags, headers, -u, --data-raw, --data-urlencode, retries, output files, and HTTP version flags. It is still an import helper, not a full shell parser. Commands with unsupported curl options, complex shell interpolation, or multipart form details can lose fidelity and should be reviewed after import.

The JSON tab records both raw inputs and derived values such as the final URL, flags list, retry summary, warnings, and errors. Basic passwords, bearer tokens, and API-key values are masked there as ***, but the generated command is not masked. That distinction is useful for documentation, but it is not a substitute for secret-handling discipline.

Assembly Map

Validation and Warning Rules

Everyday Use & Decision Guide

Start with the shape of the request, not with the final command line. If the request is a familiar pattern, the presets save time: JSON POST seeds a JSON body and content type, Form POST starts an application/x-www-form-urlencoded body, and the auth presets fill in the matching credential structure. If you already have a curl example, import it first and treat the result as an editable reconstruction.

Choose the shell early. The request meaning stays the same across shells, but quoting, path rendering, and line continuation do not. A Bash example that reads cleanly with backslashes can become awkward in PowerShell or CMD if you switch late. The shell selector is not a cosmetic choice. It changes the exact text you will paste.

Pick the body mode based on what the server expects on the wire. JSON mode is the right fit when the body should be valid JSON and usually paired with application/json. Raw mode is better for plain text, XML, or already prepared payloads. Form URL-encoded mode is for classic key-value pairs that curl should encode safely. If the server expects multipart file upload behavior, use this page as a sketching aid rather than a final generator.

• Use the dedicated User-Agent and Referer fields when those values matter. They keep the request readable and avoid duplicate-header confusion.
• Prefer long flags when the command will be read by other people and short flags when you want compact copy for personal use.
• Treat warnings as review prompts. They flag settings that are legal but easy to misread, such as GET with a body or retry delay without retries.
• Check the Fields tab before you copy the command. It is usually faster to spot a wrong URL, empty body, or missing retry policy there than inside the full command string.

For shared documentation, the page is often most useful in two passes. First build the request with placeholders and verify the structure. Then swap in real credentials locally, copy the final command, and avoid reusing the shareable page URL after that point.

Step-by-Step Guide

1. Choose a preset if the request already matches a common pattern, or paste an existing curl command into the importer when you want to rebuild and clean up a command you already have.
2. Select Bash or Zsh, PowerShell, or Windows CMD before you fine-tune the command. Decide whether you want multi-line formatting, keeping in mind that CMD always stays single-line here.
3. Enter the method, base URL, and optional raw query string. Add headers one at a time, then set auth, User-Agent, and Referer if the request needs them.
4. Choose the body mode only when the request truly has a body. Paste JSON, raw text, or form pairs and watch for parse or warning messages right away.
5. Open the advanced panel for redirect handling, response-header inclusion, failure behavior, retry policy, time limits, protocol choice, output file name, and flag style.
6. Review errors first and warnings second. Errors mean the page could not produce a safe command. Warnings mean the command is buildable but still deserves context-aware review.
7. Use Command when you need the runnable line, Fields when you need a quick audit or CSV or DOCX handoff, and JSON when you need a structured snapshot of both inputs and derived values.

Interpreting Results

The command preview is the final artifact, but the other result surfaces help answer a different question: does this command still match what you meant to send? The Fields tab turns the request back into readable checkpoints such as shell, method, final URL, header count, body size, flags, retry policy, and auth summary. That is the fastest way to catch a request that is syntactically valid but operationally wrong.

Errors and warnings do different jobs. Errors stop the page from claiming it has a usable command at all. Warnings leave the command available because the combination may still be intentional, but they mark places where the request can easily be misread. A GET body, an inactive retry delay, or a redirect limit without redirect following all fall into that second category.

• If the Headers count is lower than expected, look for duplicate names or an overridden User-Agent or Referer value.
• If Body bytes is zero, the request either has no body or the selected body mode did not produce one after parsing.
• If the Flags row does not include a switch you expected, trust that row over memory. It reflects the final emitted options, not just the controls you touched.
• If the Auth row is populated, assume the command itself carries sensitive material unless you deliberately used placeholders.
• If the JSON snapshot looks safe because some auth fields are masked, remember that the command and copied page URL still need separate care.

HTTP version output deserves especially careful reading. An emitted --http3 flag means curl will try HTTP/3, not that the runtime environment, network, and server will finish over QUIC. The generator shows intent. It does not validate the remote endpoint.

Worked Examples

JSON API POST with bearer auth and fail-with-body

Set the preset to JSON POST, keep the method on POST, and enter a URL such as https://api.example.com/v1/items. Add a bearer token, leave the JSON body mode active, and enable Fail with body plus a 20-second max time. The page will minify the JSON, add Content-Type: application/json if you did not already set it, and emit a request that still surfaces the response body when the server answers with an HTTP error.

The result is useful when you need both scripting behavior and debugging detail. The summary shows the final host, auth mode, active flags, and body size before you run anything.

URL-encoded form submission with readable retries

Choose Form POST, set the body to lines such as name=Ada and email=ada@example.com, then switch the flag style to long form. If you also set Retry attempts to 3, Retry delay to 2, and Silent except errors on, the page emits repeated --data-urlencode arguments plus a transport profile that is easier to read in shared documentation.

This is a good pattern when you want request examples that stay explicit about both payload handling and retry behavior.

Import a Unix command, then deliver it to a Windows user

Paste a Bash-oriented curl example into the importer, then switch the shell selector to PowerShell or CMD. The importer will recover many common headers, auth fields, retries, data flags, and the original URL. The page then re-renders the same request with the quoting rules and line style for the new shell.

That workflow is especially useful when a support article, README, or ticket thread only includes one platform's example and the receiving user needs another.

FAQ

Glossary

Header

A named request field such as Accept, Authorization, or User-Agent that changes how the server handles the request.

Basic auth

A username and password sent as one credential string through curl's -u or --user option.

URL-encoded form data

A key-value request body format that encodes reserved characters so pairs can be transmitted safely in application/x-www-form-urlencoded requests.

Referer

A request header that identifies the source URI for the request context, subject to browser and privacy rules.

Retry policy

The combination of retry count and retry delay that controls whether curl should attempt a failed transfer again.

Shell quoting

The escaping rules that keep spaces, punctuation, and special characters intact when a shell interprets the command line.

References

• curl man page, especially option semantics for --fail-with-body, --http3, --insecure, --referer, --show-error, and --trace-time, accessed April 11, 2026.
• everything curl: Retry, including default transient retry behavior, retry delay, and --retry-all-errors, accessed April 11, 2026.
• everything curl: HTTP/3, including QUIC, HTTPS-only use, and fallback behavior when HTTP/3 is denied, accessed April 11, 2026.
• everything curl: URL encode data, including how --data-urlencode handles form-style content, accessed April 11, 2026.
• RFC 9110: HTTP Semantics, especially GET request content behavior and Referer header privacy rules, accessed April 11, 2026.