Introduction

Yes, there is a real difference between string.Empty and null in C#. They may both display as "nothing" in a UI, but they represent different program states and often carry different business meaning.

What null means

null means the variable does not currently reference any string object.

1string? name = null;
2
3Console.WriteLine(name == null);   // True
4Console.WriteLine(name is null);   // True

Because there is no string instance, calling members on it throws:

string? name = null;
Console.WriteLine(name.Length); // NullReferenceException

In domain terms, null often means "unknown", "not provided", or "not loaded yet".

What string.Empty means

string.Empty is a valid string object whose length is zero. It is equivalent to "".

1string value = string.Empty;
2
3Console.WriteLine(value.Length);      // 0
4Console.WriteLine(value == "");       // True
5Console.WriteLine(value is null);     // False

This usually means "known to be blank" rather than "missing entirely". That difference matters in validation, serialization, and API contracts.

Use the right check for your rule

Most code should not manually compare against both states every time. Use the built-in helpers that match the business rule.

1string? a = null;
2string b = string.Empty;
3string c = "   ";
4
5Console.WriteLine(string.IsNullOrEmpty(a));       // True
6Console.WriteLine(string.IsNullOrEmpty(b));       // True
7Console.WriteLine(string.IsNullOrWhiteSpace(c));  // True

Use string.IsNullOrEmpty when missing and empty should be treated the same. Use string.IsNullOrWhiteSpace when strings containing only spaces should also count as empty.

Check explicitly for null only when the distinction matters.

The distinction matters in APIs and persistence

This is where developers most often get burned. An omitted JSON property is not always the same as a property explicitly set to "". Likewise, a database column with NULL can carry different meaning from an empty string.

If your code normalizes everything too early, you may destroy information that downstream logic needed. For example:

string? rawInput = GetUserInput();
string normalized = rawInput ?? string.Empty;

That is fine if your application genuinely wants to erase the distinction. It is not fine if null means "not supplied yet" and empty means "supplied but blank."

Choose a convention deliberately

The best convention depends on the domain:

• normalize to string.Empty when consumers always want a safe usable string
• preserve null when "missing" is semantically different from "blank"
• document whether fields may be null, empty, or whitespace

That documentation matters more than personal style debates over string.Empty versus "". The real problem is usually unclear semantics, not the literal syntax.

This becomes especially important in layered systems. A web form, API model, database row, and domain object may each have different rules about whether empty and missing values should collapse into one state or stay distinct.

Common Pitfalls

• Assuming null and string.Empty are interchangeable in serializers, ORMs, and API contracts.
• Using value == "" as the only emptiness check and missing null or whitespace-only input.
• Normalizing to string.Empty too early and losing the meaning of "not provided."
• Ignoring nullable reference warnings that already tell you a string may be null.
• Treating this as only a syntax preference question instead of a domain semantics question.

Summary

• 'null means no string object is referenced.'
• 'string.Empty means a real string exists but contains zero characters.'
• Member access on null throws; member access on string.Empty is safe.
• Use string.IsNullOrEmpty or string.IsNullOrWhiteSpace for most validation code.
• Preserve the difference when your domain needs to distinguish missing text from intentionally blank text.