Introduction

In C#, protected and protected internal both expose members beyond the declaring class, but they do not expose them to the same audience. protected is inheritance-based access, while protected internal is broader and allows access either through inheritance or from any code in the same assembly.

protected Means the Inheritance Chain

A protected member can be used inside the class that declares it and inside derived classes. Unrelated classes cannot access it directly, even if they live in the same project.

1using System;
2
3public class Base
4{
5    protected int Counter = 10;
6}
7
8public class Derived : Base
9{
10    public void PrintCounter()
11    {
12        Console.WriteLine(Counter);
13    }
14}
15
16public class Program
17{
18    public static void Main()
19    {
20        var item = new Derived();
21        item.PrintCounter();
22    }
23}

This compiles because Derived inherits from Base. If you tried to read Counter from a non-derived helper class, the compiler would reject it.

protected internal Means Same Assembly OR Derived Type

The phrase protected internal is easy to misread. It does not mean "accessible only when code is both protected and internal." In C#, it means access is granted when either condition is true:

• The code is in a derived class.
• The code is in the same assembly.

That makes it wider than plain protected.

1using System;
2
3public class Base
4{
5    protected internal int Counter = 10;
6}
7
8public class NonDerived
9{
10    public void Print(Base value)
11    {
12        Console.WriteLine(value.Counter);
13    }
14}

If NonDerived is compiled into the same assembly, this works even though NonDerived does not inherit from Base. That is the core difference.

Think in Terms of Design Boundaries

The useful question is not "which modifier is more convenient right now?" It is "who should be allowed to depend on this member?"

Choose protected when the member exists for subclasses that extend the type's behavior. Choose protected internal when you also want same-assembly collaborators to use that member directly.

This is common in frameworks where the library assembly contains helper types, factories, or infrastructure that must coordinate closely with the base type. The tradeoff is tighter coupling inside the assembly. Once many unrelated classes can touch the member, it becomes harder to change later.

Compare It with private protected

C# also offers private protected, which is narrower. It allows access only from derived classes inside the same assembly. That gives you a useful spectrum:

• 'protected: derived classes anywhere'
• 'protected internal: derived classes anywhere or same-assembly code'
• 'private protected: derived classes in the same assembly only'

That comparison helps expose why protected internal is often misunderstood. It is the most permissive of the three in many real codebases.

Common Pitfalls

The most common mistake is assuming protected internal behaves like a restrictive combination of two keywords. In practice it is broader because the access rule is based on or.

Another issue is using protected internal when plain protected would have preserved a cleaner API boundary. Broader access feels convenient during implementation and becomes costly during maintenance.

Developers also sometimes forget the assembly part entirely and are surprised when a non-derived type in the same assembly can access the member.

Summary

• 'protected allows access from the declaring class and derived classes.'
• 'protected internal allows access from derived classes or from any code in the same assembly.'
• The important difference is same-assembly access for non-derived types.
• 'private protected is narrower and should not be confused with protected internal.'
• Prefer the narrowest modifier that still matches the intended design boundary.