A block explorer is a website that renders raw blockchain data as pages. It is the first tool most people use to “see” a transaction and the last tool many people learn to read properly. Every number on the page is either a fact from the chain or an inference the explorer added for convenience, and the difference matters when you are debugging a payment, auditing a contract or verifying a claim someone made on social media.
Part 1 — A Bitcoin transaction
Identity
txid is the double-SHA256 hash of the transaction's serialised bytes, excluding witness data. Since the 2017 SegWit upgrade a second identifier, wtxid, covers the witness too. The practical consequence: a txid cannot be changed by a third party fiddling with signatures, which is what made payment channels safe to build. If an explorer shows both, that is why.
Inputs
Each input names a previous output by txid:index, the coin being spent. Explorers resolve that reference to show the address and amount of the coin, but note that the address of an input is derived from the previous output, not stored in this transaction. The input also carries the unlocking data: a signature and public key for legacy scripts, or a witness for SegWit and Taproot. A sequence field per input signals whether the sender opted into Replace-By-Fee; explorers usually summarise it as an “RBF” badge.
Outputs
Each output is an amount in satoshis and a locking script. The explorer translates the script into an address and a type. Learn to read the prefixes:
| Address starts with | Script type | Meaning |
|---|---|---|
| 1… | P2PKH | Legacy pay-to-public-key-hash; largest and most expensive to spend |
| 3… | P2SH | Pay-to-script-hash; multisig, or SegWit wrapped for compatibility |
| bc1q… | P2WPKH / P2WSH | Native SegWit (bech32); cheaper, witness discount |
| bc1p… | P2TR | Taproot (bech32m); Schnorr signatures, key-path or script-path spends |
Outputs with no address and a script starting OP_RETURN carry arbitrary data and are unspendable; they are how protocols anchor commitments into Bitcoin.
Size, weight and fee
Since SegWit, block capacity is measured in weight units with a limit of four million per block. Non-witness bytes count four units each; witness bytes count one. Explorers convert weight to virtual bytes (vsize = weight ÷ 4) so that fees can be quoted as sat/vB. The fee itself is never written in the transaction: it is the sum of inputs minus the sum of outputs. When an explorer says “fee 2,340 sat, 14.2 sat/vB” it computed both.
Time fields
locktime makes a transaction invalid before a given block height or timestamp; zero means no restriction. Combined with sequence numbers it enables relative timelocks. The “time” an explorer shows for a transaction is the timestamp of the block that included it, or the time the explorer's own node first saw it in the mempool; neither is the moment you pressed send.
Confirmations
Confirmations = current chain height − block height of the transaction + 1. An unconfirmed transaction has none and lives only in mempools, which differ between nodes; an explorer's mempool view is the view of that explorer's node.
Part 2 — A Bitcoin block
A block page shows the height (position in the chain), the hash (which must be below the difficulty target, hence the leading zeros), the previous block hash that chains it to its parent, the merkle root that commits to every transaction in the block, the timestamp the miner wrote (which may be a little off), the nonce, and the difficulty and weight. The first transaction is always the coinbase: it has no real inputs and creates the block subsidy plus all fees for the miner. The coinbase input's data field is where miners write pool names and signalling, which is how explorers know “mined by” a given pool.
Part 3 — An Ethereum transaction
Ethereum uses accounts, not coins, so the page looks different but the rule is the same.
- Hash: keccak-256 of the signed transaction. Nonce: the sender's transaction counter; transactions from one account must confirm in nonce order, which is why a stuck low-fee transaction blocks everything after it.
- From / To: the sender and the recipient account. If “to” is a contract, the explorer usually shows the contract's name if its source code was verified, and decodes the input data: the first four bytes are the function selector, the rest are ABI-encoded arguments. A missing “to” means contract creation.
- Value: ether transferred directly. Token transfers show a value of zero here; the tokens move inside the contract's storage and show up as events.
- Gas limit / gas used: what the sender authorised versus what execution consumed. A simple ether transfer uses exactly 21,000 gas. Base fee is set by the protocol per block and burned; priority fee (tip) goes to the block proposer. Transaction fee = gas used × (base fee + priority fee).
- Status: success or failure. A failed transaction is still included in a block and still pays gas; only its state changes are reverted. The explorer often shows the revert reason if the contract provided one.
- Logs / events: structured records emitted by contracts during execution, such as the
Transfer(from, to, amount)event that every standard token emits. This is where the “Tokens transferred” section comes from. - Internal transactions: ether movements caused by contract code rather than by the signed transaction itself. They are not stored on chain as transactions; the explorer reconstructs them by re-executing the transaction with tracing enabled. Different explorers can disagree here.
Since the switch to proof of stake, blocks are produced in fixed twelve-second slots, grouped into epochs of thirty-two slots; explorers show both the block number and the slot, and mark a block as “finalized” once the checkpoint containing it has been justified twice.
Part 4 — What the explorer added
Fiat values use whatever price feed the explorer chose at whatever moment it sampled. Address labels (“Binance 14”, “Bitfinex hack”) come from heuristics, public reports and manual tagging; they are often right and occasionally spectacularly wrong. “Balance” of a Bitcoin address is a sum over UTXOs the explorer indexed, which is correct but conceptually foreign to the protocol. Contract names only appear when someone uploaded matching source code, and a verified contract can still be malicious. None of this is a reason to distrust explorers; it is a reason to know which fields are which.
Part 5 — Checking from your own node
Everything above can be read without an explorer. On a Bitcoin Core node with transaction indexing enabled:
bitcoin-cli getrawtransaction <txid> true
bitcoin-cli getblock <blockhash> 2
bitcoin-cli getmempoolentry <txid>The first call returns inputs, outputs, scripts, size, vsize, weight and confirmations as JSON; you compute the fee by fetching each input's previous output. On an Ethereum node, or any provider exposing JSON-RPC:
curl -s -X POST -H 'Content-Type: application/json' \
--data '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["0x<hash>"]}' \
http://localhost:8545The receipt carries status, gas used, effective gas price and the logs. Pair it with eth_getTransactionByHash for the signed fields and debug_traceTransaction if you want the internal calls an explorer would show. Reading the raw output once is the best cure for treating explorer pages as authoritative: the page is a view, the node is the source.
Frequently asked questions
Why does a Bitcoin explorer show a fee when the transaction has no fee field? Bitcoin transactions never state the fee. It is implied: the total of the inputs minus the total of the outputs goes to the miner. The explorer looks up each input's previous output to compute it.
What is the difference between size, vsize and weight? Size is the raw byte length. Weight counts non-witness bytes four times and witness bytes once, with a block limit of four million weight units. Virtual size is weight divided by four, and fee rates are quoted per virtual byte so that SegWit's discount is reflected.
Why did my Ethereum transaction fail but still cost gas? Execution happens before the outcome is known. If the contract reverts, the state changes are undone, but the computation up to that point was already performed by every node, so the gas it consumed is still paid. The transaction stays in the block with a failed status.
Are internal transactions stored on the blockchain? No. They are ether movements made by contract code during execution. Explorers reconstruct them by re-running the transaction with tracing, which is why two explorers can present them differently.