Encoding is not encryption: protect data for the right reason

By Ajay Ladva · 18 October 2026 · Security basics

Encoding, encryption and hashing can all turn familiar text into an unfamiliar string, which makes them easy to confuse. Their purposes are different. Encoding changes how data is represented so another system can read or transport it. Encryption uses a secret key to make data unreadable to someone without authorised access. Hashing produces a fixed-size digest intended to be one-way. Choosing the wrong operation can create a false sense of protection—for example, Base64 is not a way to keep a password secret.

Encoding changes representation

Base64 represents bytes using a limited set of printable characters. It is useful where a protocol expects text, such as embedding binary data in a text format. Anyone can reverse it without a password. URL encoding represents certain characters in a form safe to place in a URL component; it does not conceal the data. HTML entities make reserved characters display as text in HTML. These formats are reversible and provide no confidentiality. If an encoded value is posted publicly, treat the underlying content as public too.

Example: the word “cat” can be represented as Base64 characters, but those characters do not make the word private. Encoding also should not be confused with sanitising. Correctly encoding a value for a specific HTML, URL or SQL context can prevent parsing errors or injection when applied in the right place, but a generic encoded string is not automatically safe for every context. Security depends on using the correct context-aware output encoding and safe APIs.

Encryption needs a key and a sound implementation

Encryption protects confidentiality by transforming data using a cryptographic algorithm and key. Authenticated encryption also helps detect tampering. Modern libraries handle important details such as nonce use, authentication tags and algorithm parameters. Do not invent an algorithm, reuse a nonce where the mode forbids it, or store the key beside the encrypted file without another protection layer. A strong cipher with a weak or exposed key provides little practical protection.

Example: encrypting a backup can reduce risk if a storage account is accessed, but the protection works only while the key remains secret and recoverable to its owner. If the key is lost, the data may be unrecoverable. If the key is emailed alongside the file, an attacker who obtains both can read the contents. For data exchanged with another person, agree on a safe way to deliver and rotate keys and verify recipient identity through a separate channel.

Hashing serves a different purpose

A cryptographic hash maps input to a digest. It is useful for checking integrity and as one component of digital signatures. Hashes are designed to be hard to reverse, but a plain hash of a low-entropy value such as a short password can be guessed by trying likely candidates. Password storage should use a purpose-built password-hashing function with a unique salt and appropriate work factor, as implemented and maintained by a trusted framework. A fast general-purpose hash alone is not a safe password-storage scheme.

Hashing is not encryption: there is no decryption key that restores the original message. If the original needs to be recovered, use appropriate encryption rather than a hash. If the goal is comparison without storing the original, a secure password-verification design may be suitable, but the details should be selected by an experienced developer using vetted libraries.

Using a browser toolkit safely

The KRHTech Encryption Toolkit provides educational and practical operations in the browser. Read the selected mode's description and use only values whose handling you understand. Do not paste production credentials, medical or financial records, recovery phrases or regulated information into an online tool without a security review of its code and data path. Local browser processing reduces server transfer for that operation but does not protect against malware, browser extensions, shoulder surfing, clipboard history or a compromised device.

Before relying on an encrypted output, confirm how the key is generated, how the algorithm and parameters are chosen, whether authenticity is verified, and how the receiver obtains the key. Keep a recovery copy when losing the data would be costly. Test decryption using a harmless sample before deleting an original. For high-value or regulated data, use an audited, well-maintained application and documented key-management process instead of a general-purpose web utility.

Common mistakes and a decision guide

Do not use Base64, URL encoding, ROT-style substitutions or a hidden filename as a substitute for encryption. Do not send a password or decryption key through the same public channel as the data. Do not infer security merely from a long output string. A hash cannot be used to restore a message; a reversible encoding does not make it secret; and encryption does not prove who created the content unless an appropriate authentication or signature design is used.

Ask three questions before choosing: must the data be readable again, must it remain confidential, and must changes be detectable? If only representation must change, encoding may be right. If the data must be recovered but kept confidential, encryption is relevant. If you need a one-way fingerprint, a cryptographic hash may fit. For authentication, use an established signature or message-authentication design. The Encryption Toolkit can help explore concepts, but it is not a security certification or substitute for professional review.

Transport security and key storage are separate layers

Encrypting a file on disk does not automatically protect it while it is being uploaded, emailed or opened on an infected device. Use secure transport and access controls as well as appropriate at-rest protection. Conversely, HTTPS protects a connection in transit but does not mean a service cannot read information after it arrives. Understand where the plaintext exists, who controls each key and how copies are retained. A threat model should include backups, logs, temporary files, endpoints and people with administrative access.

For a business workflow, define who can create, rotate, revoke and recover keys before adopting an encryption tool. Record a safe recovery procedure, test it with non-production data and ensure key backups do not share the same failure point as the encrypted files. If the system handles regulated or high-value information, use established platform controls and get a qualified security review. A small demonstration helps teach vocabulary, but it cannot establish that a complete product or workflow is secure.