Short answer: hashing maps bytes to a fixed-length digest and has no decryption operation. Encryption uses a key to transform plaintext into ciphertext that an authorized party can recover. A bare hash does not keep data secret or prove who created it. Modern authenticated encryption can protect confidentiality and integrity; HMAC and digital signatures authenticate without necessarily encrypting. Base64 is only reversible encoding.

Hashing, encryption, encoding, and authentication compared

OperationPrimary purposeReversible?Secret material?Typical output
Cryptographic hashDigest exact bytesNo decryption operationNoFixed-size digest
Password KDFSlow password verificationNo decryption operationPassword plus salt; optional pepperParameterized verifier
Authenticated encryptionConfidentiality and integrityYes with the key after authentication succeedsEncryption key and unique nonce policyCiphertext and authentication tag
HMACShared-secret message authenticationMessage is not encoded by the MACShared keyAuthentication tag
Digital signaturePublicly verifiable origin and integrityMessage remains separatePrivate signing key; public verification keySignature
Base64Binary-to-text representationYes without a keyNoPrintable ASCII text

What cryptographic hashing does

A cryptographic hash such as SHA-256 accepts an arbitrary byte sequence and produces a fixed-size digest. Identical bytes produce identical output. A small change to the input normally changes many digest bits, and a well-designed current function makes it computationally difficult to find an input for a chosen digest or two distinct inputs with the same digest.

Because infinitely many possible inputs map to a finite digest space, information is necessarily lost. There is no key that restores the original. That does not mean every source is unknowable: if an input comes from a small set such as common passwords, six-digit codes, email addresses, or predictable identifiers, an attacker can hash candidates and compare them.

Hashing is useful for file checksums, immutable content identifiers, deduplication, cache keys, Merkle structures, and as a component inside HMAC, digital signatures, and password KDFs. The surrounding construction supplies context a bare digest lacks. For example, an ordinary file checksum detects a mismatch only relative to an expected value; it does not say where that expected value came from.

What encryption does

Encryption protects confidentiality by transforming plaintext with a key. Symmetric encryption uses the same secret key, or closely related secret material, for encryption and decryption. Public-key encryption lets a sender encrypt to a public key so the holder of the corresponding private key can decrypt. Key generation, distribution, rotation, storage, and destruction are part of the security problem.

Current applications should generally use a reviewed authenticated-encryption scheme, such as AES-GCM or ChaCha20-Poly1305 in an appropriate protocol and library. Authenticated encryption returns ciphertext plus a tag and refuses to release plaintext when verification fails. Nonces must follow the scheme's uniqueness requirements; reusing a nonce with the same key can catastrophically weaken some modes.

Encryption does not make untrusted data safe to parse after decryption, does not authorize the recipient to perform an action, and does not conceal every form of metadata. Length, timing, endpoints, and access patterns may remain visible. The protocol must define associated data, key identity, replay handling, versioning, and error behavior.

Passwords need a dedicated one-way verifier

An application usually needs to check a password later without recovering the user's original password. Reversible encryption would create a master key whose compromise exposes every stored password. A fast hash such as SHA-256 or MD5 avoids a decryption key but lets a database thief test enormous numbers of guesses offline.

Password-hashing KDFs deliberately make each guess expensive. Prefer Argon2id where available, or use scrypt, bcrypt, or PBKDF2 when platform, compatibility, or compliance constraints require them. Generate a unique random salt for every verifier and store it with the algorithm identifier, cost parameters, and derived value. A salt is public; it prevents shared lookup work and identical-password equality, but does not replace adequate cost.

Calibrate parameters on the real authentication infrastructure, enforce password and breached-credential policy, rate-limit online guesses, and upgrade parameters after successful logins. A server-side pepper may add a separate defense when managed in a secret store, but its lifecycle and outage behavior need deliberate design.

Why a hash is not an HMAC or signature

Anyone can calculate SHA-256 over any message. If Alice sends a message and an unkeyed digest over a channel Mallory can modify, Mallory can replace the message and calculate a matching digest. The value may detect accidental transmission errors but offers no evidence that Alice approved the bytes.

