String Comparison - Comparing Strings Safely and Effectively in C#

Vaibhav • September 10, 2025

Comparing strings looks simple-until it isn’t. Do you want case sensitivity or not? Should “color” equal “colour” in a user-facing search? Does culture matter for sorting? In C#, you can compare strings using operators, helper methods, and comparison options that control case, culture, and sort rules. This article gives you a practical playbook: when to use == vs Equals, how to choose the right StringComparison, how to sort predictably, and how to avoid common pitfalls-while staying within the scope of Chapter 8.

1) The basics: == vs Equals

In C#, the == operator for string compares contents (not references). That’s convenient:

string a = "hello";
string b = "he" + "llo";
Console.WriteLine(a == b);          // True (content equality)
Console.WriteLine(a.Equals(b));     // True (default equals uses culture-sensitive rules depending on overload)

However, Equals has overloads that let you specify StringComparison, which is crucial for controlling case and culture. Prefer an overload that makes intent explicit:

string userInput = "Hello";
bool same = userInput.Equals("hello", StringComparison.OrdinalIgnoreCase); // True

2) Understanding StringComparison options

The StringComparison enum lets you pick comparison semantics explicitly:

• Ordinal - byte-wise (Unicode code point) comparison; fast, stable, and culture‑independent.
• OrdinalIgnoreCase - ordinal semantics but case‑insensitive; ideal for case-insensitive keys and protocols.
• CurrentCulture - uses the current thread’s culture; preferred for user-facing text.
• CurrentCultureIgnoreCase - culture‑aware and case‑insensitive.
• InvariantCulture - culture‑neutral rules; useful for round‑tripping or data that must be culture-stable.
• InvariantCultureIgnoreCase - culture‑neutral and case‑insensitive.

string x = "straße";     // German sharp s (ß)
string y = "strasse";

Console.WriteLine(x.Equals(y, StringComparison.Ordinal));               // False
Console.WriteLine(x.Equals(y, StringComparison.CurrentCulture));        // May be True in some cultures (treats ß ~ ss)
Console.WriteLine(x.Equals(y, StringComparison.InvariantCulture));      // Culture-neutral behavior (typically False)

3) Case sensitivity: ignore case the right way

A common trap is normalizing both sides to upper/lower case and then comparing. That’s slower and may be incorrect in certain locales. Use the ignore‑case overloads instead:

// ✅ Correct and clear
bool ok1 = "HELLO".Equals("hello", StringComparison.OrdinalIgnoreCase);

// ❌ Avoid: allocates new strings and may be locale-problematic
bool ok2 = "HELLO".ToLower() == "hello".ToLower();

4) StartsWith / EndsWith with comparison options

Always use overloads that take a StringComparison so behavior is explicit and consistent:

string s = "Readme.TXT";

bool hasPrefix = s.StartsWith("read", StringComparison.OrdinalIgnoreCase); // True
bool hasSuffix = s.EndsWith(".txt", StringComparison.OrdinalIgnoreCase);   // True

This pattern is essential for file extensions, protocol prefixes, and any text that needs case-insensitive checks.

5) Sorting strings predictably

The order you get from List<string>.Sort() depends on the comparer used. For user-facing lists, you often want culture-aware ordering; for internal order (like IDs), you want ordinal. Provide the comparer explicitly:

var names = new List<string> { "ä", "a", "z" };

// Culture-aware sort (CurrentCulture)
names.Sort(StringComparer.CurrentCulture);
// For case-insensitive UI sort:
names.Sort(StringComparer.CurrentCultureIgnoreCase);

// Ordinal sort (binary)
names.Sort(StringComparer.Ordinal);
// Ordinal, case-insensitive
names.Sort(StringComparer.OrdinalIgnoreCase);

UI lists should feel natural to the user’s language, so use CurrentCulture. For machine-stable order, use Ordinal.

6) Comparing with String.Compare and CompareTo

When you need the relative order (less than, equal, greater than), use String.Compare or CompareTo. Both return an int (< 0, 0, > 0).

string a = "Alpha";
string b = "alpha";

int c1 = string.Compare(a, b, StringComparison.Ordinal);          // not equal by ordinal
int c2 = string.Compare(a, b, StringComparison.OrdinalIgnoreCase); // 0 (equal ignoring case)

// Instance method (uses culture-sensitive comparison by default)
int c3 = a.CompareTo(b);  // be explicit if you care about semantics

7) Using StringComparer and collection behaviors

