Visibility in Solidity

Solidity gives you four visibility modifiers: public, private, internal, and external. They control which code can call a function or read a state variable. Getting them wrong either locks down functionality that should be open, or exposes internals that should stay hidden.

This post explains what each modifier does, where it applies, how it interacts with inheritance, and when to reach for each one.

---

The Four Modifiers at a Glance

Modifier	State variables	Functions	Who can access
public	Yes	Yes	Anyone, anywhere
private	Yes	Yes	Current contract only
internal	Yes (default)	Yes	Current contract and derived contracts
external	No	Yes	Outside callers only

external cannot be used on state variables. Attempting it will cause a compile error.

---

State Variable Visibility

public

Declaring a state variable public tells the compiler to generate a getter function automatically. External callers use that getter to read the value. You do not write it yourself.

1contract VisibilityExample {
2    uint256 public myNumber = 42;
3    // Compiler generates: function myNumber() public view returns (uint256)
4}

Any external contract or wallet can call myNumber() and get back 42. This is clean and convenient, but only declare variables public if you actually want them readable by anyone.

private

A private variable can only be accessed by functions inside the same contract. Derived contracts cannot read it, even though they inherit from the same base.

 1contract MyContract {
 2    uint256 private secretValue = 100;
 3
 4    function revealSecret() public view returns (uint256) {
 5        return secretValue; // allowed
 6    }
 7}
 8
 9contract ChildContract is MyContract {
10    function tryAccess() public view returns (uint256) {
11        // return secretValue; // compile error
12        return 0;
13    }
14}

private does not hide data from the blockchain. All storage slots are publicly readable by anyone who queries the chain directly. private only prevents other Solidity contracts from referencing the variable by name. Never store sensitive data on-chain and assume private protects it.

internal

internal is the default visibility for state variables. If you declare a variable without specifying visibility, Solidity treats it as internal. The variable is accessible within the contract and within any contract that inherits from it.

 1contract Parent {
 2    uint256 internal familySecret = 500;
 3}
 4
 5contract Child is Parent {
 6    function read() public view returns (uint256) {
 7        return familySecret; // allowed
 8    }
 9}

Prefer writing internal explicitly rather than relying on the default. It makes intent clear.

---

Function Visibility

public

A public function can be called from inside the contract or from outside. It is the most flexible option, but it has a cost: when called internally, Solidity copies function arguments into memory. For small inputs this does not matter, but for large arrays it adds unnecessary gas overhead.

 1contract Calculator {
 2    function add(uint256 a, uint256 b) public pure returns (uint256) {
 3        return a + b;
 4    }
 5
 6    function calculate() public pure returns (uint256) {
 7        return add(10, 20); // internal call to public function
 8    }
 9}

external

An external function can only be called from outside the contract. You cannot call it directly by name from within the same contract. Calling it internally requires this.functionName(), which creates an external call and costs significantly more gas.

 1contract DataProcessor {
 2    function processData(uint256[] calldata data) external pure returns (uint256) {
 3        return data.length;
 4    }
 5
 6    function internalProcess() public pure returns (uint256) {
 7        uint256[] memory testData = new uint256[](3);
 8        // return processData(testData); // compile error
 9        return this.processData(testData); // works, but expensive
10    }
11}

The main advantage of external is that it allows calldata for array parameters. calldata is read directly from the transaction input without copying, which is cheaper than loading into memory. If a function only ever gets called from outside and accepts large arrays, external with calldata is the correct choice.

internal

An internal function is accessible within the contract and in any contract that inherits from it. It is never part of the contract's ABI, so no external caller can invoke it.

 1contract Math {
 2    function multiply(uint256 a, uint256 b) internal pure returns (uint256) {
 3        return a * b;
 4    }
 5
 6    function square(uint256 x) public pure returns (uint256) {
 7        return multiply(x, x);
 8    }
 9}
10
11contract AdvancedMath is Math {
12    function cube(uint256 x) public pure returns (uint256) {
13        return multiply(x, multiply(x, x)); // inherited, accessible
14    }
15}

