Stop Guessing: A Developer's Guide to Debugging HTTP Headers with cURL

I've lost count of how many times I've spent hours debugging an API integration, only to realize the issue wasn't my code, but a silent 502 Bad Gateway or a misconfigured Content-Type header.

When a web application fails silently, the first thing you should do is look at the raw HTTP response. Browsers abstract this away from us, so as developers, we need to drop down to the network layer.

Here is my standard workflow for debugging APIs using cURL, and how to do it faster when you don't have terminal access.

1. The Basics: Fetching Headers Only When debugging, you usually don't care about the entire HTML body. You just want the headers. Using -I (or --head) tells cURL to only fetch the headers:

bash
curl -I https://api.example.com/v1/users
This will return the HTTP status code (200, 404, 500), the server type, cache control, and crucially, the Content-Type.

1. Following Redirects (301 vs 302) If you are migrating a site or testing an API endpoint, you need to know if the server is redirecting you. By default, cURL does not follow redirects.

If you see a 301 or 302 in the output, add the -L flag:

bash
curl -IL https://example.com/old-endpoint
This will follow the redirect chain and show you the final status code. If you see an infinite redirect loop, this is the fastest way to catch it.

1. Inspecting the Exact Request/Response Sometimes you need to see exactly what headers your client is sending. Maybe you forgot the Authorization token, or your Accept header is wrong.

The -v (verbose) flag is your best friend:

bash
curl -v -X POST https://api.example.com/v1/login \
-H "Content-Type: application/json" \
-d '{"user":"admin","pass":"secret"}'
The output will show lines starting with > (what cURL sent) and < (what the server returned). This instantly reveals if you are missing a bearer token or sending malformed JSON.

1. The Problem: When You Don't Have a Terminal As developers, we spend most of our time in the terminal. But what happens when you are debugging on a mobile device, or you just want a quick check without opening a new tab?

I got tired of trying to remember cURL flags and writing out long commands every time, so I built a couple of lightweight tools for my own workflow and put them on Site Tools Box (no sign-ups, no ads).

For single URLs: I use the HTTP Status Checker. It gives you the status code, response time, and headers in a clean UI.

For bulk checking: If you have a list of URLs (like checking a sitemap for 404s), use the Bulk HTTP Checker. It runs in your browser and checks up to 20 URLs at once via a CORS proxy.

Wrapping Up
Debugging is 90% observation and 10% fixing. Before you start tearing apart your frontend code, verify the HTTP layer. A quick cURL command or a fast online check can save you hours of frustration.

What's your go-to cURL trick for debugging? Let me know in the comments!