`curl -I` and `-L` Are How You Debug Redirects, Headers, and Misleading HTTP Behavior Without a Browser

Why browser testing is not enough: the browser hides just enough HTTP detail to make many bugs slower to understand. curl is useful because it lets you ask direct questions about the response chain.

What these flags solve

Two very practical curl behaviors matter constantly in web work:

1. -I to inspect response headers
2. -L to follow redirects

The curl manual documents both, but their combined value is easiest to understand through day-to-day debugging. Web issues often turn out to be header issues, redirect issues, cache issues, or proxy issues. Those are easier to see from the terminal than from a browser tab full of assumptions.

Inspect headers only

curl -I https://example.com

This sends a HEAD request and returns headers without the full body. That is extremely useful when the real question is:

1. what status code is returned
2. is there a redirect location
3. what cache headers exist
4. what content type is being declared

You do not need the full HTML page to answer those.

Follow redirects

curl -L https://example.com

Without -L, curl shows the initial redirect response. With -L, it follows the chain.

This matters because many endpoint complaints are actually about multi-step redirect behavior: HTTP to HTTPS, naked domain to www, old path to new path, application path to login, login back to app, and so on.

Use them together with more visibility

A very practical pattern is:

curl -I -L https://example.com

Or go verbose when the behavior still feels weird:

curl -v -L https://example.com

Now you can see the progression more clearly instead of guessing what the browser may have normalized away for you.

Why redirects cause so much confusion

Because teams often test only the final page and forget the chain that gets users there. But bugs can live in the chain:

1. loops between layers
2. a redirect to the wrong host
3. accidental downgrade or upgrade logic
4. auth redirects that should not happen for public endpoints

The browser will still “do something,” which can make the problem feel murkier than it really is.

A practical example

Suppose your marketing site says canonical redirects are fine, but SEO tools report mixed behavior. Check it directly:

curl -I https://example.com
curl -I https://www.example.com
curl -I -L https://example.com/some-page

Now you can compare status codes and location headers instead of debating abstractly about what the stack should be doing.

Why this is better than instinctively blaming the framework

Frameworks get blamed for a lot of behavior that actually originates from:

1. CDN rules
2. reverse proxies
3. load balancers
4. platform-level redirects
5. auth middleware

If you do not inspect the real HTTP behavior first, you can spend an hour in application code that was not responsible at all.

A small habit that pays off repeatedly

If an endpoint feels odd, check it both with and without redirect following. The contrast is often the clue. One view shows the first response honestly. The other shows the user-facing landing point. Seeing both prevents you from confusing “the final page looks fine” with “the path to it is correct.”

Final recommendation

Use curl -I when the body is noise and the headers are the real story. Use -L when redirect chains matter. Most confusing web routing and caching bugs get easier once you stop browsing around them and start reading the HTTP behavior directly.

Sources

• curl man page