Solidity REPL
SOLIDITY REPL DOCUMENTATION

Everything you need to investigate Solidity.

Solidity REPL accepts loose expressions, normal contracts, local files, and fixed-block RPC forks. Build an investigation one entry at a time, see each result in place, and open deeper controls only when you need them.

01

Quick start

Type Solidity in the composer below the transcript. Press⌘ Enter on macOS or Ctrl Enter elsewhere to commit it as an entry and run it. The result appears directly under that entry.

uint256 amount = 1 ether

amount * 7 / 100

keccak256("hello")

These can be three separate entries. The second entry can use amount because accepted declarations, functions, structs, and contracts remain available to later entries. Normal line breaks create multiline input.

Try basic arithmetic
02

How a run works

Solidity REPL is a browser compiler and EVM runner with a transcript in front of it. It does not interpret a Solidity-like language. Every successful answer comes from the selected Solidity compiler and an EVM execution.

1. AssembleREPL entries are joined into one document. The active document, imports, and browser files form a compilation unit, and loose statements are placed in a generated runner.
2. CompileThe exact compiler, EVM target, optimizer, and via-IR settings saved in the session produce bytecode, ABI, and source mappings in a worker.
3. ExecuteThe runner executes in an in-browser EthereumJS EVM. Local starts from local state; Fork resolves missing account and storage data through the configured RPC.
4. ObserveReturn values, reverts, logs, nested calls, storage writes, gas, and optional opcode steps are captured from that run.
5. CommitIn REPL mode, a candidate becomes accepted history only after the complete history compiles and executes. A failed candidate remains an editable attempt.

Compiler startup

The compiler begins loading when the editor receives focus, when the browser becomes idle, or when you select Run. If Run comes first, Solidity REPL queues it and starts automatically when the compiler is ready. A compiler release that is not cached must be downloaded before that first run.

What makes a replay reproducible

A session pins its compiler and settings, accepted input, local files, and execution context. A fork also pins the block after its first successful run. Keep those inputs unchanged and a clean replay asks the same EVM question again. Historical fork replay still depends on an RPC provider that can serve the pinned block.

Generated replay source is an inspectable build artifact. The session JSON is the portable record because it preserves entry boundaries, rejected attempts, settings, files, and context.
03

Choose REPL or Source mode

Both modes use the same compiler, EVM, files, execution controls, and inspection data. The difference is how source and state evolve between runs.

REPLBest for a sequence of small questions. Each accepted entry joins the visible history, and every change replays that history from a clean configured environment. Results stay beside the entry that produced them.
SourceBest for a complete contract or generated replay source. The editor owns one full document and Run details stays beside it. Keep EVM state can make one manual run continue from the previous run.
InspectREPL opens details temporarily in a drawer. Source keeps the same categories in a permanent panel: Values, Logs, Calls, State, and Debug appear when the run produces them.
Move between themOpening Source preserves the transcript and exposes its complete generated document. Returning to REPL validates edited source and, on success, converts it into one accepted entry.
Use REPL when visible history is part of the evidence. Use Source with Keep EVM state when the experiment specifically depends on hidden state accumulating between manual runs.
04

The REPL transcript

Every committed fragment becomes a numbered transcript entry. Values and errors stay attached to the entry that produced them, so the transcript reads like a complete investigation. The REPL uses the full workspace width by default, keeping the active question and its answer together. Use the arrow keys at the edge of the composer to recall older input.

Solidity REPL interface with numbered entries, inline results, and a clean replay gas summary. Open full size

Accepted entries keep their values inline while the compact strip summarizes the clean replay.

  1. Clean replay summarizes the accepted history, gas, and duration.
  2. Inline values stay attached to the entries that produced them.
  3. The composer accepts the next complete Solidity fragment.
ContinueLater entries can use variables, functions, types, and deployed contracts declared by accepted earlier entries.
Edit → Update & runChange an entry and validate the complete replay. A failed edit stays open and does not replace accepted history.
Use againCopy an entry into the composer without changing the transcript, then adjust and run it as a new entry.
DeleteRemove a rejected attempt immediately. Removing an accepted entry succeeds only when the remaining history still runs.
ReproduceEvery proposed history change rebuilds all accepted entries and runs them against the same clean EVM.

A new entry or edit enters the cumulative program, and a deletion changes it, only after the complete candidate history compiles and executes successfully from a clean EVM. A failed new entry remains visible and editable as a rejected attempt. The replay summary stays on the last accepted history and marks the failed input as Attempt not committed.

Rejected REPL entry with an inline Solidity error and Attempt not committed status. Open full size

