Exception URI formats are not supported
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The .NET exception saying URI formats are not supported usually means the string you passed is not a valid URI for the API you chose. The most common causes are confusing file paths with URLs, passing partially formed strings into new Uri(...), or using an unsupported scheme where the called API expects something more specific.
Start by Distinguishing URI from File Path
A URI and a Windows file path are not the same thing. This often breaks code like:
That may work differently than expected depending on context, and it often leads developers into trouble when the string is later handed to an API that expects http, https, or another absolute URI scheme.
If the value is really a local path, use the file-specific conversion.
Use Uri.TryCreate When Input Is Untrusted
If a string might be malformed, parse it defensively.
This avoids throwing and lets you decide how to handle bad input explicitly.
Absolute and Relative URIs Matter
Some APIs require an absolute URI, not a relative one. These two strings are different cases:
If you pass a relative path into an API that requires an absolute URI with a scheme and host, the exception is a symptom of giving the wrong kind of input, not of .NET URI support being broken.
Spaces and Illegal Characters Need Proper Handling
Another common trigger is feeding raw strings with spaces or illegal characters into URI-sensitive APIs.
If the value is supposed to be a URL built from components, encode the components rather than concatenating arbitrary strings blindly.
Build URIs from Known Parts
When possible, use UriBuilder or safe concatenation of encoded segments.
This is safer than assembling strings manually and hoping the final result is a valid URI.
Watch for API Expectations
Sometimes the exception comes from a downstream API, not from new Uri directly. For example, an HTTP client expects a network URI, while file APIs may accept local paths instead.
If you pass a file path into GetAsync, the problem is not just formatting. It is using the wrong resource type for the API.
Diagnose the Real String
When this exception appears, log the exact value before it is parsed. Many bugs come from invisible whitespace, accidental missing schemes, or path combinations that look valid in the debugger but are not valid URIs.
Common Pitfalls
A common mistake is treating every string location as a URI even when it is really a local file path. Another is assuming example.com is automatically a valid absolute URI without https:// or another scheme. Developers also often build URLs by raw string concatenation and then introduce spaces or malformed query strings. Finally, debugging the receiving API without logging the actual input string usually wastes time because the root cause is almost always in the data passed in.
Summary
- This exception usually means the input string is not a valid URI for the API in use.
- Distinguish local paths from absolute network URIs.
- Use
Uri.TryCreatefor untrusted or user-provided input. - Build URLs from encoded parts instead of ad hoc string concatenation.
- Check whether the called API expects a file path, a relative URI, or a fully qualified absolute URI.

