Onion Page Pivot Extractor: Onion Addresses, PGP, Wallets, Analytics IDs

What does the extractor find, at a glance?

Every row below is extracted from the text you paste or the files you drop, deduplicated and counted, with up to five “where found” snippets (file, line number, surrounding text). Results are grouped, each group can be copied, and the whole set exports to CSV or JSON.

What can a saved onion page reveal about its operator?

Onion services hide where a server is, not what its operator publishes. A saved page often carries identifiers that also exist outside Tor:

• Payment addresses. Bitcoin and Ethereum addresses are public on their blockchains, so a donation or escrow address can be followed to exchanges and other sites. Monero is different: its addresses do not expose balances or counterparties to block explorers.
• PGP keys. Vendors and administrators sign mirror lists and messages. The same fingerprint on another forum, a paste site or a key server links the identities. Paste an armored block into the PGP Key Inspector to read its fingerprint, user IDs and creation date.
• Contact handles. Email, Jabber/XMPP, Telegram, Matrix, Session and Tox IDs are frequently reused across sites. Search them on the clearnet before anything else.
• Analytics, ad and verification IDs. A Google Analytics, Tag Manager, AdSense or Yandex Metrica ID, or a site-verification token, copied from an operator's clearnet template is a classic attribution pivot. Source-code search engines such as PublicWWW index these strings across websites (vendor description).
• Server leaks. Apache and nginx error pages can print a signature such as Server at 203.0.113.7 Port 80, and absolute links can name a clearnet domain or IP. The extractor flags any non-onion host in a server signature.
• Other onion services. Mirror lists, links to partner shops and “official” directories show which services the operator controls or trusts, and the extractor separates the page's own address from addresses it links to.

None of these is proof on its own. Operators plant decoys, share templates and copy each other's pages, so treat each hit as a lead to corroborate, as our dark-web OSINT guide recommends for any onion link.

How are v3 onion addresses checked?

The Tor specification defines a v3 onion address as base32(PUBKEY | CHECKSUM | VERSION) + ".onion", where PUBKEY is the service's 32-byte ed25519 public key, VERSION is one byte with the value 3, and CHECKSUM is the first two bytes of SHA3_256(".onion checksum" | PUBKEY | VERSION) Tor Specifications: rend-spec, “Encoding onion addresses [ONIONADDRESS]” (read 10 Oct 2026). Those 35 bytes encode to exactly 56 base32 characters, which matches the Tor Project's description of an onion address as 56 letters and numbers followed by .onion Tor Project Support: Onion Services — 16-character v2 addresses “no longer work”, onion addresses have 56 characters (read 10 Oct 2026).

The extractor decodes each 56-character label, checks that the version byte is 3, recomputes the SHA3-256 checksum with its own built-in SHA3 implementation (no library is downloaded) and marks the address valid or invalid with the reason. It was tested against the three example addresses printed in the specification and against addresses generated from random 32-byte keys with the same algorithm.

What the checksum proves is narrow: the address is well-formed and was not mistyped. It does not prove that the service is online, that it is the site it claims to be, or that whoever wrote the page controls it.

Why flag v2 addresses and look-alike mirrors?

v2 addresses are dead. The Tor Project's timeline removed v2 onion services from the code base in the 0.4.6 series (July 2021) and shipped client releases that disabled v2 on 15 October 2021 Tor Project blog: “Onion Service version 2 deprecation timeline”, dgoulet (2 Jul 2020). Its support pages say 16-character v2 addresses no longer work Tor Project Support: Onion Services — 16-character v2 addresses “no longer work”, onion addresses have 56 characters (read 10 Oct 2026). A 16-character address on a page is a dating clue — the text, or the link list it was copied from, predates the switch.

Look-alikes. When two v3 addresses on the same page share their first five or more characters, or four or more characters at the end (ignoring the final two, which carry the version), both are flagged as possible phishing clones. Random v3 addresses almost never share that much by chance; matching prefixes are usually generated on purpose so that a mirror looks familiar at a glance. Check every character against a source you trust, such as a PGP-signed mirror list.

Labels of other lengths ending in .onion are listed as malformed: truncated, padded or deliberately broken links.

How are wallet addresses validated?

