Field vs Property in C#: What’s the Difference and When to Use Each

By the end of this page, you will understand how fields and properties differ in C#, why properties are usually preferred for class design, and when using a field directly is still appropriate. You will also see practical examples, common mistakes, and how this choice appears in real codebases.

In C#, fields and properties both relate to storing or exposing data in a class, but they serve different purposes.

A field is a variable declared directly inside a class or struct. It stores the actual data.

class Person
{
    public string name;
}

Here, name is a field.

A property is a member that provides controlled access to data. It looks like a variable from the outside, but it is actually made of get and/or set accessors.

class Person
{
    public string Name { get; set; }
}

Here, Name is a property.

Why this matters

Properties are important because they support encapsulation. Encapsulation means a class controls how its internal state is accessed and changed.

With a property, you can:

• validate values before storing them
• make a value read-only or write-only
• compute a value instead of storing it directly
• change internal implementation later without changing external code
• trigger side effects such as logging or notifications

A field is simpler, but it exposes raw storage directly if it is public. That can make your code harder to maintain.

Common rule of thumb

• Use properties for data you want other code to access.
• Use fields mostly for private internal storage.

For example:

class Person
{
    private string _name;

    public string Name
    {
        get { return _name; }
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Name cannot be empty.");

            _name = value;
        }
    }
}

In this example:

• _name is a private field that stores the data
• Name is a public property that controls access

This is a very common pattern in C#.

Auto-properties

C# also supports auto-properties, which let you write properties more concisely:

class Person
{
    public string Name { get; set; }
}

This creates a hidden backing field automatically.

When to use a field instead of a property

Use a field when:

• the data is strictly internal to the class
• you do not need validation or access control beyond private
• you want a constant or readonly value
• you are storing the backing data for a property

Example:

class Counter
{
    private int _count;

    public void Increment()
    {
        _count++;
    }

    public int Count => _count;
}

Here _count is a private field because it is internal state. Count is a property because it exposes that state safely.

Public fields are usually discouraged

Public fields are possible:

class Person
{
    public string Name;
}

But this is usually avoided because:

• you cannot easily add validation later without changing the API
• frameworks and tools often expect properties
• it breaks encapsulation
• you lose flexibility for future changes

That is why C# code usually exposes public properties, not public fields.

Think of a field as a box inside an object where data is stored.

Think of a property as a front desk for that box.

• The field is the actual storage room.
• The property is the receptionist that decides what goes in, what comes out, and under what rules.

If someone needs access to your object’s data, it is usually safer to send them through the front desk instead of letting them walk straight into the storage room.

That is why classes often keep fields private and expose properties publicly.

Field syntax

class Product
{
    private decimal _price;
}

This declares a private field named _price.

Property syntax

class Product
{
    public decimal Price { get; set; }
}

This declares an auto-property. C# creates the hidden storage automatically.

Property with validation

class Product
{
    private decimal _price;

    public decimal Price
    {
        get { return _price; }
        set
        {
            if (value < 0)
                throw new ArgumentException("Price cannot be negative.");

            _price = value;
        }
    }
}

This version uses a field to store the data and a property to control access.

Consider this example:

class User
{
    private string _email;

    public string Email
    {
        get { return _email; }
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Email is required.");

            _email = value;
        }
    }
}

User user = new User();
user.Email = "alice@example.com";
Console.WriteLine(user.Email);

Step by step

1. A User object is created.
2. The object contains a private field named _email.
3. The line user.Email = "alice@example.com"; does not write directly to _email.
4. Instead, it calls the property's set accessor.
5. The set accessor checks whether the value is null, empty, or whitespace.
6. Since "alice@example.com" is valid, the code assigns it to .

Where fields are used

Fields are commonly used for:

• private backing storage inside classes
• constants and readonly values
• internal counters or cached values
• dependency references stored by a class

Example:

class EmailService
{
    private readonly ILogger _logger;

    public EmailService(ILogger logger)
    {
        _logger = logger;
    }
}

_logger is a field because it is internal state used by the class.

Where properties are used

Properties are commonly used for:

• exposing model data in APIs
• configuration objects
• DTOs and view models
• settings and options classes
• public object state that other code needs to read or update

Example:

class AppSettings
{
    public string ConnectionString { get; set; }
    public int TimeoutSeconds { get; set; }
}

Many serializers and frameworks work naturally with properties.

In real C# projects, developers usually follow this pattern:

• private fields for internal storage
• public properties for external access

Common patterns

Backing field + property

Used when validation or extra logic is needed.

private string _username;

public string Username
{
    get => _username;
    set
    {
        if (string.IsNullOrWhiteSpace(value))
            throw new ArgumentException("Username is required.");

        _username = value;
    }
}

Auto-property

Used when no custom logic is needed.

public string Title { get; set; }

Read-only property

Used to expose state safely.

public DateTime CreatedAt { get; } = DateTime.UtcNow;

Guard clauses in setters or methods

Validation often happens with guard clauses.

1. Making fields public by default

Broken example:

class Person
{
    public int Age;
}

Problem:

• any code can set Age to an invalid value
• you cannot add validation without changing the API design

Better:

class Person
{
    public int Age { get; set; }
}

Or better with validation:

class Person
{
    private int _age;

    public int Age
    {
        get => _age;
        set
        {
            if (value < 0)
                throw new ArgumentException("Age cannot be negative.");
            _age = value;
        }
    }
}

2. Using a property when a private field is enough

Not every piece of internal state needs a property.

Quick rules

• Field = actual variable inside a class
• Property = controlled access to data
• Prefer private fields and public properties
• Avoid public fields in most class designs

Syntax

Field:

private int _count;

Auto-property:

public int Count { get; set; }

Read-only property:

public int Count { get; }

Expression-bodied property:

public int Area => Width * Height;

Property with backing field:

private int _age;

public int Age
{
    get => _age;
    set
    {
        if ( < )
              ArgumentException();
        _age = ;
    }
}

Should I use a field or property in C#?

Use a property for data that other classes need to access. Use a field mainly for private internal storage.

Are public fields bad in C#?

Not always, but they are usually discouraged in object-oriented design because they expose implementation details and reduce flexibility.

Do auto-properties use fields internally?

Yes. The compiler creates a hidden backing field for an auto-property.

Can a property exist without a field?

Yes. A property can compute its value instead of storing it, such as Area => Width * Height.

Why do frameworks prefer properties over fields?

Many serializers, UI frameworks, and libraries inspect properties for binding, validation, and configuration.

When is a field appropriate in C#?

A field is appropriate for private state, readonly dependencies, constants, and backing storage for properties.

Is a property just a method?

A property is not exactly a method, but it is implemented through accessor methods behind the scenes. It is used with field-like syntax for convenience.

• Encapsulation — Properties are a common tool for hiding internal state and controlling access.
• Access modifiers — public, private, and protected affect how fields and properties can be used.
• Auto-properties — A shorter way to declare simple properties.
• Backing fields — Private fields used to store data for properties with custom logic.
• Getters and setters — The accessors that define how a property is read or written.
• Readonly fields — Useful when data should be assigned once and not changed later.
• Constructors — Often used to initialize readonly fields or get-only properties.
• Classes and objects — Fields and properties are both core members of classes.