The git object hash calculator reproduces the exact SHA-1 identifier that git assigns to an object. Git does not hash file content directly: it first wraps the content in a tiny header, then hashes header-plus-content. This tool builds that header and runs SHA-1 so you get the same 40-character hash as git hash-object.
How it works
Every git object is stored as the bytes type SP length NUL content, where type is blob, tree, commit or tag, SP is a space, length is the decimal byte length of the content, and NUL is a single zero byte (\0). Git computes the SHA-1 of that whole sequence and uses the hex digest as the object’s name.
For example, an empty blob has content of length 0, so the hashed bytes are blob 0\0 — which always produces e69de29bb2d1d6434b8b29ae775ad8c2e48c5391, a hash any git user has seen. The calculator encodes your text as UTF-8 to get the byte length, prepends the header, and runs a self-contained SHA-1 implementation so the result is deterministic and offline.
Worked examples
Example 1: A simple file with a trailing newline
Content: "hello\n" (6 bytes including the newline)
Header: blob 6\0
SHA-1 of header+content = ce013625030ba8dba906f756967f9e9ca394464aVerify on the command line: printf 'hello\n' | git hash-object --stdin
Example 2: The empty blob
Content: "" (0 bytes)
Header: blob 0\0
SHA-1 = e69de29bb2d1d6434b8b29ae775ad8c2e48c5391This is one of the most recognisable hashes in git — the empty file hash that appears in diffs whenever a new empty file is committed.
Example 3: The same content without the trailing newline gives a different hash
Content: "hello" (5 bytes — no newline)
Header: blob 5\0
SHA-1 = b6fc4c620b67d95f953a5c1c1230aaab5db5a1b0This illustrates why exact byte content matters — a missing trailing newline is a different blob.
When is this useful?
- Debugging a “file already exists” error. When git complains about a blob already in the object store, you can verify which commit introduced that exact byte sequence.
- Verifying content integrity. Compare the SHA-1 of a file you received against the hash stored in a tree object to confirm it has not been modified in transit.
- Understanding how git addresses objects. Knowing that a SHA-1 covers the header and content — not just the content — explains why two files with the same bytes always share a blob, and why git deduplicates storage across commits automatically.
- Writing custom git tools. If you are building a tool that reads or writes git’s object store directly, you need to compute hashes that match git’s own output.
Object types
| Type | Content | Used for |
|---|---|---|
blob | Raw file bytes | File content at a specific version |
tree | List of blob/tree references with mode and name | Directory snapshot |
commit | Author, committer, tree hash, parent hashes, message | A commit |
tag | Tagger, tagged object, message | Annotated tag |
The blob type is by far the most common use case for this calculator. If you want to reproduce a commit or tag hash, paste the canonical text of that object’s body — you can inspect it with git cat-file -p <sha> on the command line.
Notes
Byte length, not character count, drives the header — multi-byte UTF-8 characters and trailing newlines change the byte count and therefore the hash, so paste the content precisely as it would be stored in the file. Everything runs locally; your content is never uploaded.