Use internal for helper functions that child contracts may need to reuse. It avoids duplicating logic while keeping the function off the public interface.

private

A private function works the same as internal within the current contract, but derived contracts cannot call it at all.

 1contract Secure {
 2    uint256 private counter;
 3
 4    function incrementCounter() private {
 5        counter++;
 6    }
 7
 8    function doSomething() public {
 9        incrementCounter(); // allowed
10    }
11}
12
13contract Extended is Secure {
14    function tryIncrement() public {
15        // incrementCounter(); // compile error
16    }
17}

Use private when a function is a low-level implementation detail that should never be part of an inheritance interface.

---

Visibility Across Inheritance

This example shows all four modifiers in one inheritance scenario:

 1contract Base {
 2    uint256 public publicVar = 1;
 3    uint256 internal internalVar = 2;
 4    uint256 private privateVar = 3;
 5
 6    function publicFunc() public pure returns (string memory) {
 7        return "public";
 8    }
 9
10    function internalFunc() internal pure returns (string memory) {
11        return "internal";
12    }
13
14    function privateFunc() private pure returns (string memory) {
15        return "private";
16    }
17}
18
19contract Derived is Base {
20    function testAccess() public view returns (uint256) {
21        uint256 sum = publicVar + internalVar; // both accessible
22        // uint256 bad = privateVar;           // compile error
23
24        publicFunc();   // accessible
25        internalFunc(); // accessible
26        // privateFunc(); // compile error
27
28        return sum;
29    }
30}

Derived contracts inherit public and internal members. They never get access to private members. This is a hard boundary enforced at compile time.

---

Practical Guidelines

Default to the most restrictive option. Start with private. Move to internal if child contracts need access. Move to public or external only if outside callers need it.

Use external for functions that only serve outside callers. Especially if those functions accept array parameters. The calldata keyword saves gas and external makes the intent explicit.

Use internal for shared helpers in a contract family. It is cleaner than duplicating logic or making everything public.

Do not treat private as encryption. All on-chain state is readable. Use private for access control at the Solidity level, not for data confidentiality.

Let the compiler generate getters. Public state variables get their getter for free. Only write a custom getter if you need to transform or filter the output.

---

Common Mistakes

 1contract Mistakes {
 2    // Mistake 1: public when internal would work
 3    // Nothing outside this contract reads helperValue
 4    uint256 public helperValue;
 5
 6    // Mistake 2: public when external would work
 7    // This function is never called internally
 8    // Switching to external with calldata saves gas
 9    function processArray(uint256[] memory data) public pure returns (uint256) {
10        return data.length;
11    }
12
13    // Mistake 3: missing visibility on a function
14    // Default for functions is internal, not public
15    // This function is not callable externally
16    function oops() pure returns (uint256) {
17        return 42;
18    }
19}

The third mistake is subtle. State variables default to internal, but functions also default to internal if you omit the modifier. A function without visibility is invisible to external callers, which may not be what you intended. Always write visibility explicitly on functions.

---

Visibility and Attack Surface

Every public or external function is an entry point into your contract. Unnecessary exposure increases the number of ways an attacker can interact with your code.

 1contract SecureExample {
 2    mapping(address => uint256) private balances;
 3
 4    function deposit() external payable {
 5        balances[msg.sender] += msg.value;
 6    }
 7
 8    // Private: only used internally, not part of the ABI
 9    function updateBalance(address user, uint256 amount) private {
10        balances[user] = amount;
11    }
12
13    // External: read-only, only exposes the caller's own balance
14    function getBalance() external view returns (uint256) {
15        return balances[msg.sender];
16    }
17}

The balances mapping is private. The updateBalance helper is private. The only entry points are deposit and getBalance. This is the smallest possible attack surface for this functionality.

Keeping functions private or internal until you have a reason to expose them is a habit that pays off in audit findings and in production.

---

Visibility modifiers are straightforward once you understand what each one controls. The rule is simple: expose only what needs to be exposed, and be explicit about every choice. A contract where every variable and function has a deliberate visibility modifier is easier to audit, easier to extend, and harder to exploit.