How long is a SHA-256 hash?

You are sizing a database column, or filling in a form field that rejected what you pasted, or looking at a digest in a ticket and wondering whether somebody clipped the end off it. A SHA-256 digest is 64 hexadecimal characters — 256 bits, 32 bytes, three ways of saying the same thing — and it is 64 characters for an empty file just as surely as for a feature film.

The thing that trips people up is the name. The 256 counts bits of output, not characters, so the digest comes out at twice the length you might expect from the number on the label. Everything else about digest lengths follows from that one conversion, including the lengths of the other seven algorithms you are likely to meet.

Bits, bytes and characters

A hash function's output is a fixed number of bits, and every other figure is derived. Divide the bits by eight for bytes; divide by four for hexadecimal characters, because each character carries exactly four bits. SHA-256: 256 bits, 32 bytes, 64 characters. That is the whole calculation, and it works for every algorithm in the table below.

Strictly, the digest is the 32 bytes. The 64 characters are a way of writing those bytes down in a form that survives being emailed, pasted into a terminal, used in a filename and read aloud over the phone. Hexadecimal wins that job because it is fixed-width, unambiguous, and indifferent to case — A3 and a3 are the same byte, which is not true of base64, where case carries meaning.

So when somebody asks how long a SHA-256 hash is, the honest answer depends on what they are measuring. If it is a text field, 64. If it is a binary column or a network packet, 32. Those are the same digest.

Every digest length in one table

Two lines in that table share a length with another, and the consequence matters: length tells you the output size, not which function produced it. A 64-character value is SHA-256 or SHA3-256, and nothing about the characters themselves will separate the two — they are both just 32 random-looking bytes. The same goes for 128 characters, which is SHA-512 or SHA3-512. If that is your actual question, identifying which algorithm a checksum came from is the page that settles it.

A few lengths outside that table turn up occasionally. SHA-224 gives 56 characters. SHA-512/256 gives 64 — it is SHA-512 run with a different starting state and cut to 256 bits, a standardized variant rather than somebody trimming a digest by hand. BLAKE2 and BLAKE3 at 256 bits also produce 64 characters. None of those is interchangeable with SHA-256; they just happen to be the same width.

The length never changes, whatever you hash

This is the defining property of a hash function rather than a quirk. Input of any size, output of exactly one size. A 12-byte text file and a 120 GB video both come out as 64 characters, which means a digest carries no information whatsoever about how large the thing was — and no route back to the contents, because 32 bytes cannot hold a film.

Two practical consequences follow, and both save real trouble.

• In a schema, the width is fixed. Use CHAR(64) for hex or BINARY(32) for the raw bytes; there is no case for a variable-length type, because the length never varies. The binary form halves the storage and the index, which is worth caring about at a hundred million rows and worth ignoring below a million. Whichever you pick, normalize to one case on the way in, so a lookup never misses because something arrived in capitals.
• On screen, the width is the problem. Sixty-four monospaced characters do not fit in a table cell beside anything else, so digests get shortened for display — and the right way is to cut out the middle rather than the end, because the tail is the part people check by eye. That is why Rocket Hash shows a long digest with an ellipsis through the middle, and why copying a row gives you the digest rather than the abbreviation. Copying digests out in one go covers the forms that travel well.

Other ways the same digest gets written down

Hexadecimal is conventional, not compulsory. The same 32 bytes arrive in several other costumes, and each has its own character count — which is the usual reason a digest looks the wrong length.

The 44 is worth understanding rather than memorizing. Base64 packs three bytes into four characters, and 32 bytes is not a multiple of three — so the last two bytes are padded out to a full group, producing 43 significant characters and one =. That is why a SHA-512 digest in base64 comes to 88 characters and a SHA-1 digest to 28: the arithmetic, not a convention.

You will also meet prefixes. A value written sha256: followed by 64 characters is a container image digest or similar, and the prefix is a label rather than part of the value. Strip it before comparing anything, along with any stray whitespace. The format of a SHA256SUMS file explains the other common wrapper, where the digest is followed by two spaces and a filename.

How much of a digest can you safely cut off

Sixty-four characters is unwieldy in a log line, a URL or a conversation, so people shorten them. Git does it by default, and nobody types out a full object hash. The question is how much you can drop before the short form stops being useful, and the answer is arithmetic rather than taste.

Accidental collisions start appearing once the number of items reaches roughly the square root of the number of values the short form can take — the birthday bound, and it arrives much earlier than intuition suggests:

