Getting Started with cURL: The Terminal’s Browser
Leave the graphical interface behind. Learn how to talk directly to servers and APIs from your command line.

Search for a command to run...
Leave the graphical interface behind. Learn how to talk directly to servers and APIs from your command line.

No comments yet. Be the first to comment.
These are the assignments or knowledge dumps I decide to write for the "Chai aur Code's web Dev Cohort 2026"
You cannot style what you cannot target. Learn how to address your HTML elements with precision using CSS selectors.
RAG helps LLMs answer questions using your own data, but it doesn't guarantee correct answers. Here's how the pipeline works and where it commonly breaks down.

Imagine asking an AI, "Write a blog," versus "Act as an SEO expert and write a 1,000-word blog on AI safety formatted in markdown." The difference in the resulting output is night and day. A prompt is

Spotify and Apple Music make it incredibly easy to showcase your live listening habits on your website. YouTube Music? Not so much. After doing some setup you can do an API call and fetch your account

Arthur C. Clarke's famous third law: "Any sufficiently advanced technology is indistinguishable from magic" perfectly captures how the pace of human innovation works. From carrying supercomputers in o

Why HTTP is amnesiac, the difference between transport and state, and how to choose the right auth strategy for your Node.js app.
Before you write a single line of backend code or fetch data for a frontend component, you need to understand what a server actually is.
In the simplest terms, a server is just a computer sitting somewhere in a cold room, waiting for a message. When it receives a message, it reads it, decides what to do, and sends a message back.
Usually, your web browser handles this conversation for you. You type a URL, and Chrome or Firefox sends the message, gets the response, and paints a beautiful webpage full of colors, images, and fonts.
Learn how this happens in this blog -
But as a developer, you often don't care about the paint. You don't want the browser to render a UI. You just want to see the raw data the server is sending back, or you want to test an API you just built. You need a way to talk to the server directly, stripping away all the graphical translation.
You need cURL.
cURL (Client URL) is a command-line tool that allows you to send and receive data across a network.
Instead of typing a web address into an address bar and hitting Enter, you type a command into your terminal. cURL takes your request, hands it to the server, and dumps the raw response directly onto your screen.
Why do programmers rely on it so heavily? Because it is universal. It is installed by default on almost every modern operating system. When you read the documentation for a new API—whether it’s Stripe, GitHub, or OpenAI—they won't show you how to use it in JavaScript or Python first. They will show you a cURL command. It is the universal language of HTTP.
Let’s see it in action. Open your terminal and type this exact command:
curl https://example.com
When you hit Enter, you won't see a formatted webpage. You will see this:
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
...
This is the raw HTML of example.com.
This single command proves a fundamental truth about web development: the web is just text. Your browser hides this text from you by rendering it into a visual layout. cURL rips the mask off and shows you exactly what the server actually sent.
When you talk to a server, the response it sends back is split into two parts:
The Headers (Metadata): Information about the response (like whether it was successful, the date, and what type of data is attached).
The Body (Data): The actual content you asked for (like the HTML or JSON).
By default, cURL only shows you the Body. But as a developer, you often care more about the Headers, specifically the Status Code, which tells you if your request succeeded (like 200 OK) or failed (like 404 Not Found).
To tell cURL to include the headers in its output, use the -i (include) flag:
curl -i https://example.com
Now, before the HTML, you will see the server's hidden metadata:
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Sun, 10 May 2026 06:17:00 GMT
...
Fetching HTML is cool, but cURL’s real superpower is interacting with APIs. APIs don't return HTML for humans to read; they return structured data (usually JSON) for machines to process.
If you want to read data from a server, you use a GET request. By default, cURL always makes a GET request, so you don't need any special flags. Let's ask a public API for a mock to-do item:
curl https://jsonplaceholder.typicode.com/todos/1
The server instantly replies with raw JSON:
{
"userId": 1,
"id": 1,
"title": "delectus aut autem",
"completed": false
}
What if you don't just want to read data? What if you want to create a new user, or send a form submission? For that, you need to send a POST request.
A POST request requires a bit more information. You have to tell the server:
What HTTP method you are using (POST).
What format your data is in (usually JSON).
The actual data itself.
Here is how you build that in cURL. It looks intimidating at first, but let's break it down:
curl -X POST https://jsonplaceholder.typicode.com/posts \
-H "Content-Type: application/json" \
-d '{"title": "My First Post", "body": "cURL is awesome"}'
-X POST: The -X flag specifies the exact HTTP method you want to use.
-H: The -H flag adds a Header. Here, we are warning the server: "Hey, the data I am about to send you is formatted as JSON."
-d: The -d flag stands for data. This is the actual payload you are sending to the server.
If you run this, the API will reply with a 201 Created status and echo your data back to you. You just wrote data to a server without touching a frontend interface.
Image by MDN Web Docs
When you first start using cURL, you will inevitably run into walls. Here are the three most common traps beginners fall into:
Forgetting to quote your URLs: If a URL has an ampersand (&) in it (e.g., https://api.com?search=cat&limit=10), you must wrap the URL in quotes. If you don't, your terminal thinks the & means "run this process in the background," and your command will mysteriously fail or freeze.
Wrong: curl https://api.com?search=cat&limit=10
Right: curl "https://api.com?search=cat&limit=10"
Sending JSON but forgetting the Content-Type header: If you use the -d flag to send JSON data but forget to include -H "Content-Type: application/json", the server will assume you are sending a standard HTML form submission. It won't know how to read your JSON, and it will throw a 400 Bad Request error.
Confusing single and double quotes: When sending JSON data with -d, wrap the entire payload in single quotes ('...'), and use double quotes ("...") for the keys and values inside the JSON. If you mix them up, the JSON becomes invalid.
Graphical tools like Postman or Insomnia are fantastic, and you will absolutely use them in your career. But relying purely on a GUI hides the mechanics of HTTP.
When you learn cURL, you aren't just learning a terminal command. You are learning how the internet actually communicates. You learn how to manually assemble the headers, the verbs, and the body of a request. Once you can do it in the terminal, writing fetch() requests in JavaScript or handling routes in Node.js becomes infinitely easier—because you finally understand exactly what the code is doing under the hood.