• Bitcoin legacy (1…) and P2SH (3…): Base58Check — the last four bytes must equal the first four bytes of SHA-256(SHA-256(version + payload)), and the version byte must be 0 (pay-to-pubkey-hash) or 5 (script hash) Bitcoin Wiki: Base58Check encoding — double-SHA-256 checksum, version bytes 0 and 5 (read 10 Oct 2026).
• Bitcoin SegWit (bc1q…): the bech32 checksum from BIP-173, which also forbids mixed upper and lower case BIP-173: Base32 address format for native v0-16 witness outputs (assigned 20 Mar 2017).
• Bitcoin Taproot and later (bc1p…): BIP-350's bech32m checksum. Witness version 0 must use bech32 and version 1 or higher must use bech32m; the test vectors in BIP-350 that swap the two are rejected here BIP-350: Bech32m format for v1+ witness addresses (assigned 16 Dec 2020).
• Ethereum and EVM chains: if an address uses mixed case, each letter's case must follow the Keccak-256 hash of the lowercase address (EIP-55). All-lowercase or all-uppercase addresses carry no checksum and are shown as “found” rather than “valid” EIP-55: Mixed-case checksum address encoding (created 14 Jan 2016).
• Monero: 95-character standard addresses (106 for integrated), Monero's block-wise Base58, network byte (18 for a mainnet standard address) and a Keccak-256 checksum Monero Docs: Standard address — 95 characters, network byte 18, Keccak-256 checksum (read 10 Oct 2026).

Base58 strings that fail the checksum are shown only when they look like an address and the surrounding text mentions Bitcoin, a wallet, payment or donation, so random tokens do not flood the results. Lookup links are offered only for addresses that pass.

How does the favicon hash work?

Shodan stores each site's favicon as base64 data and computes http.favicon.hash by applying MurmurHash3 to that data; its own example shows the base64 broken into lines of 76 characters Shodan blog: “Deep Dive: http.favicon” — MurmurHash3 of the base64 favicon data (read 10 Oct 2026). The commonly used reproduction is mmh3.hash(base64.encodebytes(data)) SANS ISC diary: “Adding some Automation to the favicon.ico method of Host Recon”, Rob VandenBrink (29 Jun 2026), where encodebytes inserts a newline after every 76 characters and ends with a trailing newline Python docs: base64.encodebytes — newline every 76 bytes plus a trailing newline (read 10 Oct 2026) and mmh3.hash returns the signed 32-bit MurmurHash3_x86_32 value with seed 0 mmh3 API docs: hash(key, seed=0, signed=True), MurmurHash3_x86_32 (read 10 Oct 2026).

This page implements exactly that in JavaScript. We cross-checked it against the Python mmh3 package on 300 random files and two real icons (identical results, including negative values). It also shows the file's SHA-256, because the Censys Query Language lists a favicons.hash_sha256 field Censys docs: Censys Query Language — full-text search, favicons.hash_sha256, html_title example (read 10 Oct 2026).

FOFA also offers icon search, but its syntax documentation could not be read from our test environment, so the FOFA button opens its home page for you to paste the hash rather than a pre-filled search we could not verify.

Which lookup links does it build, and how were they checked?

Every link puts the value through encodeURIComponent, opens in a new tab with rel="noopener", and uses a URL format confirmed from the vendor's documentation or by loading it on 10 October 2026:

• Shodan: shodan.io/search?query= Shodan Help Center: Search Query Fundamentals — search?query= URL examples (read 10 Oct 2026) with the http.favicon.hash, http.html and http.title filters Shodan: search filter reference — http.favicon.hash, http.html, http.title (read 10 Oct 2026).
• Censys: platform.censys.io/search?q= Censys docs: Platform Quick Start — platform.censys.io/search?q= links (read 10 Oct 2026) with full-text queries for IDs and banners and the endpoints.http.html_title field for titles Censys docs: Censys Query Language — full-text search, favicons.hash_sha256, html_title example (read 10 Oct 2026). Censys asks you to sign in to see results.
• PublicWWW: publicwww.com/websites/"ID"/, which searches HTML and JavaScript source PublicWWW: source-code search, /websites/"…"/ query URL (vendor page; checked 10 Oct 2026).
• keys.openpgp.org: the site's own search form (/search?q=) for fingerprints, key IDs and emails. Email lookups only find keys whose owners opted in keys.openpgp.org: VKS API — fingerprint and key-ID lookups, email lookups need owner opt-in (read 10 Oct 2026).
• Ahmia: its clearnet search form requires a hidden token, so a plain ?q= link redirects to the home page. The button opens Ahmia for you to paste the address instead.
• Blockchain explorers: the same mempool.space, Blockstream, Blockchair and Etherscan address URLs used by our Crypto OSINT page.
• Max Intel tools: Email, IP, Domain, Phone and Crypto OSINT pages, each pre-filled with ?q=, and PGP Key Inspector with #fpr=.

Clearnet URLs found on the page are shown as plain text, never as clickable links, so you cannot open a hostile link by accident. Clicking any lookup sends that one value to that third-party site.

Is the pasted page sent anywhere?