• 7 hex characters — 28 bits, so clashes around 16,000 items. This is Git's traditional abbreviation, and it is exactly why Git lengthens it automatically as a repository grows.
• 16 hex characters — 64 bits, so clashes around four billion items. Comfortable for naming build artifacts or cache keys.
• 32 hex characters — 128 bits, so no accidental collision you will ever witness.

Those numbers describe accidents, not opponents. Truncating also cuts the effort required to construct a deliberate match, so a shortened digest belongs in a reference or a file name and never in a security decision. Where a shorter value is genuinely required for that, use a standardized truncated variant rather than chopping characters off — NIST's guidance is to take the leftmost bits, which is precisely what the variants do. And if you are using digests to tell files apart at volume, keep the whole thing: finding duplicates by hash depends on a value wide enough that two unrelated files never share it.

Troubleshooting

My digest is one character too long

Something invisible came along with the copy. A trailing newline, a space, a non-breaking space out of a web page, or a zero-width character are all candidates, and a field that counts characters will reject the value while your eyes see nothing wrong. Paste it into a plain text box and check the count, or retype the last few characters by hand. If the figure is 65 or 66 rather than 64, it is almost never the digest that is wrong.

My database column is cutting digests short

A column sized for an earlier era does this silently. CHAR(32) was right for MD5 and CHAR(40) for SHA-1, and either will accept a SHA-256 digest and quietly keep the front of it. The symptom is unmistakable once you look: every stored value ends at exactly the same position, and nothing ever matches. Widen the column and re-hash the source data, because a truncated digest cannot be repaired — the missing characters were never written.

The value I was given is 44 characters

That is the same digest in base64 rather than hex, and the trailing = is the giveaway. Convert one side before comparing: decode the base64 to 32 bytes and print them as hex, or encode your hex value the other way. Do not compare the two forms character by character and conclude the file is corrupt. Other unexpected lengths are worth running past the digest-length table for every algorithm.

Two values share their first eight characters

With eight characters you are comparing 32 bits, and 32 bits collide by accident somewhere around 65,000 items, so a shared prefix in a large list is ordinary rather than alarming. Compare the full 64 before concluding anything about either file. If a tool is showing you only a prefix, that is a display decision and the complete value is still there underneath.

A form will only accept 32 characters

It was built for MD5 and never revisited. You cannot shorten a SHA-256 digest to fit it — the result would not be a valid MD5 of anything — so either supply the MD5 the form is actually asking for, and accept what that does and does not prove, or ask for the field to be widened. Generating a SHA-256 on a Mac and generating an MD5 are the same operation over the same bytes, so producing both while the form catches up costs nothing.

Frequently asked questions

What does a SHA-256 hash look like?

A single unbroken run of 64 characters drawn only from 0–9 and a–f, with no spaces, punctuation or other symbols. Case carries no meaning, so the same digest is equally valid in capitals. The SHA-256 of an empty input is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is a fair illustration of the shape.

Why is a SHA-256 hash 64 characters and not 32?

Because the 256 in the name counts bits, and hexadecimal needs two characters for every byte. 256 bits is 32 bytes, and 32 bytes written in hex is 64 characters. If you were expecting 32 you were reading the byte count, which is the same digest measured differently.

How many bytes do I need to store a SHA-256 hash?

32 bytes if you store the raw digest, or 64 if you store it as hexadecimal text. In a database that means BINARY(32) or CHAR(64) — a fixed-width type either way, because the length never varies. The binary form halves both the storage and the index size, which only starts to matter at very large row counts.

Can I shorten or truncate a SHA-256 hash?

For reference purposes, yes — keeping the leftmost characters is how Git's short hashes work. Accidental collisions arrive at roughly the square root of the number of values the short form can take, so 16 characters is safe into the billions and 7 characters starts clashing in the tens of thousands. Never truncate for a security decision: use a standardized shorter variant instead of cutting one down.

How long is a SHA-512 hash compared with SHA-256?

128 hexadecimal characters against 64 — 64 bytes against 32, exactly double. SHA-384 sits between them at 96 characters, and MD5 and SHA-1 are shorter at 32 and 40. Whether the extra width buys you anything is a separate question, covered in SHA-256 against SHA-512.

Does a larger file produce a longer hash?

No. Fixed output size is the whole point of a hash function: anything you feed it comes back as the same number of characters. That also means the digest tells you nothing about the original size, and that there is no way to reconstruct the file from it.

How long does it take to generate a SHA-256 hash?

For text, no perceptible time at all. For a file, the limit is almost always how fast the disk can supply the bytes rather than the arithmetic — SHA-256 runs at roughly 2 GB/s on Apple Silicon, which outpaces most drives. Reading the throughput and time remaining covers what to expect from a long job.