Construtor de Comandos cURL

curl \
  -H "Content-Type: application/json" \
  "https://api.example.com/endpoint"

What does the cURL Builder do?

The cURL Builder is a free online tool that turns an HTTP request — method, URL, headers, body, and a few common flags — into a copy-pasteable curl command. You fill in a form (GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS, the URL, any headers, an optional JSON body, and toggles for -L, -k, -v, -s) and the tool builds a multi-line, backslash-continued command you can drop straight into a terminal.

For example, a default GET against https://api.example.com/endpoint with a Content-Type: application/json header produces:

curl \
  -H "Content-Type: application/json" \
  "https://api.example.com/endpoint"

It runs entirely in your browser, never sends your request anywhere, and doesn't require sign-up. The output updates as you type — change the method, add a header, toggle -v, and the command rewrites itself instantly.

When you'll use the cURL Builder

cURL is the lingua franca of HTTP debugging — every backend engineer, devops engineer, and API documentation reader speaks it. A web-based builder fits a few common moments:

Documenting an API call for a teammate or ticket. Pasting "POST /users with a JSON body" into a Slack thread is ambiguous. Pasting a complete curl command isn't — the recipient can run it as-is and reproduce the exact request. The Builder turns a half-remembered request shape into a precise reproduction recipe in seconds.

Sketching a request before writing code. Before wiring a call into your application, it's faster to verify the endpoint with curl from a terminal. Build the command in the form, run it, see the response, then translate to fetch/axios/requests once you're sure the request shape is right.

Converting from Postman, Insomnia, or browser DevTools. Most API clients can already export to curl, but the exports often include client-specific cookies, redundant headers, or escape sequences that don't paste cleanly. Rebuilding from scratch in the form gives you the minimal command — just what's actually needed.

Sharing a reproduction in a bug report. "Here's the curl that reproduces the 500" is the gold standard for backend bug reports. The Builder lets you produce it without writing one by hand, which means you'll actually do it instead of describing the problem in prose.

Teaching or learning HTTP. Building a request piece by piece in a form, then watching the corresponding curl command appear, is a fast way to internalize how methods, headers, and bodies fit together. Useful for bootcamps, onboarding docs, and personal study.

The flags this tool generates

The Builder exposes four optional flags. Each maps to a real curl behaviour you should turn on only when you need it.

-L (follow redirects). By default, curl shows a 301 or 302 response and stops. With -L it follows the Location header to the final destination. Turn this on when you're calling a URL that's expected to redirect (e.g. a vanity short link, an HTTP-to-HTTPS upgrade, or a load-balanced endpoint) and you want the body of the final response, not the redirect itself.

-k (insecure / skip SSL verification). Disables certificate validation. Use this against local dev environments with self-signed certs, internal staging servers without a public CA-signed cert, or any case where you've consciously decided you're okay accepting an unverified connection. Never use it against production unless you're triaging a known cert issue — it will silently accept man-in-the-middle attacks.

-v (verbose). Prints the full request and response to stderr, including the TLS handshake, every header sent and received, and any redirects followed. Indispensable when a request is failing in a way you don't understand. Pair it with -s rarely — they're not opposites, but combining them produces an awkward output.

-s (silent). Suppresses progress meters and error messages, leaving only the response body on stdout. Use this when you're piping the output to jq, grep, or another tool and don't want curl's status chatter mixed in. The classic pipeline: curl -s https://api.example.com/data | jq '.users[0]'.

Examples by request shape

Here's how common HTTP requests render through the Builder. The exact output is what you'll see in the dark output box on the page.

The full output also adds \\-newlines between sections, so a real POST looks like this when copied:

curl \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer abc123" \
  -d '{"name":"Alice","email":"[email protected]"}' \
  "https://api.example.com/users"

The line continuations are bash- and zsh-friendly. PowerShell and Windows cmd handle the syntax differently — strip the \\s and join everything onto one line if you're on Windows.

Tips and tricks

Query parameters go in the URL. The Builder doesn't have a separate "params" section. If you want ?status=active&limit=10, append it to the URL field directly. cURL will pass it through as-is.