A failed entry stays visible while the accepted replay remains unchanged.

  1. Attempt not committed confirms that the clean accepted replay is still active.
  2. The rejected entry keeps its attempted code and inline error for correction.
Transcript replay prevents hidden state from changing the answer. Persistent EVM state is available in Source mode for experiments that intentionally need each run to continue from the previous one.
05

Writing Solidity

Semicolons and a contract wrapper are optional for loose code. Each submitted entry must still be syntactically complete. Put an entire loop, function, struct, contract, or other braced construct in one multiline entry.

Variable declarations, loops, functions, structs, events, interfaces, libraries, contracts, imports, assembly, and normal Solidity syntax can build on definitions from earlier accepted entries.

Expressions

Each loose expression gets an inline result row. Supported types are decoded; other values show Executed with a note when no result display is available.

amount / 1 gwei

Declarations

Declare helpers beside the statements that use them.

square(7)

Full contracts

Deploy and call contracts without leaving the page.

Box box = new Box()
Solidity REPL preserves Solidity semantics. It repairs presentation ceremony, but it does not silently change types, arithmetic, or control flow.
06

Results and inspection

In REPL mode, each entry shows its typed values and errors inline. The compact accepted replay summary shows replay status, gas, and duration, then adds counts when the run contains logs, calls, or storage writes. It leaves the rest of the workspace to the transcript. Use the format menu to switch compatible values between display, decimal, hexadecimal, full word, ABI bytes, and JSON.

Select Inspect to open a drawer for the clean replay. Its Overview shows gas, EVM steps, duration, call depth, and activity counts. Logs, Calls, State, and Debug tabs appear only when that data exists. Close the drawer to return to the full-width transcript.

Solidity REPL Inspect drawer showing gas, EVM steps, duration, call depth, and activity counts. Open full size

Inspect opens on Overview; activity tabs appear only when the replay contains them.

  1. Metrics summarize gas, EVM steps, duration, and maximum call depth.
  2. Tabs expose only the detailed activity available for this replay.
  3. Activity counts show logs, calls, storage writes, and inline values at a glance.

Immediately after a rejection, while the summary shows Attempt not committed, Inspect opens that rejected attempt and labels it Not committed. The accepted transcript remains unchanged. Source mode instead keeps Run details beside the editor. Values is the default after a runnable Source result; Logs, Calls, State, and Debug appear only when the source run produces them. Below 850 pixels wide, Run details stacks beneath the editor.

Solidity REPL Source mode with the Solidity editor and Run details panel side by side. Open full size

Source mode keeps Values and available run details beside the complete document.

  1. The mode toggle switches between the REPL transcript and full Source editing.
  2. The editor contains the complete Solidity document for this session.
  3. Run details keeps Values visible and adds activity tabs when data exists.
OverviewGas, EVM steps, duration, call depth, and activity counts.
LogsEmitting address and decoded event arguments. Undecoded logs show their raw data.
CallsNested CREATE and CALL operations with status, value, and gas.
StateChanged storage slots with their final recorded values, deduplicated by contract address and slot.
DebugOpcode steps with program counter, gas, stack, memory, and source line.

Compilation and execution errors point back to the original entry and line. REPL changes are transactional, so the accepted replay and its output remain current unless the full candidate replay succeeds. Source typing changes the document immediately; its Run details are marked as results from the previous run until the source runs again.

Replay source is separate from Inspect. It opens the generated Solidity wrapper that Solidity REPL compiled for the accepted replay. The session JSON, rather than the compiled wrapper, preserves the visible transcript and entry boundaries.
Inspect a decoded event
07

Sessions

Sessions save automatically on this device, including accepted and rejected transcript entries plus the uncommitted draft. Rename a session at the top of the REPL and use the history button to move between saved work.

  • New creates an empty transcript.
  • Duplicate creates an independent copy.
  • Import session restores a Solidity REPL JSON export.
  • Delete removes the active local session.
  • Opening a recipe creates a new session, preserving current work.

What is saved

A session stores its transcript and draft, Source document, browser files, compiler settings, execution context, fork configuration, mode, and display preferences. Compiled bytecode and successful execution results are rebuilt when needed, so restored output is tied to the restored inputs.

Browser sessions are device-local and are not account-synced. Duplicate before exploring a different path, and export session JSON when the investigation must move to another browser or person.
08

Execution controls

Open Controls → Run to configure the EVM seen by the transcript. You can set msg.sender, tx.origin, the execution address, value, calldata, gas, block number, timestamp, base fee, gas price, and chain ID.

Solidity REPL Run controls with transaction, block, and local EVM settings. Open full size

