If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone.If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone.

Memory, Calldata, and Storage in Solidity: Understanding the Differences

6 min read

:::warning DISCLAIMER:

  • The code in this article is for educational purposes only.

:::

If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone. This is an area most beginner developers struggle to grasp, and even some experienced Solidity developers still don’t fully understand.

What are these ‘special words’? They are words that specify the main data locations in a Solidity smart contract. Data locations in Solidity describe where data can be stored and how it can be accessed on the Ethereum blockchain. Other data locations include the following:

  • Stack
  • Code
  • Logs

In this article, you will learn the differences between each main data location option and where to use each.

Firstly, what is storage?

Storage

Storage is the data location that holds a smart contract’s state variables. A state variable is data that lives permanently on the blockchain. Each smart contract has its own storage space (an array of 2^256 32-byte slots), and state variables are automatically assigned to storage.

The code snippet below shows a simple implementation of a state variable stored in storage, as well as its getter and setter functions: \n

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Storage {     /////////////////////////////     // STATE VARIABLES //////////     /////////////////////////////     uint256 public s_storedData; // s_storedData is a storage variable, s_ denotes a storage variable     /////////////////////////////     // SETTER FUNCTION //////////     /////////////////////////////     function set(uint256 x) public {         s_storedData = x; // This value is saved permanently on-chain     }     /////////////////////////////     // GETTER FUNCTION //////////     /////////////////////////////     function getStoredData() public view returns(uint256) {         return s_storedData;     } } 

In the code above, the  s_storedData remains on the blockchain after the set() function runs.

More importantly, storage is one of the major data location options that isn’t explicitly specified. Any variable declared outside any function is implicitly converted to a storage variable.

Use-case

The Bank contract above acts as a simple bank, as the name implies. The balancesmapping is stored in storage, which means it remembers values across function calls.

For instance, if Alice calls deposit(100), her balance is saved in storage in the balances mapping. Conversely, if she calls withdraw(60), she receives 60 and the mapping updates to 40.

Memory

Unlike Storage, Memory is a temporary, function-scope data location. Function-scope means, variables exist only during a function call, not at the contract-level, and clears afterwards. Additionally, memory allows for read-write access; this means variables are modified within a function. Solidity allocates memory to variables defined inside a function(local variables) or parameters marked memory.

To demonstrate:

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 a, uint256 b) public pure returns (uint256) {         uint256 result = a * b; // 'result' is stored in memory         return result; // 'result' does NOT persist after the function ends     } } 

In the code above, Solidity implicitly stores result in memory, which does not persist after the function execution.

Use-case

The code below concatenates two string inputs, string memory first, string memory second exist while the function combineStrings runs.

A note on function parameters

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 memory a, uint256 memory b) public pure returns (uint256) {         uint256 result = a * b;         return result;      } } 

For function parameters, you can’t specify the memorykeyword for uint, bool, addressand enum variables as they are directly stored on the contract’s stack, no explicit keyword.

Whereas for reference types like strings, bytes, arrays, structs, and mapping, you will have to specify or defaults to memory for internal and private functions and calldata for external and public functions(more on this below👇).

Calldata