Test against httpbin.org before hitting your real API. If you're not sure whether the request you're building is shaped correctly, swap the URL for https://httpbin.org/post (or /get, /put, etc.). httpbin echoes back exactly what it received, so you can verify the headers and body arrived intact before pointing at production.

For binary file uploads, switch to -T or --data-binary. The Builder generates -d for the body, which strips newlines on some curl versions and isn't suited for raw file content. If you need to upload a binary file, copy the generated command and replace -d '...' with --data-binary @yourfile.bin.

Use -i to see response headers. The Builder doesn't expose -i (include response headers in the output) because it's a read-only flag, but it's worth knowing. Add it manually to the copied command when you need to inspect status codes, content-types, or rate-limit headers without going full -v.

Related dev tools

cURL Builder pairs naturally with several other Microapp dev tools:

• If your request body is JSON and you want it pretty-printed before pasting it in, run it through the JSON Formatter first. The Builder accepts any string as the body — the formatter ensures it's valid JSON before you commit.
• For Basic Auth headers, you need a Base64-encoded username:password string. The Base64 Encoder/Decoder handles that in one paste — drop the encoded value into an Authorization: Basic ... header in the Builder.
• If your URL contains spaces, special characters, or non-ASCII text, encode it through the URL Encoder/Decoder before pasting. cURL is generally tolerant of unencoded URLs, but some servers reject them.
• To validate that a regex pattern in your query string matches the values you expect, the Regex Tester runs the same regex flavors most APIs use.

Frequently asked questions

Does the cURL Builder send the request, or just generate the command?

It only generates the command. Nothing is ever sent from the Builder — the form lives entirely in your browser and produces a string. You copy that string and run it in your own terminal. This means the Builder works for any URL, including localhost and internal-only endpoints that aren't reachable from the public internet.

Will the generated command work on Windows?

The output is written for bash and zsh — the line continuations use \\ and the body is wrapped in single quotes. PowerShell uses backticks for line continuation and treats single quotes differently, and Windows cmd doesn't support multi-line commands at all without escape gymnastics. The simplest fix on Windows: strip the \\-newlines and put the whole command on one line. Alternatively, run it from WSL or Git Bash, which both speak bash syntax.

How do I add Basic Authentication?

Add a header with key Authorization and value Basic <base64-encoded-credentials>. The credentials are username:password Base64-encoded — use the Base64 Encoder/Decoder to produce that string. cURL also has a built-in -u username:password flag that does the same thing more concisely; the Builder doesn't expose it (it's not in the four supported flags), but you can append -u user:pass to the copied output.

Can I use the Builder for GraphQL requests?

Yes. GraphQL over HTTP is just a POST to a single endpoint with a JSON body containing a query field. Set Method to POST, URL to the GraphQL endpoint, header Content-Type: application/json, body to {"query":"{ users { id name } }"}. The Builder doesn't know about GraphQL specifically — it just generates a generic JSON POST, which is exactly what GraphQL needs.

Why is the body wrapped in single quotes instead of double quotes?

Single quotes prevent the shell from interpreting $variable, backticks, and most special characters inside the body. If you used double quotes, a body containing $id would get expanded to whatever the shell variable $id happens to be (usually empty), corrupting the request. Single quotes are the safer default for JSON bodies. The trade-off: a body containing a single quote needs escaping, and the Builder doesn't auto-escape — you'll need to handle that case manually.

What's the difference between -L and a redirect on the server?

A redirect on the server is the response (HTTP 301, 302, 303, 307, 308) — it's there whether you ask for it or not. -L tells curl what to do with the redirect: follow it to the new URL, and show you the response from there. Without -L, curl prints the redirect status and stops. With -L, curl chases the redirect chain (up to 50 hops by default) and gives you the final response body.

Does the Builder handle file uploads (multipart/form-data)?

Not directly. The Body field generates a -d '...' argument, which is the right shape for JSON, form-urlencoded, and plain-text bodies. For multipart uploads, you need -F "field=value" or -F "file=@path/to/file", which curl treats specially (it sets the right Content-Type and boundary automatically). For now, copy the generated command and replace the -d portion with one or more -F flags by hand.