Const vs Readonly in C#: What's the Difference and When to Use Each

By the end of this page, you will understand how const and readonly work in C#, when their values are assigned, what kinds of values they can store, and which one to choose in real projects.

const and readonly both help you create values that should not be changed, but they are not the same.

const

A const field is a compile-time constant.

That means:

• Its value must be known when the code is compiled.
• You must assign it immediately where it is declared.
• Its value can never change.
• It is implicitly static, so it belongs to the type itself, not to each object.

Example:

public class AppSettings
{
    public const int MaxUsers = 100;
}

100 is known at compile time, so it works as a const.

readonly

A readonly field is a value that can be assigned only during initialization or in a constructor.

That means:

• The value does not need to be known at compile time.
• It can be different for each object.
• It can be set when the object is created.
• It can also be static readonly if you want one shared value for the whole type.

Example:

Think of const as text printed directly into every copy of a document before it is distributed.

• The value is decided once during printing.
• It cannot depend on anything that happens later.
• Every reader sees the exact same printed value.

Think of readonly as filling in a form when each object is created.

• You can decide the value at creation time.
• After the form is filled out, it cannot be changed.
• Different objects can have different values.

So:

• const = printed into the program at compile time
• readonly = assigned once at initialization/runtime, then locked

Core syntax

const

public class MathValues
{
    public const double Pi = 3.14159;
}

Rules:

• Must be assigned at declaration
• Must use a compile-time constant value
• Is automatically static

readonly

public class Config
{
    public readonly string EnvironmentName;

    public Config(string environmentName)
    {
        EnvironmentName = environmentName;
    }
}

Rules:

• Can be assigned at declaration, or
• Can be assigned inside the constructor
• Cannot be reassigned later

Example: const for a fixed application value

  
{
       NotFound = ;
}

Consider this code:

public class Example
{
    public const int FixedValue = 10;
    public readonly int InstanceValue;

    public Example(int value)
    {
        InstanceValue = value;
    }
}

var a = new Example(5);
var b = new Example(9);

Here is what happens step by step:

1. The compiler sees FixedValue and stores 10 as a compile-time constant.
2. FixedValue belongs to the class itself, not to objects a or b.
3. When new Example(5) runs, the constructor is called.
4. Inside the constructor, InstanceValue is assigned 5.

When const is useful

Use const for values that are truly fixed forever, such as:

• mathematical values used in your code
• unit conversion values
• fixed application labels
• known protocol values that will not change

Example:

public class Units
{
    public const int DaysPerWeek = 7;
}

When readonly is useful

Use readonly when the value should stay the same after creation, but is determined at runtime.

Common examples:

• timestamps like CreatedAt
• IDs passed into constructors
• file paths built from environment settings
• dependency objects assigned once
• configuration loaded at startup

Example:

public class ConnectionInfo
{
    public readonly string ConnectionString;

    
    {
        ConnectionString = connectionString;
    }
}

In real C# codebases, developers often follow these patterns:

1. const for true constants only

public class ErrorCodes
{
    public const string InvalidInput = "INVALID_INPUT";
}

This is common for:

• hardcoded error codes
• fixed names
• small immutable primitive values

2. readonly for object state that should not change

public class Order
{
    public readonly Guid Id;

    public Order(Guid id)
    {
        Id = id;
    }
}

This protects object state after construction.

3. static readonly for shared runtime-initialized values

public class Defaults
{
    public static  DateTime AppStartedAt = DateTime.Now;
}

1. Trying to use runtime values in a const

Broken code:

public class Example
{
    public const DateTime Start = DateTime.Now;
}

Why it fails:

• DateTime.Now is not a compile-time constant.

Fix:

public class Example
{
    public static readonly DateTime Start = DateTime.Now;
}

2. Forgetting that const is implicitly static

Broken assumption:

public class Product
{
    public const int TaxRate = 20;
}

You do not get a separate TaxRate for each object. There is only one value for the type.

3. Thinking makes an object fully immutable

Quick rules

• const = compile-time constant
• readonly = assign once at declaration or in constructor
• static readonly = one shared runtime-initialized value

Syntax

public const int Max = 10;
public readonly int Id;
public static readonly string BasePath = AppDomain.CurrentDomain.BaseDirectory;

Use const when

• value is known at compile time
• value will never change
• value is a true constant like 7, 404, or "GET"

Use readonly when

• value is known only at runtime
• value should not change after object creation
• value may be different for each instance

Important notes

• is implicitly

Can const be used with DateTime in C#?

No. DateTime values like DateTime.Now are not compile-time constants. Use readonly or static readonly instead.

Is const always static in C#?

Yes. A const field is implicitly static, so it belongs to the type, not to individual objects.

Can a readonly field be different for each object?

Yes. Because it can be assigned in the constructor, each instance can receive a different value.

Which is faster: const or readonly?

In most application code, the performance difference is not important. Choose based on meaning and correctness, not micro-optimization.

Should I use const for public values in a shared library?

Usually only if the value will never change. Otherwise public static readonly is often safer because of compile-time inlining of const values.

• static — Related because const is implicitly static, and static readonly is a common alternative.
• immutability — Related because both const and readonly help prevent unwanted changes.
• constructors — Related because readonly fields can be assigned inside constructors.
• fields vs properties — Related because const and readonly apply to fields, while properties use different patterns.
• access modifiers — Related because public, private, and other modifiers affect how constants and readonly fields are exposed.
• compile-time vs runtime — Related because this is the core distinction between const and readonly.
• static readonly — Related because it is often the practical replacement for const when a value is only known at runtime.
• readonly properties — Related because properties with only a getter provide another way to model immutable data.