Introduction

In .NET, WebClient is convenient for simple downloads, but it does not expose the HTTP status code directly as a normal property after every request. To get the status code, you usually either catch a WebException for error responses or subclass WebClient so you can inspect the underlying WebResponse.

Why WebClient Hides the Status Code

WebClient is a high-level wrapper around older networking APIs. It is designed for convenience methods such as DownloadString and UploadString, not for detailed HTTP inspection. That is why developers are often surprised to find that there is no built-in StatusCode property on the class itself.

This simple example downloads content successfully, but gives you no direct status-code access:

1using System;
2using System.Net;
3
4class Program
5{
6    static void Main()
7    {
8        using (var client = new WebClient())
9        {
10            string html = client.DownloadString("https://example.com/");
11            Console.WriteLine(html.Length);
12        }
13    }
14}

If the request succeeds, you get the body. If it fails with an HTTP error, you get an exception.

Read the Status Code from WebException

For non-success responses such as 404 or 500, WebClient throws a WebException. The response is usually still available, and if it is HTTP you can cast it to HttpWebResponse.

1using System;
2using System.Net;
3
4class Program
5{
6    static void Main()
7    {
8        using (var client = new WebClient())
9        {
10            try
11            {
12                string body = client.DownloadString("https://httpbin.org/status/404");
13                Console.WriteLine(body);
14            }
15            catch (WebException ex) when (ex.Response is HttpWebResponse response)
16            {
17                Console.WriteLine((int)response.StatusCode);
18                Console.WriteLine(response.StatusCode);
19            }
20        }
21    }
22}

This is the simplest way to inspect status codes when you only care about error cases.

Capture Successful Status Codes by Subclassing WebClient

If you want access to the status code even when the request succeeds, subclass WebClient and override GetWebResponse.

1using System;
2using System.Net;
3
4public class StatusWebClient : WebClient
5{
6    public HttpStatusCode? StatusCode { get; private set; }
7
8    protected override WebResponse GetWebResponse(WebRequest request)
9    {
10        WebResponse response = base.GetWebResponse(request);
11        if (response is HttpWebResponse httpResponse)
12        {
13            StatusCode = httpResponse.StatusCode;
14        }
15        return response;
16    }
17
18    protected override WebResponse GetWebResponse(WebRequest request, IAsyncResult result)
19    {
20        WebResponse response = base.GetWebResponse(request, result);
21        if (response is HttpWebResponse httpResponse)
22        {
23            StatusCode = httpResponse.StatusCode;
24        }
25        return response;
26    }
27}
28
29class Program
30{
31    static void Main()
32    {
33        using (var client = new StatusWebClient())
34        {
35            string html = client.DownloadString("https://example.com/");
36            Console.WriteLine(client.StatusCode);
37            Console.WriteLine(html.Length);
38        }
39    }
40}

This pattern is useful when your code needs to record or branch on 200, 204, or 304 responses without rewriting the call site completely.

Prefer HttpClient in New Code

If you are writing new .NET code, HttpClient is usually the better API because it returns an HttpResponseMessage with the status code already exposed.

1using System;
2using System.Net.Http;
3using System.Threading.Tasks;
4
5class Program
6{
7    static async Task Main()
8    {
9        using var client = new HttpClient();
10        HttpResponseMessage response = await client.GetAsync("https://example.com/");
11        Console.WriteLine((int)response.StatusCode);
12        Console.WriteLine(response.StatusCode);
13    }
14}

That does not change how WebClient works, but it is the cleaner option for new applications.

Handle Redirects and Non-HTTP Responses Carefully

WebClient can also deal with FTP and file URLs, not just HTTP. In those cases, an HttpWebResponse cast is not appropriate. Even within HTTP, automatic redirects can mean the final visible status differs from the first server response unless you disable redirect handling lower in the stack.

That is another reason WebClient is fine for simple tasks, but less ideal for advanced HTTP behavior.

Common Pitfalls

The most common mistake is expecting WebClient to expose a status-code property directly after DownloadString. Another frequent issue is only checking exceptions and then forgetting that successful requests also have meaningful status codes. Developers also sometimes cast ex.Response to HttpWebResponse without checking the actual protocol. Finally, many projects keep extending WebClient for modern HTTP use cases even though HttpClient is better suited to that job.

Summary

• 'WebClient does not directly expose HTTP status codes as a built-in convenience property.'
• For error responses, catch WebException and inspect the HttpWebResponse.
• For success responses, subclass WebClient and override GetWebResponse.
• Use HttpClient instead for new code when you need clear access to status and headers.
• Cast to HttpWebResponse only when the response is actually HTTP.