Skip to main content

Command Palette

Search for a command to run...

Getting Started with cURL: A Beginner's Guide to Talking to Servers

Learn how to use cURL to send HTTP requests, test APIs, and debug like a pro. A hands-on guide for developers new to command-line tools.

Updated
11 min read
Getting Started with cURL: A Beginner's Guide to Talking to Servers
V

BCA student and developer who loves learning in public. I build web and mobile projects, explore databases and backend systems, and document my journey through blogs. Currently focused on writing clean code and growing one commit at a time.

Getting Started with cURL: A Beginner's Guide to Talking to Servers

Have you ever wondered how your browser fetches a webpage? Or how apps on your phone get data from the internet? Behind the scenes, it's all about sending requests to servers and receiving responses.

What if you could do the same thing — but from your terminal? That's exactly what cURL lets you do.

Introduction

As a developer, you'll constantly need to communicate with servers — fetching data, sending information, testing APIs, and debugging issues. While browsers do this automatically, sometimes you need more control and visibility.

cURL (pronounced "curl") is a command-line tool that lets you send requests to servers directly from your terminal. It's one of the most essential tools in a developer's toolkit, and learning it will make you significantly more productive.

Don't worry if this sounds intimidating. We'll start from the very basics and build up your confidence step by step.

Prerequisites

  • Access to a terminal (Command Prompt, PowerShell, Terminal, or Git Bash)

  • cURL installed (it comes pre-installed on most systems)

  • Basic familiarity with using a terminal

To check if cURL is installed, run:

curl --version

If you see version information, you're ready to go!


What is a Server and Why Talk to It?

Before we dive into cURL, let's understand what we're actually talking to.

What is a Server?

A server is just a computer that's always on, connected to the internet, and waiting to respond to requests. When you visit a website, your browser sends a request to a server, and the server sends back the webpage.

Think of it like a restaurant:

  • You (the client): Place an order

  • Waiter (the internet): Carries your order to the kitchen

  • Kitchen (the server): Prepares and sends back your food

  • Food (the response): What you actually wanted

Why Do We Need to Talk to Servers?

Every time you:

  • Load a webpage

  • Check the weather in an app

  • Post on social media

  • Search for something online

...your device is sending requests to servers and receiving responses. As a developer, you need to understand and test these interactions.


What is cURL?

cURL stands for "Client URL." It's a command-line tool that lets you transfer data to and from servers using various protocols (mainly HTTP/HTTPS).

In Simple Terms

cURL is like a mini-browser that runs in your terminal. Instead of clicking links and seeing pretty webpages, you type commands and see the raw data that servers send back.

# Browser way: Click a link, see a webpage
# cURL way: Type a command, see the raw response

curl https://example.com

Where cURL Fits In

┌─────────────────────────────────────────────────────────────┐
│                    Ways to Talk to Servers                   │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   Browser          cURL              Your Code               │
│   ┌─────┐         ┌─────┐           ┌─────────┐             │
│   │ 🌐  │         │ >_  │           │ { code }│             │
│   └──┬──┘         └──┬──┘           └────┬────┘             │
│      │               │                   │                   │
│      └───────────────┼───────────────────┘                   │
│                      │                                       │
│                      ▼                                       │
│               ┌────────────┐                                 │
│               │   Server   │                                 │
│               └────────────┘                                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘

All three methods talk to the same servers — they're just different tools for different situations.


Why Programmers Need cURL

You might wonder: "If browsers already fetch webpages, why do I need cURL?"

Great question! Here's why developers love cURL:

1. Testing APIs Quickly

Before writing code to call an API, you can test it with cURL to make sure it works:

curl https://api.github.com/users/octocat

2. Debugging Issues

When something's not working, cURL helps you see exactly what's being sent and received:

curl -v https://example.com  # -v for verbose output

3. Automation and Scripts

You can use cURL in shell scripts to automate tasks:

# Download a file
curl -O https://example.com/file.zip

# Check if a website is up
curl -I https://mywebsite.com

4. No GUI Needed

