Encoding is not encryption

Base64 and URL encoding are reversible transformations meant to make binary or special-character data safe to carry inside contexts that only expect a limited set of characters — an email attachment, a URL query string, a JSON string value. Anyone can decode them; they add zero confidentiality. If the goal is to hide data from someone, encoding is the wrong tool — that's what encryption is for. A surprising amount of "obfuscation" in the wild is just Base64, which is why this tool treats it as a two-way, non-secret operation.

Why hashes can't be decoded

The hash functions here (SHA-1/256/384/512) are one-way by design: there is no "decode hash" button because none is mathematically possible. A cryptographic hash compresses an input of any size down to a fixed-length digest, and that compression is deliberately lossy and deterministic — the same input always produces the same hash, but the hash alone can't be reversed to recover the input. What can happen is a dictionary or brute-force attack: hashing a large list of candidate inputs and checking for a match against a known hash. That's why hashing a password directly (without a slow, salted algorithm like bcrypt) is not sufficient for password storage — see this site's bcrypt tool for that use case.

Which hash to reach for

• SHA-1 — legacy compatibility only. It's cryptographically broken for collision resistance (two different inputs can be engineered to produce the same hash) and shouldn't be used for anything security-sensitive.
• SHA-256 — the current default for most purposes: checksums, Git-adjacent tooling, general integrity verification.
• SHA-384 / SHA-512 — larger digest sizes for higher-assurance contexts, at a small computational cost.