Why curl -d Alone (No -X) Still Sends a POST
You've probably seen a command like curl -d '{"key":"value"}' https://example.com in API docs or in a browser dev tool's "Copy as cURL." There's no visible -X POST, yet this request actually goes out as POST, not GET. Most people only know "no -X means the default is GET," so this behavior is confusing the first time you see it. This guide explains why -d alone changes the method, and what goes wrong when a parsing tool fails to reproduce this exact rule.
1. curl's Default Method Rule: Conditional GET
curl's official manual reveals that the method behavior isn't as simple as it first appears. Skip the -X/--request option entirely and curl "defaults" to GET — but that default has an exception. If any data-sending option like -d, --data, --data-raw, --data-binary, or --data-urlencode is present, curl automatically switches the method to POST. So the accurate rule isn't "no -X means GET, no matter what" — it's "no -X and no data means GET; data present means POST." This isn't some arbitrary convenience feature curl bolted on — because the HTTP spec generally says a GET request shouldn't carry a body, the mere presence of a body is treated as a strong signal that "this isn't a GET."
2. Why This Keeps Causing Confusion: Docs and Tools Don't Agree
This rule gets misunderstood often because the three sources you actually run into in practice each have their own habits.
- Official API documentation: For clarity, docs often make a habit of always spelling out -X POST explicitly. This easily creates the impression that "cURL examples always have -X."
- Browser DevTools' "Copy as cURL": Even when the actual request method was POST, Chrome/Firefox sometimes omit -X and only include -d, leaving it up to curl's own rule regardless of what method was actually sent.
- Hand-written scripts: A developer thinks "obviously it's POST since I'm using -d" and omits -X on purpose. This usually works as intended, but in code review it's hard to tell whether -X was left out knowingly or because the author didn't know the rule.
All three cases end up producing the same POST request, but because the command looks different on the surface each time, the same question — "is this valid syntax?" — keeps coming back up.
3. What Goes Wrong When a Parsing Tool Misses This Rule
This rule matters especially for tools that analyze a cURL command and break it down into URL, method, headers, and body. If a tool naively implements "whatever comes after -X is the method, otherwise GET," it will show the wrong result for the following very common input.
curl -d '{"name":"Alice"}' https://api.example.com/usersWhat curl actually does: sends an automatic POST request because -d is present
A parser that ignores the rule: shows GET as the default because -X is absent → gives a result that doesn't match reality, leaving the user confused when comparing it against the API server's logs
| Input form | Method curl actually sends | Wrong answer from a rule-less parser |
|---|---|---|
| No -X, no -d | GET | GET (matches) |
| No -X, -d present | POST | GET (mismatch) |
| -X GET, -d present | GET (kept as explicitly specified) | GET (matches) |
| -X PUT, -d present | PUT | PUT (matches) |
So the problem only occurs in exactly one combination — no -X, -d present — but the trap is that this happens to be the most common pattern in real-world usage. The cURL Parser is built to correct the default GET to POST specifically when -X is absent and a body is present, so it matches real curl's behavior even for this very common pattern.
4. How to Verify This Yourself
If you'd rather see the rule with your own eyes before trusting a tool, run it in verbose mode in a terminal, e.g. curl -v -d 'test=1' https://example.com 2>&1 | grep "> POST". The -v flag prints the actual outgoing HTTP request line (> POST / HTTP/1.1), letting you verify the curl binary's own behavior directly, without going through any documentation or third-party tool. If you just want to check a command's breakdown online, paste it into the cURL Parser and see how the Method field is displayed.
5. Related Mistakes People Often Make Alongside This
Beyond the -d/method rule, there are a few other common points of confusion when working with cURL commands. One is breaking a command by mishandling quoting when attaching multiple headers with -H; another is needing to go the other way — building a fresh cURL command from an already-completed request. For the latter case, the cURL Generator lets you fill in form fields to build a command in reverse, and if you want to inspect the structure of an API response nicely, the API Tester or JSON Viewer are handy companions.
Frequently Asked Questions
Q. What happens if I use -X GET together with -d?
When you explicitly specify the method with -X, that value is kept as-is. The automatic POST correction only applies when -X is entirely absent, so -X GET -d '...' is an unusual but valid combination that sends a GET request carrying a body (how the server chooses to handle that is a separate question).
Q. Does the same rule apply to --data-raw or --data-binary?
Yes. Not just -d/--data — --data-raw, --data-binary, and --data-urlencode, all options that put data in the body, equally trigger the switch to POST whenever -X is absent.
Q. Does -F (multipart form upload) follow the same rule?
Yes — -F/--form also sends a body, so using it without -X triggers the same automatic POST. Uploading a file over GET wouldn't make sense in the first place.
Q. Does this rule differ across curl versions?
This has been curl's default behavior for a long time and is consistently maintained across the versions in wide use today. That said, if you want to confirm the exact behavior, checking the latest docs via curl --manual or the official manual page is always the safest bet.