A favicon hash is the MurmurHash3 checksum of the raw bytes inside a website's favicon file, expressed as an integer that tools like Shodan, Censys, and VirusTotal use to group sites that share the same icon. The hash does not care about your image's filename, alt text, or HTML wrapper — it depends only on the exact sequence of bytes the browser downloads when it requests /favicon.ico or follows the link element you place in your document head. That is why the first step toward a useful hash is producing a clean, predictable favicon file with the exact bytes you intend to ship. A browser-based PNG generator gives you that file without uploading the source image to anyone, which matters when the icon you want to hash is a logo, a personal mark, or a design still under wraps. Once the PNG is on disk, the rest of the workflow is arithmetic: read the bytes, feed them into the MurmurHash3 algorithm, and convert the resulting 32-bit signed integer into the form your recon tool expects. This guide walks through both halves of that workflow, from building the icon to producing a reproducible hash you can paste into a Shodan, Censys, or VirusTotal query.
How a Favicon Hash Is Computed
The favicon hash used by major internet-scanning platforms is a specific application of the MurmurHash3 algorithm, a fast non-cryptographic hash function that turns an arbitrary byte stream into a fixed-size digest. For the favicon use case, the input is the raw decoded content of the favicon file the server returns — not the URL, not the HTML surrounding it, not the page that loads it. The algorithm used by these platforms is the 32-bit x86 variant of MurmurHash3, whose native output is a 32-bit signed integer.
Because the hash is purely a function of the file bytes, two websites return identical hashes only when their favicon files are byte-for-byte identical. A one-pixel color change, a different PNG encoder setting, or an extra metadata chunk can change the hash even when the icons look indistinguishable to a human. That sensitivity is the point: it lets a researcher treat the hash as a unique signature for a specific deployment of an icon.
The canonical hash is the favicon URL that a real browser would request, downloaded in full, and hashed with the standard MurmurHash3 implementation. Different platforms have slightly different conventions for which favicon URL they pull (some use /favicon.ico, some use the first <link rel="icon"> they find), which means the same icon can produce different hashes depending on how the scanner resolves it. When you reproduce a hash locally, the only way to match a third-party database is to control the byte stream end to end.
Why the Favicon File Comes Before the Hash
The hash is a derived value, not something you author. You cannot type a favicon hash into a search box and have it mean anything unless there is a file on a server somewhere that produced it. That is why every workflow that talks about "getting a favicon hash" really starts with the same upstream decision: which favicon file are you going to hash?
A PNG favicon generated locally gives you the cleanest possible answer. The Favicon Generator decodes a PNG, JPEG, or WebP source in your browser tab, draws it through a Canvas resizer, and exports each selected size as a fresh image/png Blob with no extra server round-trip. Because nothing is uploaded, the bytes you download are determined entirely by your source image and the sizes you selected. There is no encoding variation from a shared backend, no transcoding pipeline that might re-compress your PNG between input and output, and no surprise metadata that some image hosts strip silently.
That reproducibility matters because MurmurHash3 is extremely sensitive to byte changes. Two PNG files that look visually identical can still hash to different values if one was saved by a different encoder, at a different compression level, or with a slightly different color profile chunk. Running the generation locally removes the most common source of that variance: the unknown behavior of a remote image pipeline.
Generate the Favicon PNG Locally
The first concrete step toward a favicon hash is producing a square PNG you can hash on disk. The Favicon Generator is the simplest way to do this without uploading anything.
- Pick a PNG, JPEG, or WebP source image whose main subject sits near the center of the frame; the tool accepts files up to 25 MB and rejects decoded images above 40 million pixels, so sources outside those limits are refused before any output is drawn. The generator uses a center-cover crop, so anything important near the corners will be trimmed off before the square is extracted.
- Open the generator and load your source file. The decoder runs entirely in your current browser tab, so the file never leaves your machine.
- Select the square PNG sizes you actually want on disk. The available options are 16, 32, 48, 64, 128, 256, and 512 pixels. For a single, hashable icon, 32×32 is the most commonly cited reference size because it is what most browsers request when a tab is rendered at standard DPI.
- Generate the files. Each selected size is rendered independently from the decoded source at its natural dimensions — the tool does not reuse a small preview as the basis for larger downloads, so the 512×512 file really is a fresh render at 512 pixels.
- Download each PNG and save it with the suggested filename, for example favicon-32x32.png. Keep these files in a folder you control; their bytes are what you will hash.
Once the file is on disk, you have a stable, reproducible input for the next stage. The hash is purely a function of those bytes, so anything you do to the file after this point — renaming, re-encoding, adding metadata — can change the resulting hash.
Turn the PNG Into a Hash Value
With a stable favicon file in hand, computing the hash is a short script away. The community-standard recipe reads the file as raw bytes and feeds them into a MurmurHash3 implementation, then prints the result as a 32-bit signed integer.
The basic shape of the script is:
- Open the favicon file in binary mode and read every byte.
- Initialize MurmurHash3 with the seed value that your target recon platform specifies. Shodan, Censys, and VirusTotal document their seed choice in their respective developer references, and matching that value is required to reproduce a published hash.
- Feed the byte buffer into the hash function.
- Interpret the 32-bit digest as a signed 32-bit integer.
Reference implementations exist in Python, JavaScript, and Go. A typical Python snippet reads the favicon bytes, passes them to the mmh3 library with the signed-integer flag enabled, and prints the resulting integer. The integer is what you paste into a Shodan filter (http.favicon.hash:), a Censys search (favicon.urn:), or a VirusTotal query. Different platforms sometimes wrap the integer in different identifier prefixes, but the underlying value is the same.
Because the hash is just a function of the file, the only way to reproduce a third-party hash is to send the same bytes to the same algorithm. That is why the local generation step above matters: it gives you a known input you can re-hash on demand without depending on a third-party server's encoding choices.
Inspect and Publish the Result
Before you treat the icon as final, open the smallest downloads at actual size. The 16×16 and 32×32 files are where the center-cover crop and the browser's resampling filter are most visible. If the subject is blurry, soft, or unrecognizable at 32 pixels, the file is still valid but the resulting hash will identify a blurry icon — which is rarely what you want.
| Square pixel size | Where it typically surfaces | Typical usage context |
|---|---|---|
| 16×16 | Browser tab, bookmark bar | Address-bar icon in Chrome, Firefox, Edge, Safari |
| 32×32 | High-DPI tabs, Windows taskbar | Retina tab icons, Windows shortcut target |
| 48×48 | Windows site icon | Pinned-site tile, legacy desktop shortcuts |
| 64×64 | macOS dock, larger tiles | Bookmark surfaces and shortcut overlays |
| 128×128 | Chrome Web Store, extension icons | Larger bookmark and app-launcher contexts |
| 256×256 | macOS Finder, modern launchers | App-style icons and high-resolution surfaces |
| 512×512 | PWA store listings, adaptive layers | Store assets and high-density launcher grids |
When the icon looks right, upload the chosen PNG files to the path you want them served from. The HTML the generator produces uses root-relative filenames, so edit the href to match wherever you actually placed the file. If you only need the hash for offline recon and do not plan to publish the icon publicly, skip this step entirely — the hash works the same on a file that never sees a browser.
For a full deployment walk-through that covers manifest files, root paths, and cache-busting, see how to get a favicon set up on your website.
Troubleshooting the Most Common Hash Mismatches
When the hash you compute locally does not match what a recon platform reports, the cause is almost always a byte difference. The MDN reference for the rel="icon" attribute documents the exact link shape the HTML generator emits, including the type="image/png" attribute and the sizes token, but the hash itself is unrelated to that HTML — it is purely a function of the file the link points to.
| Capability | In scope | Out of scope |
|---|---|---|
| PNG, JPEG, WebP source input | Yes | — |
| ICO container output | — | Yes |
| SVG favicon output | — | Yes |
| Apple touch icon output | — | Yes |
| Web app manifest generation | — | Yes |
| MurmurHash3 computation | — | Yes |
| <link rel="icon"> snippets | Yes | — |
| Server upload of the source image | — | Yes |
The most common mismatch is that you hashed a file that was re-encoded by your CDN, image host, or hosting provider after upload. Re-download the file from the public URL with curl or wget and hash the result — that is the byte stream the recon platform saw. The second most common mismatch is that you hashed a different size than the platform defaults to; most scanners try the smallest declared sizes value first, so a 16×16 hash and a 32×32 hash of the same logical icon will be different values.
A third mismatch source is the center-cover crop. If your source image has its subject off-center, the generator trims equal amounts from the long edges to make the square. The resulting icon is correct, but if you were trying to reproduce the hash of a slightly different icon, the cropped output will not match. Pre-crop the source in an image editor if you need exact byte parity with a reference favicon.
Finally, clear your browser cache and any service-worker caches after deploying a new favicon — otherwise your local browser will keep showing the old icon, which can make it look like the hash has not changed even though the bytes on the server have. The hash is honest about the bytes; the only question is which bytes you are actually looking at.