SHA-256 for designers: why one pixel changes a file hash

By the logoBlockchain team · 9 November 2026 · 6 min read

SHA-256 shows up everywhere once you start protecting design files: in timestamp services, in registries, in download pages that say “verify the checksum.” You do not need to be a programmer to understand it or use it. This guide explains what a SHA-256 hash is, why changing one pixel changes the whole thing, why two files that look identical can have different hashes, and how to compute a hash yourself on any computer.

What a hash is, in one paragraph

A hash function takes any amount of data — a word, a logo file, a whole video — and produces a fixed-length fingerprint. SHA-256 is one specific, widely used hash function, standardized by the US National Institute of Standards and Technology in the Secure Hash Standard (FIPS 180-4). Its output is always 256 bits, usually written as 64 hexadecimal characters (the digits 0–9 and letters a–f). The same input always gives the same output, on any computer, with any software that implements the standard correctly.

For example, the SHA-256 of the text Northwind is:

f99297d29d2aabe6cfe7470884f1a38abb589a3047f21c1a67683bef77464035

Type the same word into any SHA-256 tool and you will get exactly that string. (It is also the starting point of the default logo on our generator, which turns a hash like this into shapes, colours, and type.)

The four properties that matter

For a designer, four properties of SHA-256 explain almost everything you will run into:

Deterministic. Same bytes in, same hash out. There is no randomness and no secret key.
Fixed size. A 2 KB icon and a 2 GB video both produce 64 hex characters. The hash is a fingerprint, not a compressed copy; you cannot rebuild the file from it.
Extremely sensitive. Change one bit anywhere in the input and, on average, about half of the output bits flip. The new hash looks completely unrelated to the old one. Cryptographers call this the avalanche effect.
Practically impossible to reverse or collide. No one knows a practical way to find an input that produces a chosen hash, or to find two different inputs with the same SHA-256. That is what makes a hash usable as evidence: if your file’s hash was recorded at a certain time, it is not realistic for someone to later produce a different file with the same hash.

Why one pixel changes everything

Look at how small changes to a word affect its hash:

Input	SHA-256 (first 16 characters)
`Northwind`	f99297d29d2aabe6…
`northwind` (lowercase n)	84e2cdb7a166d167…
`Northwind` (trailing space)	13f14798c2e10f9d…

There is no pattern a human could use to tell that these inputs are almost the same. Images behave the same way, because a hash function does not see “an image” at all — it sees a sequence of bytes. In a small test we made a 64×64 pixel PNG filled with one purple colour, then changed the blue value of a single pixel by one step (from 245 to 246). The file hashes were:

original:      789475d4519cac72e076747b17405109c469f8b5c8ecd2f14535422579bfddcf
one pixel off: fb24f5f411844b2b8c52f2ac9f754067a845aeebebcb8cd8db16e29fa47858ff

Nobody could see that difference on screen. SHA-256 treats it as an entirely different file. That is exactly the point: a hash records this exact file, not “something like it.”

Same look, different bytes

The flip side surprises many designers: two files can look pixel-for-pixel identical and still have different hashes. In the same test, we re-saved the original purple square with a different PNG compression level. Every pixel was unchanged — we checked — but the file hash became:

re-saved:      3fb1f154b5e8065455918bdbf1f6ee548fc87d6339cef3c9e68add2be86eee42

Common things that change the bytes without changing what you see:

Re-exporting from a design tool, even with the same settings. Tools may write a different timestamp, software version, or element order.
Compression settings in PNG, WebP, or JPEG, and “optimizer” tools that shrink files.
Metadata: colour profiles, EXIF data, author fields, creation dates embedded inside the file.
SVG formatting: SVG is text, so a different number of decimal places, a changed attribute order, an extra line break, or a comment all change the hash.
Platforms: uploading to a website, chat app, or social network almost always re-encodes images. The copy you download back is not the file you uploaded.

The practical rule: decide which file is the master, hash that one, and never re-save it. If you need a smaller or different version, make a new file and, if it matters, hash that too.

How to hash a file yourself

Every major operating system can compute SHA-256 without installing anything. Replace logo.svg with your file name (dragging a file into a terminal window usually types its full path for you).

macOS

Open Terminal and run:

shasum -a 256 logo.svg

Linux

sha256sum logo.svg

Windows

In PowerShell, Get-FileHash uses SHA-256 by default:

Get-FileHash .\logo.svg -Algorithm SHA256

Or, in the older Command Prompt:

certutil -hashfile logo.svg SHA256

Each command prints a 64-character hash. Tools may show it in upper or lower case; that does not matter, A and a mean the same hexadecimal digit.

In a browser

Modern browsers include SHA-256 in the Web Crypto API, which is how logoblockchain hashes your file without uploading it. When you drop a file on the register or verify page, the hash is computed on your device and only the result is sent. You can compare it with the hash from the commands above; they should match exactly.

Using hashes in a design workflow

Proving a file existed. Record the hash with a timestamp service and keep the file. Later, anyone can re-hash the file and compare. Our guide on how to prove you created a logo covers the full routine.
Checking a hand-off. When you send final files to a client or printer, include the hashes in the delivery note. If the hashes match on their side, the files arrived intact and unchanged.
Spotting accidental edits. If the hash of your “final” file has changed, something re-saved it. Better to find out now than when you need it.
Organising versions. A hash is a reliable name for a specific version. File names like logo-final-FINAL-2.svg are not.

When you need a perceptual hash instead

Because SHA-256 reacts to every byte, it cannot answer “is this the same logo, resized?” For that, logoblockchain also computes a perceptual hash. Ours is a 64-bit “difference hash” (dHash): the image is shrunk to a 9×8 grid of greyscale values, and each bit records whether a cell is brighter than its neighbour to the right. Resizing or mild recompression usually leaves most of those 64 bits unchanged, so similar images get similar perceptual hashes. The verify page lists registrations whose perceptual hash differs by 10 bits or fewer.

The two hashes do different jobs. SHA-256 answers “is this exactly the file?” with near certainty. A perceptual hash answers “does this look roughly like that?” — useful for finding look-alikes, but approximate, and never a judgement about whether two logos are legally confusing.

Common misunderstandings

“The hash is encrypted logo data.” No. A hash contains no recoverable image. Publishing the hash does not publish the logo.
“If I rename the file, the hash changes.” No. The file name is not part of the file’s bytes; renaming does not change the SHA-256. Moving or copying it does not either.
“A similar logo will have a similar SHA-256.” No. Similar inputs have unrelated SHA-256 hashes. Similarity is the job of a perceptual hash.
“A hash proves who made the file.” No. It identifies the file. Who made it is shown by other evidence — drafts, source files, correspondence.
“SHA-256 is a blockchain thing.” Bitcoin uses it, but SHA-256 predates Bitcoin and is used throughout everyday computing, from software downloads to secure websites.

Once you have hashed a few of your own files, the idea becomes intuitive: a hash is a name that belongs to exactly one sequence of bytes. Keep the bytes, and the name will always point back to them.