Lightly touched on in the previous section, calldata is another temporary data location, but it’s reserved for external function parameters.  Also, unlike memory, calldata cannot be modified. To explain what this means, let’s take a look at the code below:

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example {     function tryChangeCalldata(uint[] calldata nums) external pure returns (uint[] calldata) {         nums[0] = 999; // ❌ ERROR — "calldata is read-only"         return nums;     } } 

The error message above shows that calldata is read-only. To modify calldata variables, they must first be loaded into memory.

Take the adjusted code below now modified .The code below works because the it loads nums variable to memory before modifying it in the if block.

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example { &nbsp; &nbsp; function tryChangeCalldata(uint[] calldata nums)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; external&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pure&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; returns (uint[] memory)&nbsp; &nbsp; &nbsp; { &nbsp; &nbsp; &nbsp; &nbsp; // Copy from calldata to memory &nbsp; &nbsp; &nbsp; &nbsp; uint[] memory numsCopy = new uint[](nums.length); &nbsp; &nbsp; &nbsp; &nbsp; for (uint i = 0; i < nums.length; i++) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[i] = nums[i]; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; // Now modify the copy &nbsp; &nbsp; &nbsp; &nbsp; if (numsCopy.length > 0) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[0] = 999; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; return numsCopy; &nbsp; &nbsp; } } 

\

Why Data Locations Matter

Using appropriate data locations matters as they directly affect how your contracts store, access, and pay for data. The differences can have a large impact on cost, behaviour, and security of your smart contracts. Here’s how:

Gas Costs

  • Writing data to Storage is the most expensive.
  • The gas costs in Memory is more moderate than storage.
  • Calldata is the cheapest data location, i.e., writing to calldata costs the least amount of gas.

Persistence and Temporariness

  • Any data written to Storage lives onchain, meaning the data is permanent.
  • Memory only persists during the function’s lifecycle.
  • Calldata acts like memory in handling data, only it can’t be changed.

Mutability

  • Storage data can be modified.
  • Similar to Storage, Memory can be modified but only within the context of a function.
  • Calldata is read-only.

Safety

  • Storage can be a risky choice of location because mistakes or hacks can permanently change the blockchain’s state.
  • Memory is a safer option since changes are temporary.
  • Calldata is the safest for passing input for external functions.

Wrapping Up

That’s it for this piece, as previously stated, using the appropriate data locations is integral to the functionality of your contracts. I implore you to research further about the other types of data locations mentioned in the introduction of this article.

Happy Hacking!!

Market Opportunity
Notcoin Logo
Notcoin Price(NOT)
$0.0004477
$0.0004477$0.0004477
+1.35%
USD
Notcoin (NOT) Live Price Chart
Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

CEO Sandeep Nailwal Shared Highlights About RWA on Polygon

CEO Sandeep Nailwal Shared Highlights About RWA on Polygon

The post CEO Sandeep Nailwal Shared Highlights About RWA on Polygon appeared on BitcoinEthereumNews.com. Polygon CEO Sandeep Nailwal highlighted Polygon’s lead in global bonds, Spiko US T-Bill, and Spiko Euro T-Bill. Polygon published an X post to share that its roadmap to GigaGas was still scaling. Sentiments around POL price were last seen to be bearish. Polygon CEO Sandeep Nailwal shared key pointers from the Dune and RWA.xyz report. These pertain to highlights about RWA on Polygon. Simultaneously, Polygon underlined its roadmap towards GigaGas. Sentiments around POL price were last seen fumbling under bearish emotions. Polygon CEO Sandeep Nailwal on Polygon RWA CEO Sandeep Nailwal highlighted three key points from the Dune and RWA.xyz report. The Chief Executive of Polygon maintained that Polygon PoS was hosting RWA TVL worth $1.13 billion across 269 assets plus 2,900 holders. Nailwal confirmed from the report that RWA was happening on Polygon. The Dune and https://t.co/W6WSFlHoQF report on RWA is out and it shows that RWA is happening on Polygon. Here are a few highlights: – Leading in Global Bonds: Polygon holds 62% share of tokenized global bonds (driven by Spiko’s euro MMF and Cashlink euro issues) – Spiko U.S.… — Sandeep | CEO, Polygon Foundation (※,※) (@sandeepnailwal) September 17, 2025 The X post published by Polygon CEO Sandeep Nailwal underlined that the ecosystem was leading in global bonds by holding a 62% share of tokenized global bonds. He further highlighted that Polygon was leading with Spiko US T-Bill at approximately 29% share of TVL along with Ethereum, adding that the ecosystem had more than 50% share in the number of holders. Finally, Sandeep highlighted from the report that there was a strong adoption for Spiko Euro T-Bill with 38% share of TVL. He added that 68% of returns were on Polygon across all the chains. Polygon Roadmap to GigaGas In a different update from Polygon, the community…
Share
BitcoinEthereumNews2025/09/18 01:10
TRM Labs Becomes Unicorn with 70M$: BTC Fraud Risk

TRM Labs Becomes Unicorn with 70M$: BTC Fraud Risk

The post TRM Labs Becomes Unicorn with 70M$: BTC Fraud Risk appeared on BitcoinEthereumNews.com. TRM Labs Reaches 1 Billion Dollar Valuation Blockchain intelligence
Share
BitcoinEthereumNews2026/02/05 03:33
XRP Plunges: Historic MACD Signal Sparks Alarm

XRP Plunges: Historic MACD Signal Sparks Alarm

This week, XRP depreciated by 17.94 per cent with a historic MACD indicator sitting on the market; the traders are keeping a keen eye on the support mark of 1.30
Share
LiveBitcoinNews2026/02/05 03:30