How we test and score explorers

Every explorer in our directory is scored against six criteria, each out of five, combined into a weighted overall figure. The weightings are fixed and published below, which means you can reconstruct any score yourself and tell us precisely where you think we are wrong.

The six criteria

Chain coverage (20%). How many chains the explorer indexes, weighted towards whether it covers the chains people actually use rather than raw count. A specialist covering one chain scores low here by design, which is why the verdict matters more than the number.

Data depth (25%). How much the explorer shows beyond the basics, and whether it models the chain's own structure rather than flattening it. Contract verification, decoded instructions, staking and governance data, message-chain reconstruction, mempool visibility. This carries the most weight because it is what people run out of first.

Response speed (15%). Time to a complete rendered page on identical lookups, measured rather than estimated. Weight of assets counts, because an explorer that takes ten seconds on mobile data is not usable for the people most likely to need it urgently.

Privacy posture (15%). Onion service, whether pages render without JavaScript, whether the software can be self-hosted, and whether the operator has a commercial interest in address attribution or holds customer identity data. This is the criterion that generates the most disagreement, and we think the difference it measures is real.

API access (15%). Whether an API exists, whether it needs a key, what the free tier actually allows, and whether it sends permissive CORS headers so it can be called from browser code. Verified with live requests rather than read from a pricing page.

Interface clarity (10%). Whether the important fields are findable, whether the terminology is used consistently, and whether the explorer explains its own chain's quirks. The lowest weighting because it is the most subjective.

The reference set

Every explorer gets the same items pasted into it, chosen to expose different failure modes.

A transaction with an unusually large number of inputs, which tests whether the page stays readable. An address with a long history, which tests pagination and filtering. A transaction sitting unconfirmed in the mempool, which tests whether the explorer gives you any context or just a label. A failed contract call, which tests whether the revert reason is surfaced in plain text or left as raw hex. A proxy contract, which tests whether the implementation is resolved. And, where the chain has one, a confidential or cross-chain case — an MWEB peg-in, a bounced TON message, a bridge withdrawal — which tests whether the explorer is honest about what it cannot see.

Then we read the API documentation and actually call the endpoints. This matters more than it sounds, because published rate limits and real rate limits are frequently different numbers, and key requirements have changed twice in the last eighteen months.

What the scores are not

They are not a popularity ranking. Etherscan is by a wide margin the most-visited explorer in the world and it does not top our list, because it is closed source, cannot be self-hosted, and its privacy posture is poor. If those things do not matter to you, the column to read is "best for" rather than the number.

They are not a safety rating. Every explorer in the directory is a legitimate service. Nothing here is a warning, and the risks that actually cost people money are covered in our guide to fake explorers.

They are not vendor-supplied. No explorer sees its score before publication, none of them pays us, and we earn no commission on any link to them.

Score notes

Every full review carries a short explanation of why each criterion scored what it did. A number on its own is an assertion; a number with a reason is something you can argue with. There are currently 35 full reviews and 50 entries in the directory.

How we test an API

The API score is the one most often wrong on other sites, and the reason is simple: almost nobody tests it. Pricing pages and documentation describe an intention. What a service actually does when you call it is frequently different, and the difference is never in your favour. So every API claim on this site comes from a request we made, and we record the date we made it, because this is the fastest-decaying information we publish.

Four things get checked, in this order.

Does it answer without a key. A great many services describe themselves as having a free tier when what they mean is a free registration. Those are different products. We make the call with no credentials at all and record what comes back.

Does it answer a browser. This is the check that catches the most errors elsewhere, because it is invisible from the command line. A server sends no Origin header; a browser always does, and some endpoints reject anything that carries one. Solana's public mainnet RPC is the clean example: the identical request returns 200 from curl and 403 from a web page. Anyone who tested it in a terminal and wrote "works, no key required" was not wrong about what they saw, only about what it means. We send the preflight and the real request with an Origin header set, and we treat a missing Access-Control-Allow-Origin as a failure, because for front-end code it is one.

Where the limit actually sits. Documented rate limits and enforced rate limits are related but not equal, and the gap moves. We loop ordinary requests until something changes, and we record what changing looks like — a slower response, a 429, or something worse. The distinction between a throttle and a ban matters enormously and is almost never documented. A throttle you back off from. A block you cannot, and if your requests originate from one server rather than from each visitor's browser, a single burst removes the feature for everybody.

What the free tier covers, not just what it costs. For multi-chain APIs the headline is usually a number of supported networks. That number counts chains, not usage, and the two diverge sharply. We query each network we care about individually and record which ones answer, because a service can support sixty chains and still exclude the three you were planning to use.

None of this is sophisticated. It is roughly twenty minutes of work per service, and it is the difference between a review and a rewritten press release. It also means our API scores move more often than the rest, and occasionally sharply downward, when a service we praised tightens something quietly.

What we do when we are wrong

We will be, periodically. A page can be accurate on the day it is written and wrong four months later without anybody touching it, which is the ordinary condition of writing about infrastructure that other people control.

When we find an error, we correct the page rather than quietly deleting the claim, and where the correction changes the conclusion we say what changed and when. A review that has never visibly changed its mind about anything is not a review that has been checked; it is one that has been left alone. If you find something here that no longer matches what you see, tell us — the address is on our contact page, and a specific report of the form "this endpoint returns X now" is worth more to us than almost anything else we receive.

When we update

Scores change when the thing being scored changes. An API moving behind a key, an explorer being acquired, a project going open source, or a chain being dropped from free-tier coverage all trigger a re-check. We also re-test periodically, because indexing quality drifts.

Every page carries the date it was last updated. If a page says September 2026 and it is now considerably later, treat the API details in particular with suspicion — that is the part of this subject that goes stale fastest, and our API comparison is the page we re-check most often.