Introduction

A HashSet<string> in .NET is case-sensitive unless you explicitly tell it otherwise. That default is fine for some text, but it is wrong for many technical identifiers such as header names, feature flags, and user-facing keys that should compare without regard to letter case. The right fix is to give the set a string comparer when you create it.

Why the Default Behavior Is Case-Sensitive

HashSet<T> depends on equality and hash-code rules. With strings, the default comparer treats Admin and admin as different values.

1using System;
2using System.Collections.Generic;
3
4var set = new HashSet<string>();
5set.Add("Admin");
6
7Console.WriteLine(set.Contains("admin"));

That prints False because the default comparer is case-sensitive.

If your application expects those values to be the same logical key, the default behavior is not enough.

Use a String Comparer at Construction Time

The correct pattern is to pass the comparer when you construct the set.

1using System;
2using System.Collections.Generic;
3
4var users = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
5{
6    "Admin",
7    "alice"
8};
9
10Console.WriteLine(users.Contains("admin"));
11Console.WriteLine(users.Add("ALICE"));
12Console.WriteLine(users.Count);

With StringComparer.OrdinalIgnoreCase, the set treats case-only differences as equal. That means "alice" and "ALICE" are considered the same entry.

This is usually the cleanest and most maintainable solution.

Choosing the Right Comparer

The comparer matters. Common choices are:

• 'StringComparer.OrdinalIgnoreCase'
• 'StringComparer.CurrentCultureIgnoreCase'
• 'StringComparer.InvariantCultureIgnoreCase'

For machine-oriented identifiers such as protocol tokens, environment flags, and technical names, OrdinalIgnoreCase is usually the best choice because it is stable and culture-independent.

For human-language sorting or comparisons, culture-aware comparers may be appropriate, but they should be chosen deliberately rather than by habit.

Do Not Scatter Manual Lowercasing Everywhere

A common workaround is to lowercase every string before inserting it into the set. That can work, but it spreads normalization logic throughout the code and makes future maintenance harder.

A comparer-based set is usually better:

1using System;
2using System.Collections.Generic;
3
4string[] raw = { "ONE", "two", "Two", "three" };
5var dedup = new HashSet<string>(raw, StringComparer.OrdinalIgnoreCase);
6
7foreach (var item in dedup)
8{
9    Console.WriteLine(item);
10}

This keeps the equality rule in one place instead of forcing every caller to remember to normalize input first.

Be Consistent Across Related Collections

If the application also uses a dictionary for the same kind of keys, use the same comparer there too.

1using System.Collections.Generic;
2
3var allowedHeaders = new HashSet<string>(StringComparer.OrdinalIgnoreCase)
4{
5    "X-Request-Id",
6    "X-Trace-Id"
7};
8
9var headerValues = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
10{
11    ["x-request-id"] = "abc-123"
12};

This avoids situations where membership tests are case-insensitive but dictionary lookups are not, or vice versa.

Rebuilding a Set Must Preserve the Comparer

One subtle issue appears when you serialize set contents and later rebuild the set from stored values. The string comparer is not magically preserved unless your reconstruction code applies it again.

var restored = new HashSet<string>(loadedValues, StringComparer.OrdinalIgnoreCase);

If you forget that comparer during rehydration, the set silently becomes case-sensitive again and you may not notice until duplicate-looking values appear.

You Cannot Change Comparer Semantics In Place

Once the set is created, its hashing behavior is tied to the comparer it was given. If you decide later that the set should be case-insensitive, the usual fix is to create a new set with the right comparer and copy the values into it.

That is another reason to choose the comparer intentionally at the start.

Common Pitfalls

One common mistake is creating a default HashSet<string> and then trying to compensate by lowercasing only some inputs. That leads to inconsistent behavior.

Another mistake is using a culture-sensitive comparer for machine identifiers that should behave predictably across locales.

Developers also sometimes fix the HashSet<string> but forget to use the same comparer in related dictionaries or reconstructed sets, causing subtle contradictions in lookup behavior.

Finally, remember that HashSet<string> does not become case-insensitive automatically just because your application conceptually treats those values as equivalent. The comparer must be explicit.

Summary

• A default HashSet<string> is case-sensitive.
• Use StringComparer.OrdinalIgnoreCase when you want case-insensitive technical identifiers.
• Prefer comparer-based equality over scattered manual lowercasing.
• Keep comparer choices consistent across sets, dictionaries, and rehydrated collections.
• Choose the comparer at construction time because that decision defines the set's hashing behavior.