Build and check JSON-RPC requests without sending them
Pick a method from a dated catalogue of standard eth_* calls, fill in parameters, and get a validated request body. Paste responses to match a batch by id or explain an error. Snippets use environment-variable placeholders.
Editing a request never sends it. This page has no network mode: there is no endpoint field that gets called, and no live data.
mainnet, native ETH. Pack 1.0.0 (2026-10-30), not live-verified.
Native balance of an account at a block, in wei. Returns QUANTITY (wei). read, safe to retry
The result is the balance at the requested block only. A saved response is a snapshot, never a current balance.
20-byte account address.
Block number (QUANTITY), tag (latest, safe, finalized, earliest, pending) or EIP-1898 object {blockHash} / {blockNumber}.
On Ethereum Mainnet, "latest" resolves to whatever head the node has when the request arrives; two calls seconds apart can see different blocks. A saved response never stands in for the current value.
Edit freely. Nothing is sent when you type.
Checking for a saved draft…
Complete
No problems found against JSON-RPC 2.0 and the method pack.
This builder has no send button. Copy a snippet, run it yourself, and paste the response into the response explorer.
cryptoapis.eth-jsonrpc v1.0.0 (2026-10-30). Standard eth_/net_/web3_ read methods, plus signing/broadcast/wallet methods listed as excluded so they are visibly out of scope. Self-authored from the Ethereum execution-apis specification and ethereum.org JSON-RPC docs. Not tested against a live node.
What the validator checks
Every request is checked against JSON-RPC 2.0 and the Ethereum execution-API conventions in the bundled method pack. Problems are tied to a path such as params[1], so you can fix exactly the value at fault.
"jsonrpc" must be the string "2.0"; a missing id makes the request a notification that never gets a reply.
QUANTITY values must be compact hex: "0x0" is zero, "0x" is not a number, and "0x01" is rejected by strict clients for its leading zero.
Block parameters accept tags (latest, safe, finalized, earliest, pending), a hex number, or an EIP-1898 object where the method allows it.
Call objects flag mixed legacy and EIP-1559 fee fields, and conflicting data/input values.
Log filters flag blockHash combined with a block range, more than four topic positions, and malformed topics.
Batch responses are matched by id, never by position
JSON-RPC 2.0 lets a server answer a batch in any order. The matcher pairs each reply with its request through the id, keeping the string "2" distinct from the number 2. It reports requests with no reply, replies nobody asked for, ids used twice (whose replies cannot be attributed), notifications, and error replies with id null.
Large batches are matched in a Web Worker and can be cancelled.
Errors come in four layers
A failed call can fail at the transport (HTTP 429, a 502 HTML page), arrive incomplete (a truncated body), break the JSON-RPC envelope, or return a well-formed RPC error. The response explorer separates those layers, maps documented codes (JSON-RPC 2.0, EIP-1474, and the common code 3 for reverts), decodes Error(string) and Panic(uint256) revert data, and leaves undocumented codes labelled unknown.
Safe code snippets
Snippets for cURL, fetch, Python, Go, viem 2.x and ethers 6.x read the endpoint from an environment variable such as RPC_URL. Provider URLs often embed API keys, so the generator never writes a URL into the code. The request body is emitted verbatim, so large numbers are not re-serialised through floating point.
Questions
Does this page call my RPC provider?
No. There is no request execution at all. You can copy a snippet and run it yourself, then paste the response back in for analysis.
Why is "0x01" flagged as invalid?
The Ethereum JSON-RPC QUANTITY encoding requires the most compact form. Geth and other strict clients reject leading zeros with an "invalid argument" error. Write "0x1".
Why are eth_sendRawTransaction and eth_sign greyed out?
Signing and broadcasting are out of scope for this workbench. They are listed so you can see they are deliberately excluded, not missing by accident.
My batch reply has fewer items than my request. Is that an error?
Not necessarily. Notifications (requests without an id) never get a reply. The matcher lists exactly which ids are unanswered so you can tell a notification from a dropped reply.