What is the difference between String and string in C#?

Created 10.08.2008 07:18
Viewed 1.16M times
6890 votes

Example (note the case):

string s = "Hello world!";
String s = "Hello world!";

What are the guidelines for the use of each? And what are the differences?

@O.R.Mapper, but the fact remains that string is a lexical construct of the C# grammar whereas System.String is just a type. Regardless of any explicit difference mentioned in any spec, there is still this implicit difference that could be accomodated with some ambiguity. The language itself must support string in a way that the implementation is not (quite) so obligated to consider for a particular class in the BCL. by Kirk Woll, 02.12.2014 03:05
@KirkWoll: According to the language specification, the language itself must consider string to be exactly the same as the BCL type System.String, nothing else. That is not ambiguous at all. Of course, you can implement your own compiler, using the C# grammar, and use all of the tokens found like that for something arbitrary, unrelated to what is defined in the C# language specification. However, the resulting language would only be a C# lookalike, it could not be considered C#. by O. R. Mapper, 02.12.2014 08:22
You can use string without a using directive for System. You can't do that with String. by Wilsu, 30.11.2015 08:52
read about Boxing/Unboxing too btw. - msdn.microsoft.com/en-us/library/yz2be5wk.aspx - "The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object" by George Birbilis, 10.05.2016 17:39
For someone coming from Algol and Fortran, this discussion shows there is something wrong with string. It is needed to abbreviate System.String, but, as an alias, it seems quite like, but not exactly the same thing. After several years of C#, though, I'd say, it is safe to simply use string and string.Format() and not to worry about System.String. by Roland, 20.12.2016 00:24
Since 2014 conventions have changed a lot in .net framework. Now there's no existence for String (capital s) while declaring variables. only alias string (small s) is available. Microsoft might wanted to remove confusing programming approach! by Sangeeta, 29.11.2018 09:53
@Sangeeta What are you saying? The System.String class is still there, and the string keyword is still an alias for it. Just like System.Int32 and int. They are literally the same thing. by Craig, 08.12.2018 02:14
I hadn't paid attention to whether there was a difference between String and string, and it was a good question, and it made me learn something useful when I just started programming. by elnaz jangi, 12.06.2020 12:46
System.String myString = "Ha!"; @Wilsu No? I just did. by SacredGeometry, 31.12.2020 01:37
Show remaining 4 comments
Answers 50

string is an alias in C# for System.String.
So technically, there is no difference. It's like int vs. System.Int32.

As far as guidelines, it's generally recommended to use string any time you're referring to an object.


string place = "world";

Likewise, I think it's generally recommended to use String if you need to refer specifically to the class.


string greet = String.Format("Hello {0}!", place);

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

10.08.2008 07:22
If you decide to use StyleCop and follow that, that will say to use the types specific to the language. So for C# you'll have string (instead of String), int (instead of Int32), float (instead of Single) - stylecop.soyuz5.com/SA1121.html by Dominic Zukiewicz, 22.05.2012 22:36
I always use the aliases because I've assumed one day it might come in handy because they are acting as an abstraction, so therefore can have their implementations changed without me having to know. by Rob, 12.10.2012 23:25
Visual Studio 2015 says that String.Format should be changed to string.Format, so I guess Microsoft is going that way. I have also always used String for the static methods. by Sami Kuhmonen, 22.12.2014 05:21
What do you say to the fact that you could define your own type “String” but can’t do the same for “string” as it’s a keyword, as explained in stackoverflow.com/questions/7074/… by jmoreno, 13.10.2020 21:37
I gues then... Just be conistent. Use string or String or use a cerntain one in a specific case, but always in that case. by Rob L, 29.11.2020 06:50
It's worth noting that string is not an alias for String but is an alias for global::System.String. When you use the alias, it is guaranteed to resolve to the system string type and not some other class called String. by John Wu, 13.01.2021 00:16
Show remaining 1 comments

Just for the sake of completeness, here's a brain dump of related information...

