Introduction

In C#, “is this URL valid?” and “does this URL exist?” are two different questions. Validity is a local syntax check, while existence requires a network request and still may not produce a definitive answer because redirects, authentication, and server behavior all affect the result.

Validate the URL Format First

Use Uri.TryCreate to check whether the string is a well-formed absolute HTTP or HTTPS URL:

1using System;
2
3bool IsWellFormedHttpUrl(string input)
4{
5    return Uri.TryCreate(input, UriKind.Absolute, out var uri)
6           && (uri.Scheme == Uri.UriSchemeHttp || uri.Scheme == Uri.UriSchemeHttps);
7}
8
9Console.WriteLine(IsWellFormedHttpUrl("https://example.com"));

This answers only the syntax question. It does not contact the server.

Check Reachability with HttpClient

If you want to know whether the resource appears reachable, send an HTTP request. A HEAD request is often a good first choice because it asks for headers without downloading the full body.

1using System;
2using System.Net.Http;
3using System.Threading.Tasks;
4
5async Task<bool> UrlAppearsReachableAsync(string url)
6{
7    using var client = new HttpClient { Timeout = TimeSpan.FromSeconds(5) };
8    using var request = new HttpRequestMessage(HttpMethod.Head, url);
9    using var response = await client.SendAsync(request);
10
11    return response.IsSuccessStatusCode;
12}

This is a practical reachability check, but it is not a universal truth test.

Know the Limits of “Exists”

A URL can be valid and still fail reachability checks for many reasons:

• the server requires authentication
• the server blocks HEAD
• the resource redirects
• the server is temporarily unavailable
• the network path is down

That is why “exists” on the web is really “responds the way I expect under current conditions.”

If HEAD is not supported by the server, you may need a fallback GET request. That is more expensive, but sometimes necessary.

Keep Validation and Network Checks Separate

A good design exposes two separate functions:

• one that validates URL syntax
• one that performs a network probe

That keeps calling code honest. A string parser should not pretend it knows whether a remote resource exists, and a network check should not be the first line of defense against malformed input.

Handle Exceptions Explicitly

Network probing can throw exceptions. You should treat those as part of the result contract rather than as unexpected failures:

1async Task<bool> SafeReachabilityCheckAsync(string url)
2{
3    try
4    {
5        return await UrlAppearsReachableAsync(url);
6    }
7    catch (HttpRequestException)
8    {
9        return false;
10    }
11    catch (TaskCanceledException)
12    {
13        return false;
14    }
15}

That makes the check predictable for callers.

Reachability Depends on Context

A URL that returns 404, 401, or a redirect may still be a perfectly valid endpoint in the broader system. Decide what counts as “exists” for your application before hard-coding the rule into one boolean check.

Common Pitfalls

• Treating URL syntax validation as proof that the remote resource exists.
• Assuming a failed HEAD request means the resource is definitely absent.
• Forgetting timeouts and letting reachability checks hang too long.
• Using a full GET request when a lightweight probe would usually be enough.
• Ignoring redirects, authentication, or server-specific behavior when interpreting the response.

Network Success Is Not the Same as Business Success

A URL can respond successfully and still be the wrong resource for your application. In many systems, the real check is not only status code but whether the response behavior matches your specific expectation.

Summary

• URL validity and URL existence are different questions.
• Use Uri.TryCreate for syntax validation.
• Use HttpClient to probe remote reachability when needed.
• Treat “exists” as an operational check, not a guaranteed fact about the resource.
• Keep parsing logic and network logic separate so the API stays clear.