Introduction

In C#, string and String are not two different data types. string is just the language keyword alias for System.String, so the difference is about syntax and style rather than behavior, performance, or memory layout.

They Compile To The Same Type

These declarations all describe the same .NET type:

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        string a = "hello";
8        String b = "world";
9        System.String c = a + " " + b;
10
11        Console.WriteLine(c);
12        Console.WriteLine(a.GetType() == b.GetType());
13    }
14}

At runtime there is no distinction between those three variables. They are all System.String instances.

That means there is no performance advantage to choosing one spelling over the other.

Why string Is Usually Preferred

C# provides keyword aliases for several common CLR types:

• 'string for System.String'
• 'int for System.Int32'
• 'bool for System.Boolean'

Most C# code uses those aliases for ordinary declarations because they read like natural C# instead of framework-qualified type names.

string name = "Ada";
int age = 36;
bool active = true;

That is why most style guides prefer string in method signatures, local variables, fields, and properties.

Where String Still Shows Up Naturally

You will still see String in some situations, especially when calling static members on the type:

1using System;
2
3class Program
4{
5    static void Main()
6    {
7        string value = "   codemia   ";
8        Console.WriteLine(String.IsNullOrWhiteSpace(value));
9        Console.WriteLine(value.Trim());
10    }
11}

Some teams also prefer framework type names in reflection-heavy or cross-language code because they want consistency with other System.* types. That is a convention choice, not a technical requirement.

Another practical difference is that string works without using System;, while String usually needs either that namespace import or the fully qualified name System.String.

Consistency Matters More Than The Spelling

Most teams pick one style for normal declarations and stick to it. In C# projects, that usually means keyword aliases such as string, int, and bool for variables, parameters, properties, and return types.

1public string FormatName(string firstName, string lastName)
2{
3    return $"{lastName}, {firstName}";
4}

You might still see StringComparer, StringBuilder, or String.IsNullOrEmpty, because those are actual framework type names and static members. That does not conflict with using string for local declarations. The important part is internal consistency, since mixed style makes the code look accidental.

Nullability Does Not Change The Story

Nullable reference types do not create a new distinction here. These two mean the same thing:

1#nullable enable
2
3string? a = null;
4String? b = null;

Most developers still prefer string? because it reads more naturally in C# code.

What Actually Matters More Than The Alias

The real string decisions in C# are not about string versus String. They are about:

• whether a value can be null
• how you compare strings
• culture-aware versus ordinal operations
• allocation patterns and interpolation
• encoding when data crosses process or network boundaries

Those choices affect correctness and performance. The alias choice mostly affects consistency.

Common Pitfalls

• Thinking string is a primitive value type while String is a reference type.
• Expecting a performance difference between the two spellings.
• Using String in ordinary declarations without importing System.
• Mixing both styles randomly in the same file and making the code feel inconsistent.
• Assuming framework names like StringBuilder mean you should also replace every string keyword in your declarations.
• Spending too much energy on the alias question while ignoring actual string-handling concerns.

Summary

• 'string is the C# alias for System.String.'
• 'string, String, and System.String all represent the same runtime type.'
• There is no behavior or performance difference between them.
• Use string for normal C# declarations unless your codebase has a deliberate convention otherwise.
• Keep the codebase consistent, and focus more on comparison rules and null handling than on the alias itself.