HMAC combines a cryptographic hash with a secret key through a standardized construction. A verifier who knows the shared key can check that the message and tag agree. HMAC does not provide public verification because every verifier able to validate can also create tags. Use a constant-time comparison function supplied by the platform.

A digital signature uses a private key to sign and a public key to verify. It can support public or multi-party verification when key identity is established correctly. Signature algorithms define message preprocessing, domain separation, encoding, and verification rules; do not sign an ad hoc hash without following the complete scheme.

Base64 and hexadecimal are not security controls

Base64 converts bytes into a printable alphabet, while hexadecimal represents each byte with two hex digits. Both are reversible without a key. They are useful for moving binary values through JSON, configuration, URLs, logs, and copy-and-paste workflows. An encoded password, token, document, or key remains readable to anyone who obtains the text.

Ciphertext, digests, MAC tags, signatures, and keys are often displayed using Base64 or hex, which can make the layers easy to confuse. The representation does not reveal which cryptographic operation produced the bytes. A field's schema must say whether it carries a SHA-256 digest, an HMAC tag, an AES-GCM package, a signature, or simply arbitrary data.

The Base64 Encoder is a transport conversion tool, while the Hash Generator calculates one-way digests. Neither tool supplies an encryption key-management system or an authentication protocol.

Choose by the property the application needs

  1. Need to compare exact content? Use SHA-256 or the algorithm required by the protocol, and protect the expected value according to the threat model.
  2. Need to store user passwords? Use Argon2id, scrypt, bcrypt, or PBKDF2 through an established authentication library.
  3. Need secrecy and tamper detection? Use authenticated encryption with managed keys and correct nonces.
  4. Need shared-secret authenticity? Use a standardized HMAC construction and define replay protection.
  5. Need public verification? Use an appropriate digital-signature system and verify the signer's key identity.
  6. Need printable transport? Use Base64 or hex after the security operation, without attributing security to the encoding.

Common design mistakes

  • “We encrypt passwords with SHA-256.” SHA-256 is not encryption, and one pass is not adequate password storage.
  • “The checksum matches, so the download is official.” A match is only as trustworthy as the expected checksum source.
  • “The value is Base64, so users cannot read it.” Base64 is immediately reversible and provides no confidentiality.
  • “We add a secret before hashing, so it is an HMAC.” Ad hoc keyed hashes can have structural flaws; use the standard HMAC API.
  • “Encryption automatically detects changes.” Only authenticated modes and correct tag verification provide that property reliably.
  • “A longer digest fixes every protocol.” Algorithm strength cannot repair exposed keys, nonce reuse, untrusted metadata, or missing authorization.

Need a deterministic digest? Calculate SHA-256 from exact UTF-8 bytes locally, then place that digest only in a workflow whose trust and authentication rules are explicit.

Open the SHA-256 Generator

Frequently asked questions

What is the main difference between hashing and encryption?

Hashing creates a fixed-length one-way digest for comparison and cryptographic constructions. Encryption transforms plaintext into ciphertext that an authorized party can decrypt with the correct key, providing confidentiality when the scheme is used correctly.

Can a hash be decrypted?

No. A cryptographic hash has no decryption key and discards information by mapping many possible inputs into fixed-size outputs. Weak inputs can still be discovered by hashing guesses, which is not the same as decrypting the digest.

Should passwords be encrypted or hashed?

Password verifiers should normally use a dedicated password-hashing KDF such as Argon2id, scrypt, bcrypt, or PBKDF2 with a unique salt and tuned cost. Reversible encryption creates a key whose compromise can expose every password.

Does hashing provide data authenticity?

A bare hash does not. Anyone can hash modified data. Use HMAC when trusted parties share a secret, or a digital signature when verifiers need public-key proof of origin, and follow the complete protocol.

Is Base64 encryption or hashing?

Neither. Base64 is a public reversible encoding that represents bytes with printable characters. It uses no secret key, offers no confidentiality, and provides no integrity or authenticity by itself.

Can encryption also detect tampering?

Authenticated-encryption schemes can provide confidentiality and integrity together when keys, nonces, associated data, and verification are handled correctly. Unauthenticated or obsolete encryption modes may hide plaintext without reliably detecting modification.