<p>Every variable in a Solidity smart contract has a type. That might sound like a trivial detail — just pick one and move on, right? But in a world where storage costs real money (gas), where arithmetic bugs have drained millions, and where a single missing keyword can prevent your contract from sending ETH, data types are one of the most consequential decisions you’ll make.</p>
<p>This post breaks down the Solidity type system from the ground up: what each type does, how the EVM actually stores them, and the mistakes that catch almost everyone off guard.</p>
<hr>
<h2>Think of It Like a Spreadsheet — But Stricter</h2>
<p>In a spreadsheet, columns have formats: one holds numbers, another holds text, another holds checkboxes. You wouldn’t paste a sentence into a number column. Solidity works the same way, except the compiler enforces the rules <em>before deployment</em>, not at runtime when your users’ funds are on the line.</p>
<p>Every variable must declare its type upfront. There’s no auto-detect, no loose typing, no “figure it out later.” The compiler needs to know the exact size and shape of every value so it can allocate storage on the blockchain.</p>
<pre><code>uint256 public totalSupply <span class="hljs-operator">=</span> <span class="hljs-number">1000000</span><span class="hljs-comment">;</span>
address public owner <span class="hljs-operator">=</span> msg.sender<span class="hljs-comment">;</span>
bool public paused <span class="hljs-operator">=</span> false<span class="hljs-comment">;</span>
string public name <span class="hljs-operator">=</span> <span class="hljs-string">&quot;MyToken&quot;</span><span class="hljs-comment">;</span>
</code></pre>
<p>Each line declares the type, visibility, name, and an optional default. The compiler rejects anything that doesn’t match.</p>
<hr>
<h2>The Core Types You’ll Use Constantly</h2>
<p>Here’s a quick reference for the types that show up in virtually every contract:</p>
<h3><code>uint256</code> — The Default Number Type</h3>
<p>Stores a positive whole number from 0 to 2²⁵⁶ − 1 (a number with 78 digits). This is your go-to for token balances, counters, timestamps, and most numeric values. It fits perfectly into the EVM’s native 32-byte (256-bit) word size, which means no wasted space and no conversion overhead.</p>
<h3><code>int256</code> — When You Need Negatives</h3>
<p>Same range as <code>uint256</code>, but split across negative and positive values. Use it for price deltas, signed math, or any value that can go below zero.</p>
<h3><code>address</code> — Ethereum’s Identity Type</h3>
<p>Stores exactly 20 bytes — enough for any Ethereum wallet or contract address. But here’s where it gets interesting: there are <em>two</em> flavors.</p>
<ul>
<li><code>address</code> — Can receive function calls but <em>cannot</em> receive ETH.</li>
<li><code>address payable</code> — Can receive ETH via <code>.transfer()</code> or <code>.send()</code>.</li>
</ul>
<p>This distinction trips up almost everyone. More on that below.</p>
<h3><code>bool</code> — True or False</h3>
<p>Exactly what it sounds like. Used for flags, toggles, paused states. Takes a full 32-byte slot when stored alone (the EVM pads it), so don’t think you’re saving gas by using <code>bool</code> over <code>uint256</code> for a single state variable.</p>
<h3><code>string</code> — Variable-Length Text</h3>
<p>Stores text of any length. But beware: every byte of on-chain storage costs gas. A 1 KB string costs over 640,000 gas to store for the first time. For anything substantial, store data off-chain (IPFS, a database) and keep only the hash or URI on-chain.</p>
<h3><code>bytes32</code> — Fixed Raw Data</h3>
<p>32 bytes of raw data. Perfect for storing hashes (like keccak256 outputs), unique identifiers, and compact data that doesn’t need to be human-readable.</p>
<h3><code>uint8</code> — Small Numbers (0–255)</h3>
<p>The smallest unsigned integer type. Common for decimal values (like a token’s <code>decimals</code> field) and small enums. But it comes with a hidden cost that most people miss entirely.</p>
<hr>
<h2>How the EVM Actually Stores Data</h2>
<p>This is where theory meets money.</p>
<p>The EVM processes everything in <strong>32-byte chunks</strong> called storage slots. A <code>uint256</code> fills one slot perfectly. But here’s the catch that surprises almost every new Solidity developer:</p>
<p><strong>A lone <strong><code>uint8</code></strong> costs exactly the same gas as a <strong><code>uint256</code></strong>.</strong></p>
<p>The EVM pads that tiny 1-byte value to fill the entire 32-byte slot. Worse, operations on <code>uint8</code> actually cost <em>more</em> gas because the EVM has to convert it to <code>uint256</code> internally before performing any arithmetic, then convert it back.</p>
<p>So when does <code>uint8</code> save gas? Only when you <strong>pack multiple smaller types into the same slot</strong>. The EVM can fit up to 32 <code>uint8</code> values into a single storage slot if they’re declared consecutively:</p>
<pre><code><span class="hljs-comment">// These three pack into a single 32-byte slot</span>
<span class="hljs-built_in">uint8</span> <span class="hljs-keyword">public</span> decimals;    <span class="hljs-comment">// 1 byte</span>
<span class="hljs-built_in">uint8</span> <span class="hljs-keyword">public</span> version;     <span class="hljs-comment">// 1 byte</span>
<span class="hljs-built_in">bool</span> <span class="hljs-keyword">public</span> paused;       <span class="hljs-comment">// 1 byte</span>
<span class="hljs-comment">// 29 bytes of the slot still unused</span>

