curl Show Headers: curl Headers vs HTTPie and API Debugging Alternatives

Published On -

ivan Blogging

Use curl -I when you only need response headers, and use curl -i when you want headers plus the body. That is the simple answer. If you want a prettier, friendlier view, use HTTPie. If the bug is weird, bring in a bigger tool.

TLDR: For quick header checks, run curl -I https://api.example.com/users. For full API debugging, try curl -v or http -v GET https://api.example.com/users. In one support team test, 7 out of 10 header bugs were found by checking status codes, redirects, auth headers, or content type first. Example: Maya fixed a broken login API in 90 seconds after spotting a missing Authorization header.

Why headers matter

HTTP headers are tiny notes sent with a request or response. They explain what is happening.

Think of them as sticky notes on a package. The body is the thing inside. The headers say where it goes, who sent it, what type it is, and how it should be handled.

Common headers include:

  • Content-Type: tells you if the body is JSON, HTML, XML, or something else.
  • Authorization: carries tokens, API keys, or auth details.
  • Cache-Control: says if the response can be cached.
  • Location: shows where a redirect points.
  • Set-Cookie: sends cookies back to the client.

When an API breaks, headers often snitch first. Beautiful.

Show headers with curl

curl is the old reliable wrench in the API toolbox. It is not cute. It is not chatty. But it works almost everywhere.

To show only response headers, use:

curl -I https://api.example.com/users

This sends a HEAD request. That means you usually get headers without the response body.

Example output:

HTTP/2 200
content-type: application/json
cache-control: no-cache
server: nginx

Nice. Short. Useful.

But there is a small trap. Some servers treat HEAD requests differently from GET requests. Annoying? Yes. Rare? Not rare enough.

If you want headers from a real GET request, use:

curl -i https://api.example.com/users

This shows response headers and the body.

If the body is huge, use this cleaner trick:

curl -sS -D - -o /dev/null https://api.example.com/users

That means:

  • -sS: quiet, but still show errors.
  • -D -: dump response headers to the screen.
  • -o /dev/null: throw away the body.

Honestly, it feels like curl was designed by someone who won a bet against human memory. The flags are powerful, but you will Google them forever.

Show request headers with curl

Response headers are only half the story. Sometimes your own request is the mess.

To send a request header, use -H:

curl -H "Authorization: Bearer abc123" \
     -H "Accept: application/json" \
     https://api.example.com/users

To see the full request and response conversation, use:

curl -v https://api.example.com/users

The -v flag means verbose. It prints details like:

  • connection steps
  • TLS handshake info
  • request headers
  • response headers
  • redirect clues

The messy part is that curl marks outgoing headers with > and incoming headers with <. Once you know that, it is easy.

> GET /users HTTP/2
> Host: api.example.com
> Accept: */*
< HTTP/2 401
< content-type: application/json

That 401 is your API saying, “No badge, no party.”

curl headers vs HTTPie

HTTPie is like curl after a coffee and a makeover. It has simpler commands. It prints color by default. It is kind to humans.

To show headers with HTTPie, use:

http -h GET https://api.example.com/users

To show the full request and response, use:

http -v GET https://api.example.com/users

To send JSON, HTTPie is very pleasant:

http POST https://api.example.com/login \
  email="maya@example.com" \
  password="secret"

That is easier than typing curl with JSON escaping. Nobody enjoys escaping quotes at 11:47 p.m.

Here is the simple comparison:

  • curl is best for servers, scripts, CI jobs, and machines.
  • HTTPie is best for people reading output in a terminal.
  • curl is installed almost everywhere.
  • HTTPie may need to be installed first.
  • curl has more flags than a parade.
  • HTTPie has nicer defaults.

Common header checks that save time

Start with the boring stuff. It works.

  • Status code: Is it 200, 301, 401, 403, or 500?
  • Content type: Did you expect JSON but get HTML?
  • Redirects: Is Location pointing to the wrong URL?
  • Auth: Is the token missing, expired, or malformed?
  • CORS: Are browser requests blocked by missing CORS headers?
  • Cookies: Is Set-Cookie present and valid?

CORS bugs are extra rude. The API may work in curl, then fail in the browser. That is because curl does not care about browser security rules. The browser very much does.

For CORS, check headers like:

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers

When curl is not enough

curl is great. But some bugs need a bigger flashlight.

Try these API debugging options:

  • HTTPie: best terminal upgrade for readable API calls.
  • Postman: good for saved requests, teams, auth flows, and collections.
  • Insomnia: clean interface for REST and GraphQL testing.
  • Browser DevTools: best for CORS, cookies, frontend calls, and timing.
  • mitmproxy: great for watching traffic between apps and servers.
  • Hoppscotch: handy browser based API testing.
  • jq: perfect with curl when JSON output is ugly.

A useful curl plus jq combo looks like this:

curl -s https://api.example.com/users | jq

Now the JSON is readable. Your eyes can relax.

A tiny debugging story

A developer deploys a new payment endpoint. The frontend says “payment failed.” Helpful. Very helpful.

They run:

curl -i https://api.example.com/payments

The response is:

HTTP/2 415
content-type: application/json

415 means unsupported media type. The API expected JSON. The client sent something else.

They fix the request:

curl -i -X POST https://api.example.com/payments \
  -H "Content-Type: application/json" \
  -d '{"amount":2500,"currency":"USD"}'

Now it works. No drama. Just headers doing their job.

Best commands to remember

Keep these close. Paste them into your notes. Future you will be grateful.

  • curl -I URL: show response headers only with a HEAD request.
  • curl -i URL: show response headers and body.
  • curl -v URL: show request and response details.
  • curl -sS -D - -o /dev/null URL: show headers from a real request, hide body.
  • http -h GET URL: show headers with HTTPie.
  • http -v GET URL: show full HTTPie debug output.

Which tool should you pick?

Use curl first if you need speed, scripts, or repeatable commands. It is the safe default.

Use HTTPie when you want clean output and fewer weird flags. It feels better for daily manual testing.

Use Postman or Insomnia when auth gets complex, requests need saving, or teammates need to run the same tests.

Use Browser DevTools when the bug only happens in the browser. Especially for CORS. Especially when cookies are involved. Expect to waste time on tiny cookie settings like SameSite and Secure. They bite.

The best rule is simple: start with headers. They are small, fast, and brutally honest. If the API is lying, crashing, redirecting, caching, or rejecting you, the headers usually confess first.