githash home

How githash works

What it does

githash gives you per-file git blob hashes for any GitHub commit, and lets you pivot any file into VirusTotal by its raw SHA-256. Two hashes per file, two different jobs:

git blob SHA — identifies a file's bytes across all of GitHub. Great for cross-repo dedup ("does this exact file appear anywhere else?").
SHA-256 of raw bytes — what VirusTotal and most security tools index. Computed on first click; cached forever.

Using the search bar

One input does two jobs depending on what you paste:

GitHub repo: owner/repo, owner/repo@ref, or any https://github.com/… URL → ingests the commit and renders its file tree.
Git blob hash: 6–40 hex chars → finds every ingested file with these exact bytes.

If a hex prefix uniquely resolves to one blob, the URL auto-extends to the full 40-char SHA so the link you share is unambiguous.

Swap github.com → githash.org

You don't have to copy a repo into the search bar at all. Take any GitHub repo URL in your address bar and change the host from github.com to githash.org — leave the rest of the path untouched. githash reads the path, ingests that exact commit, and renders the file tree:

github.com/octocat/Hello-World
        ↓  (just change the host)
githash.org/octocat/Hello-World

The same path forms GitHub uses all carry over, so whatever page you're looking at maps cleanly:

repo root: githash.org/owner/repo → the default branch (HEAD)
branch / tag: githash.org/owner/repo/tree/main → that ref, resolved to a commit
exact commit: githash.org/owner/repo/commit/<sha> → that immutable snapshot
release tag: githash.org/owner/repo/releases/tag/v1.0.0 → the tagged ref
a single file: githash.org/owner/repo/blob/main/path/to/file → ingests the repo and opens that file's details panel

githash always ingests the whole repo at the given ref — a /blob/… URL just auto-opens the one file you pointed at. Tip: in the browser address bar you can edit only the github.com part and hit enter.

Once the page loads, githash rewrites the URL to a canonical hash route pinned to the resolved commit SHA (see how refs work), so the link you copy afterward won't drift.

Browsing a repo

The file tree mirrors the repo at the ingested commit. Folders collapse and expand. Click any file row to open its details panel:

path, size, blob sha — all from GitHub's trees API, free at ingest
sha-256 — computed on demand the first time you expand the row, cached after
View on GitHub — deep link to the file at this commit
View on VirusTotal — opens VT at the file's SHA-256 (computes if needed)
Search Blob — switches to the blob view, showing every other place the same file bytes appear

Cross-repo dedup

Two files with identical bytes have identical git blob SHAs — that's git's content-addressing guarantee. githash keys on the blob SHA, so the same jQuery file dropped into 100 repos shows up as one blob entry with 100 occurrences. Click "Search Blob" on any file to see those occurrences (owner/repo, commit, path) and deep-link into each.

How refs work (and why it matters)

GitHub refs — branches and tags — are mutable pointers, not snapshots. The same v1.0.0 tag might point to a different commit today than it did last month. main moves every time someone pushes. HEAD tracks whatever the default branch happens to point at.

Commit SHAs, on the other hand, are immutable. A commit SHA is a cryptographic hash of the snapshot, so it can never quietly change meaning.

When you ingest owner/repo@v1.0.0, githash resolves the ref to a commit SHA at that exact moment and stores both. Every subsequent ingest re-resolves the ref and records what we see. If the ref now points somewhere different than last time, we flash a warning on the page:

⚠ ref "v1.0.0" moved Previously pointed at abc123… (last seen 2025-08-04). Now resolves to def456….

Treat that banner as a meaningful signal. The file contents at v1.0.0 today are not what they were last week — the tag overlaps but the bytes diverge. Common causes:

A maintainer force-pushed a fix to an existing tag (sometimes a quiet security patch)
A tag was re-cut from a different branch
The repo was rewritten or rebased

Canonical links

After every ingest, githash rewrites the URL to use the resolved commit SHA, not the ref. Share that:

#/repo/octocat/Hello-World@7fd1a60b01f91b314f59955a4e4d4e80d8edf11d

Anyone opening it sees the exact same bytes you did. A link with @main drifts the next time someone pushes.

The two hashes, explained

Every file has two fingerprints. They look alike but answer different questions — and mixing them up is the most common trip-up, so here's the plain version.

Git blob SHA — “is this the exact same file?”

The 40-character hash git uses to identify a file's contents. Two files with the same git blob SHA are byte-for-byte identical — that's how githash spots the same file showing up across different repos. It's the hash shown throughout the file tree, and the one the search bar matches when you paste a hash.

⚠ Don't paste this into VirusTotal. A git blob SHA isn't the hash VirusTotal uses, so it won't find your file there. For that, use the SHA-256 below — or just click View on VirusTotal on any file and githash sends the right one.

SHA-256 — “what do security tools call this file?”

The 64-character hash that VirusTotal and most security tools use to look up a file. GitHub doesn't provide it, so githash calculates it for you. The first time anyone needs a given file's SHA-256 there's a brief pause while it's computed; after that it's saved and instant for everyone.

githash also works ahead in the background, pre-computing SHA-256s for files already in its index — so by the time you click, most are ready. The badge at the top of the page shows how far along that is.

Limits and gotchas

10 MB blob cap. Files larger than this aren't fetched or hashed; the trees-API size lets us skip them without trying.
100k entries / 7 MB tree cap. GitHub truncates the trees response for very large repos. We surface a banner and show the partial file list.
Submodules are skipped. They're gitlinks to other repos, not files in this one. Ingest the target repo separately.
Symlinks are stored but flagged. VirusTotal pivot is disabled — a symlink blob's "content" is the target path string, not a real file.
One ref at a time. Each ingest captures the commit a ref resolves to right now. To compare two points in time, ingest both commit SHAs explicitly.

Privacy + data

githash only knows about public GitHub repos that someone has explicitly ingested through this tool. Nothing is crawled. File contents are fetched only when needed for SHA-256 computation and aren't stored — only the hashes, sizes, and paths. We do log each search and ingest (including IP address) for rate-limiting and abuse prevention.

For the full details, see the Privacy Policy and Terms of Service.

← back to home