Run controls define the transaction, block, execution, and fork context.

  1. Control tabs organize run, compiler, file, and verified-contract settings.
  2. Environment selects a chain fork or a clean local EVM.
  3. Call context sets sender, value, calldata, gas, and block fields.

Local EVM

Local mode executes entirely in the browser. REPL history is always replayed from a clean deterministic environment. Source mode can enable Keep EVM state when repeated runs should share storage, balances, and deployed contracts.

Fork

Fork reads one block through an EVM-compatible RPC URL. No provider is selected by default. If the URL is empty when you run, Solidity REPL asks for one and continues the pending run after you save it. Enter a block number, or leave it empty to start from the latest block and pin it after the first successful run. Calls and writes are simulated, no transaction is broadcast, and later runs remain reproducible.

NetworkThe RPC URL determines which EVM-compatible network serves state. Set chain ID to that same network so the simulated block context agrees. Ethereum mainnet, L2 networks, and compatible sidechains can be used when their provider supports the required RPC methods.
BlockA fixed block makes code, balances, and storage stable. The provider must retain historical state for that block.
ReadContract code, account data, and storage are fetched as the local simulation needs them. Requests leave the browser for the RPC endpoint.
WriteState changes exist only inside the simulated run. Solidity REPL never signs or broadcasts a transaction.

Transaction fields and block fields answer different questions. Sender, origin, value, calldata, gas, and gas price describe the call. Block number, timestamp, base fee, and chain ID describe the block context visible to Solidity. The execution address is the address where the generated runner is installed for the simulation.

Change the call context Call USDC on a fork
09

Compiler

Open the Solidity version button above the workspace to search every stable release from 0.4.0 through 0.8.36. Selecting a result pins that exact compiler version to the session, so reopening or exporting the session keeps the same compiler instead of silently moving to a newer release.

When a selected compiler is not already available locally, Solidity REPL downloads its browser build from the official Solidity compiler distribution. The browser caches it for later runs. The first compile with that release can therefore take longer and requires a network connection; a cleared browser cache may require the download again.

Compiler controls follow the capabilities of the selected release. The available EVM targets are limited to those known by that compiler, and options such as via IR appear only when the release supports them. Optimizer settings and optimizer runs are saved with the exact compiler selection. Releases before 0.4.11 use their built-in optimizer run count.

Changing the compiler makes existing results stale. A local REPL session replays its accepted history with the new release; a manual or fork session waits for Run. Source written for a newer release can fail under an older compiler, but the source is left intact so the incompatibility remains visible and you can switch back safely.

Generated from the compiler catalog. Current catalog release: 0.8.36.
SeriesSupported rangeReleasesExact versions
0.8.x0.8.0–0.8.3637
View versions0.8.36, 0.8.35, 0.8.34, 0.8.33, 0.8.32, 0.8.31, 0.8.30, 0.8.29, 0.8.28, 0.8.27, 0.8.26, 0.8.25, 0.8.24, 0.8.23, 0.8.22, 0.8.21, 0.8.20, 0.8.19, 0.8.18, 0.8.17, 0.8.16, 0.8.15, 0.8.14, 0.8.13, 0.8.12, 0.8.11, 0.8.10, 0.8.9, 0.8.8, 0.8.7, 0.8.6, 0.8.5, 0.8.4, 0.8.3, 0.8.2, 0.8.1, 0.8.0
0.7.x0.7.0–0.7.67
View versions0.7.6, 0.7.5, 0.7.4, 0.7.3, 0.7.2, 0.7.1, 0.7.0
0.6.x0.6.0–0.6.1213
View versions0.6.12, 0.6.11, 0.6.10, 0.6.9, 0.6.8, 0.6.7, 0.6.6, 0.6.5, 0.6.4, 0.6.3, 0.6.2, 0.6.1, 0.6.0
0.5.x0.5.0–0.5.1718
View versions0.5.17, 0.5.16, 0.5.15, 0.5.14, 0.5.13, 0.5.12, 0.5.11, 0.5.10, 0.5.9, 0.5.8, 0.5.7, 0.5.6, 0.5.5, 0.5.4, 0.5.3, 0.5.2, 0.5.1, 0.5.0
0.4.x0.4.0–0.4.2627
View versions0.4.26, 0.4.25, 0.4.24, 0.4.23, 0.4.22, 0.4.21, 0.4.20, 0.4.19, 0.4.18, 0.4.17, 0.4.16, 0.4.15, 0.4.14, 0.4.13, 0.4.12, 0.4.11, 0.4.10, 0.4.9, 0.4.8, 0.4.7, 0.4.6, 0.4.5, 0.4.4, 0.4.3, 0.4.2, 0.4.1, 0.4.0
Using legacy Solidity: selecting a 0.4.x compiler runs that release as it was published. Solidity REPL does not translate modern syntax or rewrite source pragmas. Use the constructor, fallback-function, data-location, and arithmetic rules accepted by the exact version you select; newer examples may need to be adapted before they compile.
Run the Solidity 0.4.0 example
10