As others have noted, string is an alias for System.String. Assuming your code using String compiles to System.String (i.e. you haven't got a using directive for some other namespace with a different String type), they compile to the same code, so at execution time there is no difference whatsoever. This is just one of the aliases in C#. The complete list is:

object:  System.Object
string:  System.String
bool:    System.Boolean
byte:    System.Byte
sbyte:   System.SByte
short:   System.Int16
ushort:  System.UInt16
int:     System.Int32
uint:    System.UInt32
long:    System.Int64
ulong:   System.UInt64
float:   System.Single
double:  System.Double
decimal: System.Decimal
char:    System.Char

Apart from string and object, the aliases are all to value types. decimal is a value type, but not a primitive type in the CLR. The only primitive type which doesn't have an alias is System.IntPtr.

In the spec, the value type aliases are known as "simple types". Literals can be used for constant values of every simple type; no other value types have literal forms available. (Compare this with VB, which allows DateTime literals, and has an alias for it too.)

There is one circumstance in which you have to use the aliases: when explicitly specifying an enum's underlying type. For instance:

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint   {} // Valid

That's just a matter of the way the spec defines enum declarations - the part after the colon has to be the integral-type production, which is one token of sbyte, byte, short, ushort, int, uint, long, ulong, char... as opposed to a type production as used by variable declarations for example. It doesn't indicate any other difference.

Finally, when it comes to which to use: personally I use the aliases everywhere for the implementation, but the CLR type for any APIs. It really doesn't matter too much which you use in terms of implementation - consistency among your team is nice, but no-one else is going to care. On the other hand, it's genuinely important that if you refer to a type in an API, you do so in a language-neutral way. A method called ReadInt32 is unambiguous, whereas a method called ReadInt requires interpretation. The caller could be using a language that defines an int alias for Int16, for example. The .NET framework designers have followed this pattern, good examples being in the BitConverter, BinaryReader and Convert classes.

18.10.2008 18:52

String stands for System.String and it is a .NET Framework type. string is an alias in the C# language for System.String. Both of them are compiled to System.String in IL (Intermediate Language), so there is no difference. Choose what you like and use that. If you code in C#, I'd prefer string as it's a C# type alias and well-known by C# programmers.

I can say the same about (int, System.Int32) etc..

18.10.2008 17:25
I personally prefer using "Int32", since it immediately shows the range of the value. Imagine if they upgraded the type of "int" on later higher-bit systems. 'int' in c is apparently seen as "the integer type that the target processor is most efficient working with", and defined as "at least 16 bit". I'd prefer predictable consistency there, thank you very much. by Nyerguds, 28.04.2016 11:41
@MyDaftQuestions I concur. If anything it would make sense to consistently use the .net types because they are language ignorant and the type is obvious, independent of any language (do I know all of F#'s or VB's idiosyncrasies?). by Peter - Reinstate Monica, 21.01.2017 17:39
@Nyerguds There are two reasons to simply not worry about it. One is that int is defined in the C# language spec as a 32 bit integer regardless of the hardware. C#, despite a shared heritage in the mists of time, is not actually C. Changing int to a 64 bit integer would be a breaking change in the specification and the language. It would also require redefining long, as long is currently the 64 bit integer. The other reason not to worry is irrelevant since the types will never change, but .NET is just abstract enough that 99% of the time you don't have to think about it anyway. ;-) by Craig, 08.12.2018 02:47
@Craig I dig into lots of old proprietary game formats where I do have to think about that all the time, though. And then using Int16, Int32 and Int64 is a lot more transparent in the code than using the rather nondescriptive short, int and long by Nyerguds, 09.12.2018 02:29
But short, not, long, float, double, et al are descriptive, because they’re in the language spec. C# is not C. I prefer them on declarations because they’re concise, small, and aesthetically pleasing. I do prefer the Torre library names on API’s where the API has a data type dependency. by Craig, 14.10.2020 15:49

The best answer I have ever heard about using the provided type aliases in C# comes from Jeffrey Richter in his book CLR Via C#. Here are his 3 reasons:

  • I've seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# the string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used.
  • In C#, long maps to System.Int64, but in a different programming language, long could map to an Int16 or Int32. In fact, C++/CLI does in fact treat long as an Int32. Someone reading source code in one language could easily misinterpret the code's intention if he or she were used to programming in a different programming language. In fact, most languages won't even treat long as a keyword and won't compile code that uses it.
  • The FCL has many methods that have type names as part of their method names. For example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32, ReadSingle, and so on, and the System.Convert type offers methods such as ToBoolean, ToInt32, ToSingle, and so on. Although it's legal to write the following code, the line with float feels very unnatural to me, and it's not obvious that the line is correct:
BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

So there you have it. I think these are all really good points. I however, don't find myself using Jeffrey's advice in my own code. Maybe I am too stuck in my C# world but I end up trying to make my code look like the framework code.

15.08.2008 23:00

string is a reserved word, but String is just a class name. This means that string cannot be used as a variable name by itself.

If for some reason you wanted a variable called string, you'd see only the first of these compiles:

StringBuilder String = new StringBuilder();  // compiles
StringBuilder string = new StringBuilder();  // doesn't compile 

If you really want a variable name called string you can use @ as a prefix:

StringBuilder @string = new StringBuilder();

Another critical difference: Stack Overflow highlights them differently.

24.02.2009 05:14

There is one difference - you can't use String without using System; beforehand.

27.08.2008 18:21

It's been covered above; however, you can't use string in reflection; you must use String.

19.10.2008 01:04
I do not understand what this answer means and why it was upvoted. You can use typeof(string) in reflection. Example one: if (someMethodInfo.ReturnType == typeof(string)) { ... } Example two: var p = typeof(string).GetProperty("FirstChar", BindingFlags.NonPublic | BindingFlags.Instance); Where is it that you must use String, not string? If you try things like Type.GetType("String") or Type.GetType("string"), neither will find the class because the namespace is missing. If for some silly reason you compare .Name of a type to "string" in a case-sensitive way, you are right. by Jeppe Stig Nielsen, 24.05.2019 12:04

System.String is the .NET string class - in C# string is an alias for System.String - so in use they are the same.

As for guidelines I wouldn't get too bogged down and just use whichever you feel like - there are more important things in life and the code is going to be the same anyway.

If you find yourselves building systems where it is necessary to specify the size of the integers you are using and so tend to use Int16, Int32, UInt16, UInt32 etc. then it might look more natural to use String - and when moving around between different .net languages it might make things more understandable - otherwise I would use string and int.

10.08.2008 07:26

I prefer the capitalized .NET types (rather than the aliases) for formatting reasons. The .NET types are colored the same as other object types (the value types are proper objects, after all).

Conditional and control keywords (like if, switch, and return) are lowercase and colored dark blue (by default). And I would rather not have the disagreement in use and format.


String someString; 
string anotherString; 
03.09.2008 18:58

string and String are identical in all ways (except the uppercase "S"). There are no performance implications either way.

Lowercase string is preferred in most projects due to the syntax highlighting

18.10.2008 16:50

C# is a language which is used together with the CLR.

string is a type in C#.

System.String is a type in the CLR.

When you use C# together with the CLR string will be mapped to System.String.

Theoretically, you could implement a C#-compiler that generated Java bytecode. A sensible implementation of this compiler would probably map string to java.lang.String in order to interoperate with the Java runtime library.

17.03.2009 20:29

This YouTube video demonstrates practically how they differ.

But now for a long textual answer.

When we talk about .NET there are two different things one there is .NET framework and the other there are languages ( C#, VB.NET etc) which use that framework.

enter image description here

"System.String" a.k.a "String" ( capital "S") is a .NET framework data type while "string" is a C# data type.

enter image description here

In short "String" is an alias ( the same thing called with different names) of "string". So technically both the below code statements will give the same output.

String s = "I am String";


string s = "I am String";

In the same way, there are aliases for other c# data type as shown below:-

object: System.Object, string: System.String, bool: System.Boolean, byte: System.Byte, sbyte: System.SByte, short: System.Int16 and so on

Now the million-dollar question from programmer's point of view So when to use "String" and "string"?

The first thing to avoid confusion use one of them consistently. But from best practices perspective when you do variable declaration it's good to use "string" ( small "s") and when you are using it as a class name then "String" ( capital "S") is preferred.

In the below code the left-hand side is a variable declaration and it declared using "string". On the right-hand side, we are calling a method so "String" is more sensible.

string s = String.ToUpper() ;
15.01.2014 18:03
But now you have 2 styles in one line? :) by Wouter, 18.02.2021 16:25

Lower case string is an alias for System.String. They are the same in C#.

There's a debate over whether you should use the System types (System.Int32, System.String, etc.) types or the C# aliases (int, string, etc). I personally believe you should use the C# aliases, but that's just my personal preference.

10.08.2008 07:27
That's the problem, they are not 'C#' aliases, they are 'C' aliases. There is no native 'string' or 'int' in the C# language, just syntactic sugar. by Quarkly, 29.05.2015 20:23
not sure where "C" came from here, since C# 5 language specification reads "The keyword string is simply an alias for the predefined class System.String." on page 85, paragraph 4.2.4. All high level languages are syntactic sugar over CPU instruction sets and bytecode. by aiodintsov, 24.02.2016 06:57

string is just an alias for System.String. The compiler will treat them identically.

The only practical difference is the syntax highlighting as you mention, and that you have to write using System if you use String.

18.10.2008 16:50
You don't need to prefix System to use String. by Joe Ratzer, 18.10.2008 19:24
You do have to include a using System when using String, otherwise you get the following error: The type or namespace name 'String' could not be found (are you missing a using directive or an assembly reference?) by Ronald, 16.10.2009 17:53

Both are same. But from coding guidelines perspective it's better to use string instead of String. This is what generally developers use. e.g. instead of using Int32 we use int as int is alias to Int32

FYI “The keyword string is simply an alias for the predefined class System.String.” - C# Language Specification 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

18.10.2008 18:26

As the others are saying, they're the same. StyleCop rules, by default, will enforce you to use string as a C# code style best practice, except when referencing System.String static functions, such as String.Format, String.Join, String.Concat, etc...

19.10.2008 01:15

New answer after 6 years and 5 months (procrastination).

While string is a reserved C# keyword that always has a fixed meaning, String is just an ordinary identifier which could refer to anything. Depending on members of the current type, the current namespace and the applied using directives and their placement, String could be a value or a type distinct from global::System.String.

I shall provide two examples where using directives will not help.

First, when String is a value of the current type (or a local variable):

class MySequence<TElement>
  public IEnumerable<TElement> String { get; set; }

  void Example()
    var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);

The above will not compile because IEnumerable<> does not have a non-static member called Format, and no extension methods apply. In the above case, it may still be possible to use String in other contexts where a type is the only possibility syntactically. For example String local = "Hi mum!"; could be OK (depending on namespace and using directives).

Worse: Saying String.Concat(someSequence) will likely (depending on usings) go to the Linq extension method Enumerable.Concat. It will not go to the static method string.Concat.

Secondly, when String is another type, nested inside the current type:

class MyPiano
  protected class String

  void Example()
    var test1 = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
    String test2 = "Goodbye";

Neither statement in the Example method compiles. Here String is always a piano string, MyPiano.String. No member (static or not) Format exists on it (or is inherited from its base class). And the value "Goodbye" cannot be converted into it.

15.01.2015 14:21

Using System types makes it easier to port between C# and VB.Net, if you are into that sort of thing.

22.09.2008 19:40

Against what seems to be common practice among other programmers, I prefer String over string, just to highlight the fact that String is a reference type, as Jon Skeet mentioned.

31.05.2011 11:20
Good point. If 'string' was not invented, we would not have any confusion and not need this pointless discussion. All our apps would just run fine with String. 'int' seems useful if you don't care about the bit size, which happens most of the time, and 'string' seems only added for consistency. by Roland, 20.04.2021 12:20

string is an alias (or shorthand) of System.String. That means, by typing string we meant System.String. You can read more in think link: 'string' is an alias/shorthand of System.String.

21.10.2011 01:10

I'd just like to add this to lfousts answer, from Ritchers book:

The C# language specification states, “As a matter of style, use of the keyword is favored over use of the complete system type name.” I disagree with the language specification; I prefer to use the FCL type names and completely avoid the primitive type names. In fact, I wish that compilers didn’t even offer the primitive type names and forced developers to use the FCL type names instead. Here are my reasons:

  • I’ve seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used. Similarly, I’ve heard some developers say that int represents a 32-bit integer when the application is running on a 32-bit OS and that it represents a 64-bit integer when the application is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the code is running on. If programmers would use Int32 in their code, then this potential confusion is also eliminated.

  • In C#, long maps to System.Int64, but in a different programming language, long could map to an Int16 or Int32. In fact, C++/CLI does treat long as an Int32. Someone reading source code in one language could easily misinterpret the code’s intention if he or she were used to programming in a different programming language. In fact, most languages won’t even treat long as a keyword and won’t compile code that uses it.

  • The FCL has many methods that have type names as part of their method names. For example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32, ReadSingle, and so on, and the System.Convert type offers methods such as ToBoolean, ToInt32, ToSingle, and so on. Although it’s legal to write the following code, the line with float feels very unnatural to me, and it’s not obvious that the line is correct:

    BinaryReader br = new BinaryReader(...);
    float val = br.ReadSingle(); // OK, but feels unnatural
    Single val = br.ReadSingle(); // OK and feels good
  • Many programmers that use C# exclusively tend to forget that other programming languages can be used against the CLR, and because of this, C#-isms creep into the class library code. For example, Microsoft’s FCL is almost exclusively written in C# and developers on the FCL team have now introduced methods into the library such as Array’s GetLongLength, which returns an Int64 value that is a long in C# but not in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s LongCount method.

I didn't get his opinion before I read the complete paragraph.

28.01.2011 10:08

String (System.String) is a class in the base class library. string (lower case) is a reserved work in C# that is an alias for System.String. Int32 vs int is a similar situation as is Boolean vs. bool. These C# language specific keywords enable you to declare primitives in a style similar to C.

14.01.2012 22:51

It's a matter of convention, really. string just looks more like C/C++ style. The general convention is to use whatever shortcuts your chosen language has provided (int/Int for Int32). This goes for "object" and decimal as well.

Theoretically this could help to port code into some future 64-bit standard in which "int" might mean Int64, but that's not the point, and I would expect any upgrade wizard to change any int references to Int32 anyway just to be safe.

18.08.2008 17:58

String is not a keyword and it can be used as Identifier whereas string is a keyword and cannot be used as Identifier. And in function point of view both are same.

25.04.2011 06:06

Coming late to the party: I use the CLR types 100% of the time (well, except if forced to use the C# type, but I don't remember when the last time that was).

I originally started doing this years ago, as per the CLR books by Ritchie. It made sense to me that all CLR languages ultimately have to be able to support the set of CLR types, so using the CLR types yourself provided clearer, and possibly more "reusable" code.

Now that I've been doing it for years, it's a habit and I like the coloration that VS shows for the CLR types.

The only real downer is that auto-complete uses the C# type, so I end up re-typing automatically generated types to specify the CLR type instead.

Also, now, when I see "int" or "string", it just looks really wrong to me, like I'm looking at 1970's C code.

24.08.2012 15:22

There is no difference.

The C# keyword string maps to the .NET type System.String - it is an alias that keeps to the naming conventions of the language.

Similarly, int maps to System.Int32.

14.01.2012 22:47

@JaredPar (a developer on the C# compiler and prolific SO user!) wrote a great blog post on this issue. I think it is worth sharing here. It is a nice perspective on our subject.

string vs. String is not a style debate


The keyword string has concrete meaning in C#. It is the type System.String which exists in the core runtime assembly. The runtime intrinsically understands this type and provides the capabilities developers expect for strings in .NET. Its presence is so critical to C# that if that type doesn’t exist the compiler will exit before attempting to even parse a line of code. Hence string has a precise, unambiguous meaning in C# code.

The identifier String though has no concrete meaning in C#. It is an identifier that goes through all the name lookup rules as Widget, Student, etc … It could bind to string or it could bind to a type in another assembly entirely whose purposes may be entirely different than string. Worse it could be defined in a way such that code like String s = "hello"; continued to compile.

class TricksterString { 
  void Example() {
    String s = "Hello World"; // Okay but probably not what you expect.

class String {
  public static implicit operator String(string s) => null;

The actual meaning of String will always depend on name resolution. That means it depends on all the source files in the project and all the types defined in all the referenced assemblies. In short it requires quite a bit of context to know what it means.

True that in the vast majority of cases String and string will bind to the same type. But using String still means developers are leaving their program up to interpretation in places where there is only one correct answer. When String does bind to the wrong type it can leave developers debugging for hours, filing bugs on the compiler team, and generally wasting time that could’ve been saved by using string.

Another way to visualize the difference is with this sample:

string s1 = 42; // Errors 100% of the time  
String s2 = 42; // Might error, might not, depends on the code

Many will argue that while this is information technically accurate using String is still fine because it’s exceedingly rare that a codebase would define a type of this name. Or that when String is defined it’s a sign of a bad codebase.


You’ll see that String is defined for a number of completely valid purposes: reflection helpers, serialization libraries, lexers, protocols, etc … For any of these libraries String vs. string has real consequences depending on where the code is used.

So remember when you see the String vs. string debate this is about semantics, not style. Choosing string gives crisp meaning to your codebase. Choosing String isn’t wrong but it’s leaving the door open for surprises in the future.

Note: I copy/pasted most of the blog posts for archive reasons. I ignore some parts, so I recommend skipping and reading the blog post if you can.

11.04.2019 08:39
Glad to find this answer here. There is a difference and it's important. by shoelzer, 07.12.2020 20:58

There's a quote on this issue from Daniel Solis' book.

All the predefined types are mapped directly to underlying .NET types. The C# type names (string) are simply aliases for the .NET types (String or System.String), so using the .NET names works fine syntactically, although this is discouraged. Within a C# program, you should use the C# names rather than the .NET names.

01.11.2013 15:21

Yes, that's no difference between them, just like the bool and Boolean.

08.10.2012 08:22

string is a keyword, and you can't use string as an identifier.

String is not a keyword, and you can use it as an identifier:


string String = "I am a string";

The keyword string is an alias for System.String aside from the keyword issue, the two are exactly equivalent.

 typeof(string) == typeof(String) == typeof(System.String)
11.06.2014 05:26
The only tiny difference is that if you use the String class, you need to import the System namespace on top of your file, whereas you don’t have to do this when using the string keyword. by Uttam, 04.03.2018 09:29
There are simple use-cases where the equality statement would fail... Such as defining a type call String in the blah namespace and importing that namespace into the file in which the equality statement is running. by Rick the Scapegoat, 04.06.2019 13:36

There is no difference between the two - string, however, appears to be the preferred option when considering other developers' source code.

24.08.2011 09:25

One argument not mentioned elsewhere to prefer the pascal case String:

System.String is a reference type, and reference types names are pascal case by convention.

03.10.2012 10:52
-1 All type names are pascal case by convention. But C# keywords are all lowercase. by P Daddy, 23.04.2013 21:14
@PDaddy yes, and string is indeed a C# keyword. The question being asked here is whether to prefer the keyword or the type name. My answer says that, although you can obviously pick the keyword, one argument in favour of using the type name is that they keyword string, which is an alias for the String, is ultimately a reference type.The keyword int, in contrast, is an alias for Int32 which is a value type. by Zaid Masud, 24.04.2013 13:24
The casing conventions don't differ between reference types and value types, as evidenced by the Int32 type you yourself mentioned. It doesn't make sense to eschew the keyword in favor of the class name to abide by some imagined restriction that reference types follow different naming conventions than value types. by P Daddy, 24.04.2013 15:34
@PDaddy yes you are correct. I was carrying over Java conventions here, where primitives are camelCase. by Zaid Masud, 24.04.2013 18:40

Both are the same.The difference is how you use it. Convention is,

string is for variables

String is for calling other String class methods


string fName = "John";
string lName = "Smith";

string fullName = String.Concat(fName,lName);

if (String.IsNullOrEmpty(fName))
  Console.WriteLine("Enter first name");
07.04.2015 10:30
This convention is no more valid: if you use Visual Studio 2015 and try to use String the program suggests you to "simplify your code", carrying it to string. by Massimiliano Kraus, 04.11.2016 14:04

String refers to a string object which comes with various functions for manipulating the contained string.

string refers to a primitive type

In C# they both compile to String but in other languages they do not so you should use String if you want to deal with String objects and string if you want to deal with literals.

04.10.2012 10:37
Care to name these other languages, because I know of none in .net where string != System.String. Also, literal has nothing to do with string vs String... by Andy, 08.10.2016 18:53
Are there really 26 voters who believe this is correct? by Dawood ibn Kareem, 21.02.2019 01:17
@Andy I was working with Java back when I answered this where it does make a difference, not sure if the question specified .net when I answered it as it's been edited since then by Inverted Llama, 21.02.2019 01:36

There is practically no difference

The C# keyword string maps to the .NET type System.String - it is an alias that keeps to the naming conventions of the language.

07.03.2014 13:09

There is one practical difference between string and String.

nameof(String); // compiles
nameof(string); // doesn't compile

This is because string is a keyword (an alias in this case) whereas String is a type.

The same is true for the other aliases as well.

| Alias     | Type             |
|  bool     |  System.Boolean  |
|  byte     |  System.Byte     |
|  sbyte    |  System.SByte    |
|  char     |  System.Char     |
|  decimal  |  System.Decimal  |
|  double   |  System.Double   |
|  float    |  System.Single   |
|  int      |  System.Int32    |
|  uint     |  System.UInt32   |
|  long     |  System.Int64    |
|  ulong    |  System.UInt64   |
|  object   |  System.Object   |
|  short    |  System.Int16    |
|  ushort   |  System.UInt16   |
|  string   |  System.String   |
18.01.2018 13:40
In the end someone able to state an actual difference... you may also add the need for a using System; directive prior to use String type instead of the C# keyword string. This should be the selected answer, or at least a highly voted one. by mins, 20.09.2019 10:32

In case it's useful to really see there is no difference between string and System.String:

var method1 = typeof(MyClass).GetMethod("TestString1").GetMethodBody().GetILAsByteArray();
var method2 = typeof(MyClass).GetMethod("TestString2").GetMethodBody().GetILAsByteArray();


public string TestString1()
    string str = "Hello World!";
    return str;

public string TestString2()
    String str = "Hello World!";
    return str;

Both produce exactly the same IL byte array:

[ 0, 114, 107, 0, 0, 112, 10, 6, 11, 43, 0, 7, 42 ]
01.10.2015 17:43
I've given you a +1, but your actual methods, when optimise+ is on, are identically return "Hello World!";. To actually ensure the types are "considered" you can use return (string)(object)typeof(string).Name; and return (System.String)(System.Object)typeof(System.String).Name;, which happens to confirm System.Object is identical to object too :-) by Mark Hurd, 26.10.2015 09:03

You don't need import namespace (using System;) to use string because it is a global alias of System.String.

To know more about aliases you can check this link.

30.12.2014 13:43

First of All, both(string & String) are not same. There is a difference: String is not a keyword and it can be used as Identifier whereas string is a keyword and cannot be used as Identifier.

I am trying to explain with different example : First, when I put "string s;" into Visual Studio and hover over it I get (without the color):
String Definition

That says that string is System.String, right? The documentation is at https://msdn.microsoft.com/en-us/library/362314fe.aspx. The second sentence says "string is an alias for String in the .NET Framework.".

08.02.2018 08:28
so internally they are the same. meaning, they point to the same thing, and can be used interchangeably. their difference lies in that String is the name of the actual struct as defined, whereas string is an alias which points to that same struct. it (string) being an alias makes it a keyword, which is why VS shows them as difference colors. if you right click to view definition for string, you will be staring at the struct String. by Heriberto Lugo, 14.02.2018 16:13

In C#, string is the short version of System.String (String). They basically mean the same thing.

It's just like bool and Boolean, not much difference..

05.01.2018 19:52

String: A String object is called immutable (read-only) because its value cannot be modified once it has been created. Methods that appear to modify a String object actually return a new String object that contains the modification. If it is necessary to modify the actual contents of a string-like object

string: The string type represents a sequence of zero or more Unicode characters. string is an alias for String in the .NET Framework. string is the intrinsic C# datatype, and is an alias for the system provided type "System.String". The C# specification states that as a matter of style the keyword (string) is preferred over the full system type name (System.String, or String). Although string is a reference type, the equality operators (== and !=) are defined to compare the values of string objects, not references. This makes testing for string equality more intuitive. For example:

Difference between string & String:

  • The string is usually used for declaration while String is used for accessing static string methods
  • You can use 'string' do declare fields, properties etc that use the predefined type 'string', since the C# specification tells me this is good style.
  • You can use 'String' to use system-defined methods, such as String.Compare etc. They are originally defined on 'System.String', not 'string'. 'string' is just an alias in this case.
  • You can also use 'String' or 'System.Int32' when communicating with other system, especially if they are CLR-compliant. i.e. - if I get data from elsewhere, I'd de-serialize it into a System.Int32 rather than an 'int', if the origin by definition was something else than a C# system.
20.05.2014 14:34
Where are you getting this stuff? This is all complete nonsense: String and string are exactly the same thing. by Jay Sullivan, 24.09.2014 14:56
@JaySullivan I'd beg to differ. by Neo, 07.11.2019 00:49

As far as I know, string is just an alias for System.String, and similar aliases exist for bool, object, int... the only subtle difference is that you can use string without a "using System;" directive, while String requires it (otherwise you should specify System.String in full).

About which is the best to use, I guess it's a matter of taste. Personally I prefer string, but I it's not a religious issue.

20.06.2014 03:55

String : Represent a class

string : Represent an alias

It's just a coding convention from microsoft .

11.12.2016 00:38

Jeffrey Richter written:

Another way to think of this is that the C# compiler automatically assumes that you have the following using directives in all of your source code files:

using int = System.Int32;
using uint = System.UInt32;
using string = System.String;

I’ve seen a number of developers confused, not knowing whether to use string or String in their code. Because in C# string (a keyword) maps exactly to System.String (an FCL type), there is no difference and either can be used.

01.02.2018 13:13

To be honest, in practice usually there is not difference between System.String and string.

All types in C# are objects and all derives from System.Object class. One difference is that string is a C# keyword and String you can use as variable name. System.String is conventional .NET name of this type and string is convenient C# name. Here is simple program which presents difference between System.String and string.

string a = new string(new char[] { 'x', 'y', 'z' });
string b = new String(new char[] { 'x', 'y', 'z' });
String c = new string(new char[] { 'x', 'y', 'z' });
String d = new String(new char[] { 'x', 'y', 'z' });
MessageBox.Show((a.GetType() == typeof(String) && a.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((b.GetType() == typeof(String) && b.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((c.GetType() == typeof(String) && c.GetType() == typeof(string)).ToString()); // shows true
MessageBox.Show((d.GetType() == typeof(String) && d.GetType() == typeof(string)).ToString()); // shows true

@JonSkeet in my compiler

public enum Foo : UInt32 { }

is working. I've Visual Studio 2015 Community.

04.06.2016 11:20

string is short name of System.String. String or System.String is name of string in CTS(Common Type System).

12.01.2018 09:19

string is equal to System.String
in VS2015 if you write this

System.String str;

Than compiler will show potential fix to optimize it and after applying that fixe it will look like this

string str;
25.03.2017 05:04

There is no difference between the two. You can use either of them in your code.

System.String is a class (reference type) defined the mscorlib in the namespace System. In other words, System.String is a type in the CLR.

string is a keyword in C#

20.01.2016 10:53

A string is a sequential collection of characters that is used to represent text.

A String object is a sequential collection of System.Char objects that represent a string; a System.Char object corresponds to a UTF-16 code unit.

The value of the String object is the content of the sequential collection of System.Char objects, and that value is immutable (that is, it is read-only).

For more information about the immutability of strings, see the Immutability and the StringBuilder class section in msdn.

The maximum size of a String object in memory is 2GB, or about 1 billion characters.

Note : answer is extracted from msdn help section. You can see the full content here in msdn String Class topic under Remarks section

10.11.2017 11:34

As pointed out, they are the same thing and string is just an alias to String.

For what it's worth, I use string to declare types - variables, properties, return values and parameters. This is consistent with the use of other system types - int, bool, var etc (although Int32 and Boolean are also correct).

I use String when using the static methods on the String class, like String.Split() or String.IsNullOrEmpty(). I feel that this makes more sense because the methods belong to a class, and it is consistent with how I use other static methods.

28.12.2015 09:03