On servers (which usually don't have browsers), cURL is essential for making HTTP requests.

5. See the Raw Truth

Browsers hide a lot of complexity. cURL shows you exactly what's happening — headers, status codes, raw data.

💡 Tip: Think of cURL as a developer's X-ray vision for HTTP requests. It shows you what browsers hide.


Making Your First Request

Let's get hands-on! Open your terminal and let's make your first request.

The Simplest Command: Fetching a Webpage

curl https://example.com

That's it! This command:

  1. Sends a request to https://example.com

  2. Receives the response

  3. Prints the HTML content to your terminal

What You'll See

<!doctype html>
<html>
    <head>
        <title>Example Domain</title>
        ...
    </head>
    <body>
        <h1>Example Domain</h1>
        <p>This domain is for use in illustrative examples...</p>
    </body>
</html>

This is the same HTML that your browser receives — but without all the pretty formatting!

Fetching JSON Data

Most APIs return data in JSON format. Let's try one:

curl https://api.github.com/zen

Output:

Keep it logically awesome.

This is GitHub's API returning a random programming wisdom quote!

Try Another One

curl https://httpbin.org/get

Output:

{
    "args": {},
    "headers": {
        "Accept": "*/*",
        "Host": "httpbin.org",
        "User-Agent": "curl/7.68.0"
    },
    "origin": "203.0.113.50",
    "url": "https://httpbin.org/get"
}

This is a test API that echoes back information about your request. Super useful for learning!


Understanding Request and Response

Every HTTP interaction has two parts: what you send (request) and what you receive (response).

The Request

When you run curl https://example.com, cURL sends something like this:

GET / HTTP/1.1
Host: example.com
User-Agent: curl/7.68.0
Accept: */*

This tells the server:

  • GET: I want to retrieve data (not send data)

  • /: The path I'm requesting (root page)

  • Host: Which website I'm talking to

  • User-Agent: What tool is making the request

  • Accept: What types of responses I can handle

The Response

The server sends back:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>
...
</html>

This includes:

  • Status Code (200 OK): The request succeeded

  • Headers: Metadata about the response

  • Body: The actual content (HTML, JSON, etc.)

Seeing the Full Picture

To see both request and response headers, use the -v (verbose) flag:

curl -v https://example.com

This shows you everything happening behind the scenes!

Common Status Codes

CodeMeaningWhat It Means
200OKSuccess! Everything worked
201CreatedSomething was successfully created
400Bad RequestYour request has an error
401UnauthorizedYou need to log in
404Not FoundThe page doesn't exist
500Server ErrorSomething broke on the server

Using cURL to Talk to APIs

APIs (Application Programming Interfaces) are how different software systems communicate. Let's learn how to interact with them using cURL.

GET Requests: Fetching Data

GET is the most common request type. It retrieves data without changing anything on the server.

# Get a user's GitHub profile
curl https://api.github.com/users/octocat
# Get weather data (example API)
curl "https://wttr.in/London?format=3"

Output:

London: ⛅️ +8°C

ℹ️ Note: When your URL contains special characters like ? or &, wrap it in quotes.

POST Requests: Sending Data

POST is used to send data to a server — like submitting a form or creating a new record.

curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name": "John", "email": "john@example.com"}'

Let's break this down:

  • -X POST: Use the POST method

  • -H "Content-Type: application/json": Tell the server we're sending JSON

  • -d '{"name": "John"}': The data we're sending

Understanding the Flags

FlagLong FormPurpose
-X--requestSpecify the HTTP method (GET, POST, PUT, DELETE)
-H--headerAdd a header to the request
-d--dataSend data in the request body
-v--verboseShow detailed request/response info
-o--outputSave response to a file
-O--remote-nameSave file with its original name
-I--headFetch headers only (no body)

A Practical Example

Let's use a free testing API to practice:

# Create a new post (fake API for testing)
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{
    "title": "My First Post",
    "body": "This is the content of my post",
    "userId": 1
  }'

Response:

{
    "title": "My First Post",
    "body": "This is the content of my post",
    "userId": 1,
    "id": 101
}

The server created a new post and returned it with an assigned id!


Browser Request vs cURL Request

You might wonder how cURL compares to what your browser does. Let's compare:

┌─────────────────────────────────────────────────────────────────┐
│                     Browser Request                              │
├─────────────────────────────────────────────────────────────────┤
│  1. You type URL and press Enter                                 │
│  2. Browser sends request (hidden from you)                      │
│  3. Browser receives HTML, CSS, JS, images                       │
│  4. Browser renders everything into a pretty page                │
│  5. You see the final result                                     │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                      cURL Request                                │
├─────────────────────────────────────────────────────────────────┤
│  1. You type the curl command                                    │
│  2. cURL sends request (you control every detail)                │
│  3. cURL receives the raw response                               │
│  4. Response is printed exactly as received                      │
│  5. You see the raw HTML/JSON/data                               │
└─────────────────────────────────────────────────────────────────┘

Key Differences

AspectBrowsercURL
InterfaceVisual (GUI)Text (command line)
OutputRendered pageRaw data
ControlLimitedFull control over headers, methods
AutomationHardEasy to script
DebuggingDev tools neededBuilt-in with -v

Common Mistakes Beginners Make

Learning from others' mistakes will save you time and frustration!

Mistake 1: Forgetting Quotes Around URLs

Wrong:

curl https://api.example.com/search?query=hello world

Right:

curl "https://api.example.com/search?query=hello world"

Or encode the space:

curl https://api.example.com/search?query=hello%20world

⚠️ Warning: Special characters like ?, &, and spaces need quotes or encoding!

Mistake 2: Wrong Content-Type for POST

Wrong:

curl -X POST https://api.example.com/users \
  -d '{"name": "John"}'

Right:

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "John"}'

Without the header, the server might not understand your JSON!

Mistake 3: Using HTTP Instead of HTTPS

Wrong:

curl http://api.github.com/users/octocat

Right:

curl https://api.github.com/users/octocat

Many APIs require HTTPS for security.

Mistake 4: Not Checking the Response

Always look at what the server returns:

# Add -i to see response headers (including status code)
curl -i https://api.example.com/endpoint

A 200 OK means success, but a 400 or 500 means something went wrong.

Mistake 5: Overcomplicating Early On

Start simple:

# Start with this
curl https://example.com

# Then add complexity gradually
curl -v https://example.com
curl -I https://example.com
curl -X POST -d "data" https://example.com

Don't try to learn all flags at once!


Quick Reference Cheat Sheet

# Basic GET request
curl https://example.com

# Show response headers
curl -I https://example.com

# Verbose output (debugging)
curl -v https://example.com

# POST with JSON data
curl -X POST https://api.example.com/endpoint \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

# Save response to file
curl -o output.html https://example.com

# Download file with original name
curl -O https://example.com/file.zip

# Follow redirects
curl -L https://example.com

# Add custom header
curl -H "Authorization: Bearer token123" https://api.example.com

Best Practices

  • Start simple — Master basic GET requests before adding flags

  • Use -v for debugging — It shows you exactly what's happening

  • Always check status codes — They tell you if the request succeeded

  • Quote your URLs — Avoid issues with special characters

  • Read the API documentation — Know what headers and data format the API expects

Where cURL Fits in Backend Development

┌────────────────────────────────────────────────────────────────┐
│                  Backend Development Workflow                   │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│   1. Read API docs                                              │
│          ↓                                                      │
│   2. Test with cURL  ←── You are here!                          │
│          ↓                                                      │
│   3. Understand request/response                                │
│          ↓                                                      │
│   4. Write code to call the API                                 │
│          ↓                                                      │
│   5. Debug with cURL when issues arise                          │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

cURL is your testing and debugging companion throughout your development journey!


Conclusion

You've learned the fundamentals of cURL! Here's what we covered:

  • Servers are computers that respond to requests over the internet

  • cURL is a command-line tool to send HTTP requests

  • GET requests fetch data, POST requests send data

  • Responses include status codes, headers, and body content

  • Practice with simple commands before adding complexity

cURL is incredibly powerful, and we've only scratched the surface. As you grow as a developer, you'll find yourself using it constantly for testing, debugging, and automation.

Next Steps / Further Reading

  • Practice with httpbin.org — A free testing API

  • Explore more HTTP methods: PUT, DELETE, PATCH

  • Learn about authentication headers (Bearer tokens, API keys)

  • Try the cURL documentation


If you found this helpful, consider following for more web development tutorials explained simply.