Files and verified contracts

Use Files to add in-browser .sol files. Import them from a transcript entry or Source mode using a relative path.

import "./MathLib.sol"
MathLib.double(21)

Import a public Git repository

Open Files → Import public Git repository and paste a public HTTPS clone or repository URL. Optionally pin a branch or tag and narrow the scan to one subdirectory. Solidity REPL reads one immutable repository snapshot, shows the resolved commit, and lets you select the .sol files to add. Relative Solidity dependencies from the same repository are included automatically.

  • GitHub, GitLab, Bitbucket, Codeberg, self-hosted Git services, and other public smart-HTTP repositories use the same flow.
  • Imported paths are rooted under the repository name, such as openzeppelin-contracts/contracts/token/ERC20/ERC20.sol, so relative imports inside the repository remain stable. Only the files reachable from imports in your active entry or Source document are sent to the compiler.
  • The commit hash records the exact snapshot. Imported files are copied into the session and do not update until you scan and import again.
  • Only anonymous HTTPS reads are supported. Private repositories, SSH URLs, credentials, submodules, Git LFS objects, and package installation are outside this importer.
GitHub repositories use GitHub’s public API and raw-file CDN directly from your browser. For other hosts, Solidity REPL’s Cloudflare Worker forwards only Git discovery and upload-pack reads, with request and response limits. Repository objects stay temporarily in browser storage while you choose files.

Use Add contract with a chain ID and address to request a verified ABI from Sourcify. Choose Fork or Local. Solidity REPL generates a typed interface, inserts a ready-to-use contract variable, and applies the selected execution mode to the session.

What Add contract does

IdentifyChain ID and address identify one deployment. They do not select an RPC provider or prove that the selected fork is on the same network.
Load metadataThe browser asks Sourcify for verified metadata. Coverage varies by network and contract; an unverified deployment cannot be generated automatically.
GenerateSolidity REPL adds a local interface file and inserts a typed variable at the deployed address. This gives the compiler the function signatures it needs.
ExecuteChoose Fork and use an RPC for that same network to call the deployed code and state. In Local, the address has no live deployment unless your own setup installs code there.

A successful verified-source lookup and a successful contract call are separate operations. The first obtains compile-time types from Sourcify; the second obtains runtime state from your RPC. Proxies may also require you to load the implementation interface while calling the proxy address.

No RPC provider is selected automatically. In Fork mode, enter an endpoint in Controls or wait for the Run prompt. Local does not load deployed code or state.
11

Persistent state and VM helpers

In Source mode, Keep EVM state preserves storage, balances, and deployed contracts between manual runs in the current browser tab. Reset EVM state makes the next Source run start from the configured environment. REPL mode uses deterministic cumulative replay instead, so a transcript never depends on hidden state from an earlier run.

Supported local EVM helpers include:

vm.deal(account, 10 ether)
vm.store(contractAddress, slot, value)
vm.load(contractAddress, slot)
vm.warp(newTimestamp)
vm.roll(newBlockNumber)
vm.etch(target, runtimeBytecode)

vm.label assigns a readable local name but currently does not change displayed addresses.

Run a persistent counter
12

Opcode debugger

Enable Opcode debugger under Run controls. Turning it on keeps later runs manual because capturing execution steps costs more work. A prepared debugger example still runs once when it opens. In REPL mode, select Inspect, open the Debug tab, and choose an opcode. In Source mode, use the Debug tab in the permanent Run details panel. Both views show remaining gas, call depth, source line, stack, and memory.

Debug capture is intentionally bounded at 600 opcode steps. The debugger lists the first 240 captured steps to keep the interface responsive.
Debug an assembly expression
13

Generated source and export

In REPL mode, choose Replay source to open the Source & export dialog. Its Generated source tab contains the complete Solidity wrapper compiled for the accepted replay. Switch to Source mode from the mode control when you want to edit the full document. Run details stays beside the editor on wider screens and stacks below it on narrow screens.

Solidity REPL Source and export dialog with Generated source, Foundry project, and Session JSON tabs. Open full size

Replay source opens the compiled wrapper alongside Foundry and session exports.

  1. Export tabs switch between generated source, the Foundry project, and session JSON.
  2. Generated source shows the complete Solidity wrapper compiled for the replay.
  3. Copy and download actions export the content shown in the active tab.

