The short answer
An explorer runs a node to obtain the raw chain, an indexer to reorganise it into a searchable database, an API to serve queries against that database, and a front end to render the results. Every layer makes choices, which is why two explorers reading the same chain can legitimately show you different things.
The node: where the data comes from
Everything starts with a node, because a node is the only thing that actually knows what the blockchain says.
A node downloads blocks from peers, validates them against the protocol's rules, and maintains the resulting state. Validation is the important word. A node does not trust what it is told; it checks every signature, every script, every state transition. That is what makes a blockchain trustworthy at all, and it is why a node is expensive to run.
For an explorer, the node needs to be more than usually complete. A default Bitcoin node prunes old block data it no longer needs; an explorer node cannot, because someone will ask about a transaction from 2013. It also needs a transaction index, which is not enabled by default and which meaningfully increases storage. On Ethereum the equivalent is an archive node, which retains historical state rather than only the current one and which runs into multiple terabytes.
This is the single largest cost in operating an explorer, and it is why free explorers are more remarkable than they appear. Blockstream gives away API access to a fully indexed Bitcoin node without so much as an email address, and the infrastructure behind that is not cheap.
The indexer: turning verification data into searchable data
A node stores the chain in a form optimised for validating the next block. That form is close to useless for answering the questions people actually ask.
Consider "what is the balance of this address". On Bitcoin there is no such field anywhere. The answer requires finding every unspent output associated with that address and adding them up, which means having indexed outputs by address in the first place. The node does not do that, because it does not need to.
The indexer's job is to walk the chain and write it into a database organised for these questions: transactions by address, outputs by script, logs by topic, tokens by holder. It also decodes — turning raw bytecode into readable function calls, resolving token contracts to names and decimals, reconstructing internal transactions from execution traces.
This is where the interpretation happens, and where explorers diverge. How should an address's balance treat outputs that exist only in the mempool? How should a token with non-standard transfer behaviour be counted? What counts as the "main" transaction when a single user action produced a tree of receipts on NEAR or a message chain on TON?
Each explorer answers differently, and none of those answers is written into the protocol. That is the entire reason two honest explorers can show you different numbers.
The API and the front end
Once the database exists, serving it is comparatively ordinary engineering. An API layer accepts queries, applies rate limits, and returns JSON. A front end calls that API and renders pages.
Two things about this layer are worth knowing as a user.
The first is that the website and the API are usually the same thing underneath. When you browse mempool.space, your browser is calling the same endpoints a developer would. This is why explorers with good APIs tend to have responsive websites, and why an explorer that is slow to load is often slow because of its front end rather than its data.
The second is that the API layer is where commercial decisions live. Rate limits, key requirements and paid tiers all sit here, and they have moved noticeably in the last two years. Blockscout moved API traffic behind a key on 1 July 2026; Etherscan trimmed its free-tier chain coverage in the same period. Neither change altered the underlying data by a single byte. Our API comparison tracks the current position, because anything written before 2026 is now unreliable.
Reorganisations, and why an explorer can be briefly wrong
On a proof-of-work chain, two miners can produce valid blocks at nearly the same moment. Both propagate, different parts of the network see different ones first, and for a short period there are two competing versions of recent history. The network resolves this by following whichever chain accumulates more work, and the losing block is orphaned.
Transactions in the orphaned block are not lost — they usually return to the mempool and get included in a subsequent block — but for a few minutes an explorer may have shown them as confirmed in a block that no longer exists.
This is the actual reason confirmation counts matter. One confirmation on Bitcoin is not a guarantee; it is a probability that improves rapidly with each subsequent block. Six confirmations is a convention chosen because reorganisations deeper than that are vanishingly rare, not because six is a magic number.
Different chains handle this differently. Proof-of-stake Ethereum has explicit finality after two epochs. The XRP Ledger has no forks in the ordinary sense, because a ledger either closes with agreement or does not close. Rollups have the sequencer-versus-settlement distinction instead. Our guide on confirmations covers what the equivalent question is on each chain.
Indexing lag, and how to spot it
An indexer has to keep up with the chain. When it falls behind — because of load, a bug, a resource constraint, or a chain producing blocks faster than the deployment was sized for — recent activity simply does not appear.
This is indistinguishable from a transaction not existing, which is why it causes so much unnecessary alarm. Somebody sends you a payment, you check, the explorer shows nothing, and the reasonable conclusion is that something went wrong.
The check takes ten seconds. Find the explorer's reported latest block height and compare it against a second explorer or the chain's own public RPC. If it is thousands of blocks behind, that deployment is lagging and everything it shows you about recent activity is stale.
This matters most on Blockscout instances, because anyone can run one and quality varies enormously between a well-resourced deployment and one somebody set up eighteen months ago. It matters on multi-chain explorers covering long-tail networks for the same reason. It rarely matters on the major commercial explorers, which are well funded precisely because uptime is their product.
What this means for how you read one
Three conclusions follow from understanding the stack, and they are the practical value of having read this far.
An explorer is a rendering, not the chain. When it disagrees with your expectation, the possibilities are: the chain says something you did not expect, the indexer interpreted something differently from how you would, or the index is stale. Only the first is actually about the blockchain, and it is the least common of the three.
Open source is worth real weight. With Blockscout, mempool.space or Esplora you can read the code and settle a question about how a figure was derived. With a closed explorer you can only trust it. That is why our scoring rewards it.
Running your own removes every layer of doubt. Your node, your index, your answers, and nobody learns what you asked. The cost is genuine — hundreds of gigabytes and days of sync for Bitcoin, terabytes for Ethereum — and our self-hosting guide is honest about who should and should not bother.
Questions people ask
Does an explorer store the whole blockchain?
It runs nodes that do, plus its own database derived from them. The index is frequently larger than the raw chain, because it stores the same data organised several different ways for fast searching.
Why do two explorers show different balances?
Usually because one counts unconfirmed activity and the other does not, or because one is lagging the chain tip. Compare their latest block heights before assuming anything about the chain itself.
Can an explorer show me something that never happened?
Not on the chain it indexes — the data comes from a validating node. It can briefly show a transaction in a block that gets orphaned during a reorganisation, and it can show a stale balance if its index is behind. A fake explorer, by contrast, can show you anything at all.
What is an archive node?
On Ethereum, a node that keeps historical state at every block rather than only the current state. It is what lets an explorer answer questions about the past, and it is why Ethereum explorer infrastructure runs into terabytes.
Why do explorers need a transaction index?
Because a default Bitcoin node cannot look up an arbitrary transaction by hash — it only tracks what it needs to validate the next block. The index is what makes lookup possible, and it is not enabled by default.