Remix IDE Cheatsheet
Debugging
Use this Remix IDE reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
Opening the Debugger
Two ways to start:
- Terminal — after any transaction, click the Debug button in its log row.
- Debugger plugin — click the bug icon in the left icon bar, paste a transaction hash, click Start Debugging.
The debugger only works on transactions executed in the current session (VM) or against a node that supports debug_traceTransaction (local Hardhat/Anvil, some testnets via Tenderly).
Debugger UI Panels
| Panel | Content |
|---|---|
| Navigation controls | Step Into / Over / Back / Jump to error |
| Slider | Drag to any step in the execution trace |
| Solidity Locals | Local variable values at current step |
| Solidity State | Contract storage variables at current step |
| Call Stack | Function call hierarchy |
| Opcodes | EVM opcode at cursor, with stack/memory |
| Stack | Raw EVM stack values |
| Memory | Raw memory (hex) |
| Storage | Full storage layout at current step |
| Return Value | Output of the call being debugged |
Setting Breakpoints
- Open the source file in the editor.
- Click the gutter (left margin) next to a line number — a red dot appears.
- Press Play in the debugger — execution pauses at that line.
Remove a breakpoint by clicking the red dot again.
Reading Solidity Locals
The Solidity Locals panel shows named variables as the Solidity compiler maps them to the EVM, for example:
amount uint256 1000000000000000000 to address 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2 success bool true
Variable values are only available if the contract was compiled without heavy optimization (high runs count can inline / remove variables).
Identifying a Revert
- Click Debug on a failed transaction (red
✗in terminal). - Click Jump to error (⏭) — the debugger lands on the failing opcode (
REVERT). - Check Solidity Locals and Call Stack to see what triggered it.
- The Return Value panel shows the revert reason string if one was provided.
require(balance >= amount, "Insufficient balance"); // Debugger will land here and show reason: "Insufficient balance"
Inspecting Storage at a Step
The Storage panel shows the full slot layout at the current execution step — useful for tracking storage corruption bugs.
| Slot | Key | Value |
|---|---|---|
0x00 | totalSupply | 1000000 |
0x01 | balances[0xAb8...] | 500000 |
Debugging with console.log
hardhat/console.sol works directly in the Remix VM — no local node needed. Import it, deploy in any Remix VM environment, and console.log output prints straight into the Remix terminal with each transaction.
When connected to a local Hardhat or Anvil node instead, the same statements print to the node's own terminal (not Remix) — switch to your CLI to read the output.
import "hardhat/console.sol"; function transfer(address to, uint256 amount) external { console.log("Transferring", amount, "to", to); // ... }
Common Debug Scenarios
| Symptom | What to look for |
|---|---|
| Transaction reverts with no reason | Jump to error → check require / assert that lacks a message |
| Wrong return value | Step through and watch Solidity Locals change |
| Unexpected storage state | Check Storage panel step-by-step across a loop |
| Out-of-gas | Opcode panel shows STOP at gas = 0; identify expensive loop |
| Reentrancy | Call Stack shows recursive entries of the same function |
Tenderly Integration (Testnet Debugging)
For testnet transactions:
- Install the Tenderly plugin from the Plugin Manager.
- Authenticate with a Tenderly account.
- Paste a Sepolia (or other supported testnet) tx hash — Tenderly provides a full step-through debugger with named variables, even for already-mined transactions.