How do you decrypt a SHA-256 hash back to the original input?
Short answer
You don't — cryptographic hashes are one-way functions with no inverse. 'Cracking' a hash means guessing candidate inputs, hashing each, and comparing (dictionary, brute force, rainbow tables), which is exactly why slow salted hashes are used for passwords. There is no key that 'decrypts' a hash. If something can be decrypted it was encrypted, not hashed — and Base64 is reversible encoding, not hashing.
This is a classic junior trap. The phrase "decrypt a hash" sounds reasonable but is a category error: hashing and encryption are different operations, and only one of them is reversible.
Hashing is one-way by design
SHA-256 maps an input of any size to a fixed 256-bit digest by repeatedly mixing and compressing the data. The function deliberately throws information away — many different inputs map to the same length output — so there is no mathematical inverse to run. This property is called preimage resistance: given a digest, you can't compute an input that produces it. There is also no key involved, so there is nothing to "decrypt with."
What "cracking" actually does
When tools appear to "reverse" a hash, they are guessing. The first step is recognizing the algorithm — an online hash identifier does exactly that — after which the attacker takes candidate inputs — words from a dictionary, mutations, or brute-forced strings — hashes each one, and checks whether the digest matches. A rainbow table is just this guessing done in advance and stored cleverly. None of this inverts the function; it searches the input space. That is precisely why passwords are stored with slow, salted hashes (bcrypt, scrypt, Argon2): to make each guess expensive.
Encryption vs. encoding vs. hashing
The distractors lean on three confusions:
- Encryption is reversible with a key (AES, RSA). If you can decrypt it, it was encrypted, not hashed.
- Encoding like Base64 is reversible with no key — it's a representation change, not security at all. Decoding Base64 never recovers a hashed input.
- Hashing is one-way and keyless.
The "apply the inverse round function" answer is also wrong: SHA-256's compression function is not invertible in a way that recovers the message, and knowing the block size buys you nothing.
The right interview answer
State plainly that you cannot decrypt a hash because it has no inverse and no key; the only path is to guess and compare. Then add the security implication: because guessing is the only attack, defenders make guessing slow and per-record unique with adaptive salted hashes.
Likely follow-ups
- What is the difference between encryption, encoding, and hashing?
- How do rainbow tables 'reverse' a hash if hashing has no inverse?
- Why does a salt slow down attacks that crack many hashes at once?