SHA-1 hash generator

Paste text and get its SHA-1. Almost nobody chooses SHA-1 any more — people produce one because something else insists, and that something is usually Git, an old signing scheme, or an integration written before 2017. The page is written for that reader rather than for somebody picking an algorithm.

Result

The answer appears here as you type.

  • Where it runs

    Nothing is uploaded, because there is no file — it is worked out in this page.

  • No queue, no account

    It answers as fast as your machine can, and it never asks who you are.

  • As often as you like

    Nothing is counted and nothing is capped — answering again costs us nothing.

How it works

  1. Paste the text into the box. The digest appears as you type.
  2. Switch the case if the system you are matching uses the other one.
  3. Copy the forty characters. Nothing was uploaded.

Broken in 2017, and what was actually demonstrated

Researchers at CWI and Google published SHAttered: two different PDF files with the same SHA-1. It cost around 6,500 CPU-years at the time, which sounds prohibitive and was not — it was rented. Three years later a chosen-prefix collision was demonstrated for roughly the price of a used car, and the cost has fallen since.

A chosen-prefix collision is the dangerous kind: it lets an attacker start from two meaningful documents rather than two blobs of noise. That is the point at which a hash function stops being usable for signatures, and it is why certificate authorities stopped issuing SHA-1 certificates and browsers stopped accepting them.

Git uses it, and Git is not broken

Every Git object is named by its SHA-1, which sounds alarming and mostly is not. Git prefixes each object with its type and length before hashing, and since 2017 it has shipped a collision detection routine that rejects the known attack — so producing a colliding object is far harder than producing a colliding file.

The migration to SHA-256 is nonetheless real and slow: the format supports it, and the transition is held up by every tool, host and script that assumes forty characters. If you are computing a Git object id by hand, SHA-1 is still the answer, and it will be for some years.

What forty characters are still fine for

The same things MD5 is fine for, with more margin: detecting accidental corruption, deduplicating content, generating a stable identifier for something where nobody benefits from a clash. A collision has to be constructed, and nothing constructs one by accident.

The practical rule is the same as everywhere else on this site. If there is somebody who gains by two different inputs matching, SHA-1 is finished. If there is not, it is a perfectly serviceable checksum that happens to be forty characters long.

Where you will still meet it

Git object ids. HMAC-SHA1 in older API signing schemes — AWS Signature Version 2, OAuth 1.0, and a long tail of internal integrations that copied one of them. `git describe` output, CI systems keyed on commit ids, and any database column somebody sized at forty characters a decade ago.

HMAC-SHA1 is worth separating out: HMAC is a construction that does not depend on the hash being collision-resistant, so HMAC-SHA1 is not broken in the way plain SHA-1 signatures are. It is still not what a new system should use, but it is not the emergency that a SHA-1 certificate would be.

Telling the digests apart

SHA-1 is forty hexadecimal characters. MD5 is thirty-two, SHA-256 is sixty-four, SHA-512 is a hundred and twenty-eight. Counting is the quickest way to identify a digest handed to you without documentation, and it is worth doing before assuming which algorithm a system uses.

It is also how a stale integration announces itself. A field documented as SHA-256 holding forty characters is holding SHA-1, and that is not a formatting quirk — it means something in the chain was never updated when the documentation was.

SHA-1 hash generator: common questions

Is SHA-1 safe to use?

Not for anything where somebody benefits from two inputs matching — signatures, certificates, verifying a download from an untrusted source. A chosen-prefix collision has been demonstrated and is now affordable. For accidental corruption and deduplication it remains perfectly serviceable.

If SHA-1 is broken, is Git broken?

No. Git prefixes each object with its type and length before hashing, and since 2017 ships collision detection that rejects the known attack, so a colliding object is much harder to produce than a colliding file. The move to SHA-256 is under way and is held up by tooling rather than by cryptography.

Is HMAC-SHA1 also broken?

Not in the same way. HMAC does not rely on the hash being collision-resistant, so HMAC-SHA1 is not in the state that SHA-1 signatures are. It is still not what a new system should choose, but an existing integration using it is not an emergency.

How long is a SHA-1 hash?

Forty hexadecimal characters, always, whatever the input length. That number is the quickest way to tell it apart from MD5 at thirty-two and SHA-256 at sixty-four when you are handed a digest with no documentation.

Does the text leave my browser?

No. The digest comes from your browser own cryptography, running in this page, and nothing is sent. Legacy signing values are exactly the sort of thing people paste into a hash tool, and exactly the sort of thing that should not be handed to a third party.

Other tools