Start with the destination
Ask where the value is going before choosing a tool. HTML entity encoding helps represent characters such as an ampersand inside HTML text. Percent encoding makes a value suitable for a URL component, where spaces and reserved characters need a defined representation. Base64 represents arbitrary bytes using a restricted alphabet that is convenient in text-oriented systems. A SHA-256 digest is a fixed-length fingerprint used to compare data, not a way to recover the original. None of these four operations is encryption. If a secret must stay confidential, choose an authenticated encryption design appropriate to the application rather than disguising it with Base64 or a hash.
One input, four different results
Take the short text A&B. In ordinary HTML text, the ampersand can be written as A&B; an HTML parser displays A&B again. As a URL component, it becomes A%26B, because an unescaped ampersand can separate query parameters. UTF-8 encodes the three visible characters as bytes 41 26 42 in hexadecimal, and standard Base64 represents those bytes as QSZC. A SHA-256 tool produces a long hexadecimal digest instead; a small input change will ordinarily give a very different digest. These outputs are not interchangeable: putting Base64 where a URL component is expected can still introduce reserved URL characters, and placing a hash in a document cannot reproduce the original text.
- A&B — original text
- HTML: A&B · URL: A%26B
- Base64: QSZC · SHA-256: digest
Reversibility and security
HTML entities, percent encoding and Base64 are reversible when their input encoding and context are known. That is precisely why they provide no secrecy. Someone reading a Base64 string can decode it without a key. SHA-256 is designed to be one-way, yet hashing a predictable password alone is not a safe password-storage method; dedicated, salted password-hashing schemes address that separate problem. A digest also does not prove who supplied the data unless it is used within an authenticated protocol. For browser content, escaping is context-specific: HTML text, an HTML attribute, a URL and JavaScript source have different rules. Escaping one context and pasting the result into another can be unsafe.
A practical conversion workflow
First identify the raw text and the receiving format. If you are constructing an HTML text node, use the HTML entity encoder for the characters that need representation there; let a trusted template system handle HTML markup in production. If you are placing a value in one URL parameter, use the URL component encoder once, then append the encoded value to the parameter. If an interface explicitly expects Base64, convert the text to bytes with the agreed character encoding, usually UTF-8, before encoding those bytes. If you need to compare the integrity of two byte sequences, hash both with the same algorithm and compare their digests. Keep the original bytes available if you will later need to display the original message.
Check the round trip
Try decoding the result with the corresponding decoder whenever the transformation should be reversible. Watch for double encoding: A%26B encoded a second time contains %25 and decodes only one layer at a time. Check whether your Base64 receiver expects the standard alphabet, a URL-safe variant or padding characters. For hashes, confirm the exact byte encoding and whether line breaks or trailing spaces are part of the input; visually similar text may have different bytes. The embedded Base64 converter below is a quick way to test the reversible case. Use the linked HTML, URL and SHA-256 tools for the other paths, then choose the output whose meaning matches the receiving system.