Opening Source mode preserves the transcript. If you edit the full document, Solidity REPL shows a conversion notice. When you switch back, it first validates the complete document. A successful validation turns it into one accepted REPL entry; a failure leaves you in Source mode with the document unchanged.

  • The Foundry archive includes source, project files, compiler settings, and a reproduction script for Solidity 0.8.0 and newer. Legacy sessions can still export generated source and session JSON.
  • The session JSON restores transcript entries, the draft, source, files, compiler, context, and preferences.
  • RPC URLs are removed from exported session files.
14

Shortcuts and command palette

⌘/Ctrl EnterCommit and run the current REPL entry
↑ / ↓Recall earlier input from the composer edge
⌘/Ctrl KOpen the command palette

The command palette also opens execution, compiler, file, contract, debug, export, new-session, mode-switch, and Source-mode auto-run actions.

REPL commands

:helpShow the available REPL commands and shortcuts.
:clearClear every transcript entry and start empty.
:resetReset the replay environment and rerun accepted history.
:sourceOpen the generated source and export dialog. This does not switch the editable workspace to Source mode.
:settingsOpen execution controls.
15

Troubleshooting

Start with the status beneath the workspace and the error attached to the current entry or Source run. Solidity REPL distinguishes compiler startup, compilation, RPC access, EVM reverts, and rejected history so the failing stage stays visible.

Run is queuedThe selected compiler is still loading. Keep the page open; the pending run starts when loading finishes. A first-time compiler download needs network access.
Compiler changedRead the first compiler error and adapt syntax or pragma for that exact release. Accepted source is preserved, so you can also return to the earlier compiler.
Import failedConfirm the path exactly matches a browser file, including case and the .sol suffix. Imports must use safe relative paths; package downloads are unavailable.
RPC unavailableCheck that the URL is HTTP or HTTPS, reachable from this browser, allows browser requests, and supports the requested chain and historical block. Then Run again.
Contract call failedConfirm Fork is selected, the RPC network matches the contract chain ID, the pinned block contains code at the address, and the generated interface matches the deployed contract or proxy.
State disappearedREPL intentionally rebuilds clean state. For state that must accumulate between separate runs, switch to Source, enable Keep EVM state, and avoid resetting the EVM.
Tab is missingLogs, Calls, State, and Debug are conditional. A tab appears only when the current run captured that activity; Debug also requires the opcode debugger before the run.
Result is staleSource changed after the displayed run. Run the document again. In REPL, fix or remove the rejected attempt; the accepted replay remains the current result until then.

Reduce the problem without losing evidence

  1. Duplicate the session so the original record remains.
  2. Keep the compiler, optimizer, EVM target, and execution context fixed.
  3. Remove unrelated later entries, then edit the earliest entry involved in the failure.
  4. Inspect the revert, calls, and state before enabling the opcode debugger.
  5. Export the session once the smallest reproduction still shows the behavior.
16

Privacy and current limits

Source compilation and EVM execution happen in the browser. Network access is tied to a visible feature or to loading the application itself.

Browser storageSessions, drafts, settings, and project files stay in this browser profile through IndexedDB with a localStorage fallback.
Compiler downloadAn uncached compiler release is downloaded from the official Solidity binary distribution and cached by exact version.
Fork RPCFork sends state-reading JSON-RPC requests to the endpoint you enter. The provider can see requested addresses, slots, proofs, and block identifiers.
SourcifyAdd contract sends the chosen chain ID and address to Sourcify to request public verified-contract metadata.
Public GitGitHub imports read the public API and selected raw files directly from your browser. Other public HTTPS Git hosts use a read-only same-origin Worker endpoint, with temporary Git objects stored in browser storage.
TransactionsSolidity REPL has no wallet or private-key flow. Calls and writes are simulations and are never broadcast.
Session exportExported JSON includes the investigation inputs but removes the configured RPC URL before download.

Current source boundaries

  • Project files are in-browser .sol files; public Git import is supported, while package-manager installation is not.
  • Top-level fallback and receive functions must be placed inside a named contract.

Practical limits

  • During live use, accepted REPL source is limited to 48,000 characters and an evaluation stops after 20 seconds.
  • Each evaluation accepts up to 80 loose top-level statements.
  • When saved data is restored and normalized, Solidity REPL keeps up to 250 entries and 96,000 transcript characters, including rejected attempts.
  • Solidity REPL uses and restores up to 128 valid browser files, each no larger than 100,000 characters, with a combined source limit of 4,000,000 characters.
  • An execution records up to 100 call records.
  • Opcode debugging captures up to 600 steps and displays the first 240.
Read the full privacy explanation