<span class="hljs-comment">// This takes a full 32-byte slot by itself</span>
<span class="hljs-built_in">uint</span>256 <span class="hljs-keyword">public</span> totalSupply;
</code></pre>
<p>The key rule: declare smaller types next to each other in your contract’s state variables or within structs. The Solidity compiler packs consecutive variables into the same slot when they fit.</p>
<hr>
<h2>The <code>address</code> vs <code>address payable</code> Trap</h2>
<p>Since Solidity 0.8, <code>msg.sender</code> returns a plain <code>address</code> — not <code>address payable</code>. This means if your function needs to send ETH back to the caller, this won’t compile:</p>
<pre><code><span class="hljs-comment">// ❌ This fails — msg.sender is not payable</span>
msg<span class="hljs-selector-class">.sender</span><span class="hljs-selector-class">.transfer</span>(amount);
</code></pre>
<p>You need an explicit cast:</p>
<pre><code><span class="hljs-comment">// ✅ This works</span>
<span class="hljs-built_in">payable</span>(msg.sender)<span class="hljs-selector-class">.transfer</span>(amount);
</code></pre>
<p>It seems minor, but missing this distinction is one of the most common mistakes in Solidity development. The compiler will catch it if you forget, but understanding <em>why</em> the two types exist helps you design contracts that handle ETH flows correctly from the start.</p>
<hr>
<h2>Value Types vs Reference Types</h2>
<p>Solidity splits its type system into two categories, and the distinction matters for how you write functions.</p>
<p><strong>Value types</strong> are copied when assigned or passed to functions:</p>
<ul>
<li>Integers (<code>uint256</code>, <code>int256</code>, <code>uint8</code>, etc.)</li>
<li><code>bool</code></li>
<li><code>address</code></li>
<li>Fixed-size byte arrays (<code>bytes32</code>, <code>bytes1</code>, etc.)</li>
</ul>
<p><strong>Reference types</strong> point to data stored elsewhere and require a <strong>data location</strong> annotation (<code>storage</code>, <code>memory</code>, or <code>calldata</code>):</p>
<ul>
<li><code>string</code></li>
<li>Dynamic <code>bytes</code></li>
<li>Arrays (<code>uint256[]</code>, <code>address[]</code>, etc.)</li>
<li>Mappings</li>
<li>Structs</li>
</ul>
<p>If you forget the data location on a reference type, the compiler will tell you. But understanding <em>which</em> location to use affects gas costs and behavior significantly.</p>
<hr>
<h2>Arrays and Mappings: The Workhorses of Contract State</h2>
<h3>Arrays</h3>
<p>Append <code>[]</code> to any type to create a dynamic list. <code>uint256[]</code> is a list of numbers. <code>address[]</code> is a list of wallets. You can <code>push</code>, <code>pop</code>, and access by index.</p>
<pre><code>uint256[] public <span class="hljs-keyword">scores;
</span>
function <span class="hljs-keyword">addScore(uint256 </span><span class="hljs-keyword">score) </span>public {
    <span class="hljs-keyword">scores.push(score);
</span>}
</code></pre>
<h3>Mappings</h3>
<p>A <code>mapping(address =&gt; uint256)</code> creates a key-value lookup — this is exactly how ERC-20 token balances work under the hood:</p>
<pre><code>mapping(address <span class="hljs-operator">=</span>&gt; uint256) public balanceOf<span class="hljs-comment">;</span>
</code></pre>
<p>One critical limitation: <strong>mappings cannot be iterated</strong>. There’s no way to loop over all keys. They only support direct key lookups. If you need to enumerate, maintain a separate array of keys alongside the mapping.</p>
<hr>
<h2>The Overflow Story: Why Solidity 0.8 Was a Big Deal</h2>
<p>Before Solidity 0.8, unsigned integer arithmetic could <strong>silently overflow</strong>. Adding 1 to the maximum <code>uint256</code> value (2²⁵⁶ − 1) would wrap around to 0 without any error. This wasn’t a theoretical concern — it was the root cause of real exploits that drained real funds from production contracts.</p>
<p>The community’s workaround was OpenZeppelin’s <code>SafeMath</code> library, which added overflow checks to every arithmetic operation. But since Solidity 0.8, those checks are <strong>built into the language</strong>. Any overflow or underflow now automatically reverts the transaction.</p>
<p>This doesn’t mean you can be careless, though. If you declare a <code>uint8</code> for a counter that could exceed 255, your transaction will revert. The overflow protection saves you from silent corruption, but choosing the right-sized type still matters.</p>
<hr>
<h2>Common Mistakes (And How to Avoid Them)</h2>
<h3>1. Using <code>uint8</code> to “save gas” on a standalone variable</h3>
<p>It doesn’t. A single <code>uint8</code> state variable takes the same 32-byte slot as a <code>uint256</code>, with <em>extra</em> conversion overhead. Only use smaller types when you can pack multiples into one slot.</p>
<h3>2. Choosing a type too small for your data</h3>
<p>If a <code>uint8</code> counter hits 256, the transaction reverts. When in doubt, use <code>uint256</code>. Storage cost is identical for a standalone variable.</p>
<h3>3. Storing large text on-chain</h3>
<p>Every 32 bytes of on-chain storage costs ~20,000 gas on a fresh write. A 1 KB string burns through 640,000+ gas. Store large data off-chain and reference it by hash or URI.</p>
<h3>4. Forgetting <code>address payable</code></h3>
<p>If your contract sends ETH, the destination must be <code>address payable</code>. Since <code>msg.sender</code> defaults to plain <code>address</code> in 0.8+, you need the explicit <code>payable()</code> cast.</p>
<hr>
<h2>TL;DR</h2>
<ul>
<li><code>uint256</code> is your default number type — it matches the EVM’s native word size and costs the same as smaller types when stored alone.</li>
<li><code>address</code>** vs **<code>address payable</code> matters — one can receive ETH, the other can’t.</li>
<li>**Small types like **<code>uint8</code> only save gas when packed together; alone they cost more.</li>
<li><strong>Solidity 0.8+</strong> prevents overflow silently, but you still need types large enough for your data.</li>
<li><strong>Strings and dynamic data</strong> are expensive on-chain — keep hashes on-chain, data off-chain.</li>
</ul>
<p>Data types aren’t glamorous, but they’re the foundation. Every gas optimization, every security property, and every ETH transfer in your contract flows through the type system. Get them right early and everything downstream gets easier.</p>
<hr>
<p><em>This post was inspired by <a href="https://doodledapp.com/feed/solidity-data-types-explained" target="_blank" rel="noopener nofollow">this article from Doodledapp</a>, a visual smart contract builder for Solidity. If you’re a non-developer building on Ethereum, their tool lets you pick types from plain-language dropdowns instead of writing raw Solidity — worth checking out.</em></p>


Solidity data types you really need to know more about