No. Text and files are read with the browser's FileReader and scanned in this tab. To read the title, meta tags, favicon references and link targets, the HTML is parsed with DOMParser as an inert text/html document: it is never added to this page, its scripts do not run and its images, frames and stylesheets are not requested. Everything shown is escaped as text. Inputs over 5 MB per file are cut to the first 5 MB (20 MB in total); the structural HTML parse covers the first 2 MB of each file while the pattern scan covers all of it, and the work is split into steps so the tab stays responsive. Nothing is stored after you close the tab.

Is it legal to analyse saved onion pages?

Accessing the dark web is legal in most jurisdictions and many onion services are legitimate, from secure communications to whistleblowing platforms. What crosses the line is engaging in illegal activity, such as buying illicit goods, downloading criminal material or infiltrating criminal networks without authorisation. Stay on public information, never interact with illegal marketplaces or enter credentials, document your methodology, and involve legal counsel for anything sensitive, as set out in our dark-web OSINT guide. Never paste illegal content, such as child sexual abuse material, into any tool; report it to the authorities instead.

How was the extractor tested?

• SHA3-256 and SHA-256 against Node.js's built-in hashes for inputs of 0 to 5,000 bytes, including the 135/136/137-byte block boundaries; Keccak-256 through the eight EIP-55 test vectors.
• The three v3 addresses printed in the Tor specification, 50 addresses generated from random keys, and one-character mutations of each (all rejected).
• BIP-173 and BIP-350 valid and invalid vectors, the Bitcoin genesis address, a P2SH address, the Monero docs' example address, and random Tox IDs.
• The favicon hash against Python's mmh3 on 300 random inputs.
• A synthetic saved page in headless Chromium: expected counts and valid/invalid marks per group, look-alike and v2 flags, no page errors, scripts in the pasted HTML never executed, no image requests, no horizontal scrolling at 375 px, and a 5 MB paste completed with progress updates.

Sources

• Tor Specifications: rend-spec, “Encoding onion addresses [ONIONADDRESS]” (read 10 Oct 2026)
• Tor Project blog: “Onion Service version 2 deprecation timeline”, dgoulet (2 Jul 2020)
• Tor Project Support: Onion Services — 16-character v2 addresses “no longer work”, onion addresses have 56 characters (read 10 Oct 2026)
• Shodan blog: “Deep Dive: http.favicon” — MurmurHash3 of the base64 favicon data (read 10 Oct 2026)
• SANS ISC diary: “Adding some Automation to the favicon.ico method of Host Recon”, Rob VandenBrink (29 Jun 2026)
• Python docs: base64.encodebytes — newline every 76 bytes plus a trailing newline (read 10 Oct 2026)
• mmh3 API docs: hash(key, seed=0, signed=True), MurmurHash3_x86_32 (read 10 Oct 2026)
• Shodan Help Center: Search Query Fundamentals — search?query= URL examples (read 10 Oct 2026)
• Shodan: search filter reference — http.favicon.hash, http.html, http.title (read 10 Oct 2026)
• Censys docs: Censys Query Language — full-text search, favicons.hash_sha256, html_title example (read 10 Oct 2026)
• Censys docs: Platform Quick Start — platform.censys.io/search?q= links (read 10 Oct 2026)
• BIP-173: Base32 address format for native v0-16 witness outputs (assigned 20 Mar 2017)
• BIP-350: Bech32m format for v1+ witness addresses (assigned 16 Dec 2020)
• Bitcoin Wiki: Base58Check encoding — double-SHA-256 checksum, version bytes 0 and 5 (read 10 Oct 2026)
• EIP-55: Mixed-case checksum address encoding (created 14 Jan 2016)
• Monero Docs: Standard address — 95 characters, network byte 18, Keccak-256 checksum (read 10 Oct 2026)
• RFC 9580 OpenPGP (Jul 2024): 8-octet Key IDs; 20-octet v4 and 32-octet v6 fingerprints
• keys.openpgp.org: VKS API — fingerprint and key-ID lookups, email lookups need owner opt-in (read 10 Oct 2026)
• TokTok Tox spec: Tox ID = 32-byte key + 4-byte nospam + 2-byte XOR checksum (read 10 Oct 2026)
• Matrix spec: User identifiers @localpart:domain; matrix.to URIs (read 10 Oct 2026)
• Session: “Session Account ID vs phone numbers” — 66-character Account IDs (8 Jun 2022)
• PublicWWW: source-code search, /websites/"…"/ query URL (vendor page; checked 10 Oct 2026)

Shodan, Censys, PublicWWW and Ahmia descriptions are vendor statements. Lookup links go to third-party sites, which receive whatever value you click.