Collections like Dictionary<TKey,TValue> and HashSet<T> accept an IEqualityComparer<string>. Use built‑in StringComparer singletons to control key equality:

// Case-insensitive dictionary for user-provided keys (current culture)
var usersByName = new Dictionary<string, int>(StringComparer.CurrentCultureIgnoreCase);

// Ordinal, case-insensitive set for protocol tokens or identifiers
var tokens = new HashSet<string>(StringComparer.OrdinalIgnoreCase);

usersByName["Vaibhav"] = 1;
Console.WriteLine(usersByName.ContainsKey("vaibhav")); // True

This ensures that all lookups and key comparisons use the same rules throughout the collection’s lifetime-no ad‑hoc comparisons sprinkled around the code.

8) Null safety and defensive helpers

Comparing strings when one might be null is common. Equals is safe on a non‑null receiver, but not on a null one. A simple helper clarifies intent:

static bool EqualsIgnoreCase(string a, string b)
{
    return string.Equals(a, b, StringComparison.OrdinalIgnoreCase);
}

// Usage
string x = null;
string y = "test";
Console.WriteLine(EqualsIgnoreCase(x, y)); // False (safe, no exception)

Using string.Equals(a, b, ...) is null-safe because it’s a static method that accepts null operands.

9) Reference equality vs content equality

Very rarely, you might wonder if two variables reference the exact same string object. Use object.ReferenceEquals for that, but this is not how you test content equality:

string a = "test";
string b = string.Copy(a); // creates a distinct instance with same content (API marked obsolete in modern .NET)
Console.WriteLine(object.ReferenceEquals(a, b)); // False
Console.WriteLine(a == b);                      // True (content equal)

10) Trimming, whitespace, and “visually equal” strings

Users often paste values with stray spaces. Decide whether surrounding whitespace should matter, then enforce it consistently:

string left  = "Vaibhav ";
string right = "vaibhav";

bool sameStrict = left.Equals(right, StringComparison.OrdinalIgnoreCase);   // False (space differs)
bool sameLoose  = left.Trim().Equals(right.Trim(), StringComparison.OrdinalIgnoreCase); // True

Use trimming only where appropriate (e.g., usernames, tags). Document your rule: “Comparisons ignore surrounding whitespace and case.”

11) Unicode and normalization (quick heads‑up)

Some characters can be represented in multiple Unicode forms (composed vs decomposed). Ordinal comparison treats different byte sequences as different-even if they look the same on screen. We’ll cover normalization in depth in the Unicode and Encoding article. For most basic applications, culture comparisons or user‑facing logic hide this complexity; for strict binary equality, use ordinal.

12) Putting it all together: practical recipes

12.1) Case‑insensitive “contains” for UI searches

string.Contains has an overload with StringComparison in modern C#:

string text = "C# String Comparison";
bool found = text.Contains("string", StringComparison.CurrentCultureIgnoreCase); // True

12.2) File extension check (safe and robust)

string file = "report.PDF";
bool isPdf = file.EndsWith(".pdf", StringComparison.OrdinalIgnoreCase); // True

12.3) Case‑insensitive dictionary of headers

var headers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
{
    ["Content-Type"] = "text/plain",
};
Console.WriteLine(headers.ContainsKey("content-type")); // True

12.4) Sort names for display (culture‑aware)

var people = new List<string> { "Åke", "Ada", "Émile" };
people.Sort(StringComparer.CurrentCulture);

13) Decision checklist (print‑worthy)

• Internal tokens/IDs/keys: Ordinal or OrdinalIgnoreCase.
• User‑facing comparisons/sorts: CurrentCulture or CurrentCultureIgnoreCase.
• Culture‑stable (not user‑visible): InvariantCulture or InvariantCultureIgnoreCase.
• StartsWith/EndsWith/Contains: always choose the overload with StringComparison.
• Collections with string keys: pass a StringComparer (e.g., OrdinalIgnoreCase).
• Whitespace rules: trim intentionally; document whether spaces are significant.
• Null‑safety: prefer string.Equals(a, b, ...) or a small helper over instance Equals on possibly null references.

Summary

Correct string comparison is about intent. For internal data and keys, choose ordinal semantics for speed and predictability, optionally ignoring case. For user text, use current culture so results feel natural. Make case and culture choices explicit with StringComparison and StringComparer, use the comparison overloads of StartsWith/EndsWith/Contains, and set collection comparers up‑front. Be deliberate about trimming and null handling, and keep normalization in mind for advanced Unicode scenarios. With these patterns, your comparisons will be clear, correct, and consistent across your codebase.