🔧 TL3 Tools

Three encodings dominate web development: Base64, HTML entities, and URL encoding. They sound similar, and a quick glance suggests they do the same thing, transform text into a different form. In reality each one exists to protect a specific channel, and using the wrong one produces bugs that are hard to spot: text that renders literally, links that break, payloads that arrive garbled.

The shared idea is simple. Every channel has characters it handles safely and characters it treats as control syntax. Each encoding maps the unsafe characters onto a safe alphabet for its own channel. The differences come down to which channel each one defends.

The Shared Idea: Making Text Safe

An email body, an HTML document, and a URL all have reserved characters. In HTML, the angle brackets and ampersand are markup, not text. In a URL, spaces, slashes, and percent signs are syntax. In a text-only transport like an email attachment or a JSON string, binary data has no safe representation at all. Encoding solves each problem by replacing the dangerous characters with characters the channel treats as plain text, and the decoder reverses the process on the other side.

Encoding is not encryption. All three transforms are reversible by anyone who sees the output, and their only job is to keep meaning intact through a specific pipe.

Base64: Binary Through Text Channels

Base64 exists because text channels cannot carry binary. It takes arbitrary bytes and represents them with a 64-character alphabet: A–Z, a–z, 0–9, plus and slash, with an equals sign for padding. Every three input bytes become four output characters. The word Hello, five bytes, encodes to SGVsbG8=; the trailing equals sign pads the final group.

The cost is bulk: output grows by about 33 percent. Base64 is the right tool when a system that only handles text must carry image data, a file, or a cryptographic key, such as embedding a small image inline in a document or passing a token in an API call. It is the wrong tool when the output will sit in a URL path, because plus, slash, and equals all carry meaning there. The Base64 encoder and decoder on this site converts text in either direction and runs entirely in your browser.

HTML Entities: Keeping Markup Literal

HTML entities exist so you can display characters that HTML treats as syntax. Five characters matter: the ampersand, the two angle brackets, and the two quote types. The browser decodes entities when it renders a page, so & displays as &'s glyph, the ampersand. The text Tom & Jerry's Pizza renders as "Tom & Jerry's Pizza" instead of being misread as markup or breaking out of an attribute.

The critical rule: encode user-supplied text when it is inserted into HTML, and never treat encoded text as a value for a URL or an API payload. Entities mean nothing outside HTML, and a query string full of & is a double-encoding bug waiting to happen. The HTML entity encoder escapes text the way a template engine would, before you render it into a page.

URL Encoding: Percent Signs for Query Strings

URL encoding, also called percent encoding, protects the characters that URLs reserve for their own syntax. Each unsafe byte becomes a percent sign followed by two hex digits. The search query what's the weather in San José? encodes to what%27s%20the%20weather%20in%20San%20Jos%C3%A9%3F: the apostrophe, each space, the accented é, and the question mark all become percent sequences, while letters, digits, and a few symbols pass through untouched.

Two details trip people up. First, the encoded space is %20 in a URL; the plus sign that appears in application/x-www-form-urlencoded form bodies is a separate convention, and JavaScript's encodeURIComponent never produces it. Second, you encode the value, not the whole URL: the scheme, host, and path stay as they are, and each query parameter is encoded individually. The URL encoder and decoder on this site applies the same transform so you can verify what a link will actually send.

What Happens When You Mix Them Up

The classic failures come from crossing channels. Base64 output dropped into a URL path breaks on the plus and slash, which the server may interpret as space and path separators; the fix is a URL-safe Base64 variant that swaps plus and slash for hyphen and underscore. HTML entities applied to a URL do nothing useful: & in a query string means an actual ampersand to the server, not an encoded one. And URL-encoding text before putting it in HTML shows the literal percent sequences on screen.

Double encoding is the other common trap. Encoding a value, then encoding the result again, produces output that the decoder reverses only once, leaving a string full of percent signs or entity names. The fix is to encode exactly once, at the boundary where the data crosses into the channel, and to keep the original value everywhere else.

A Quick Decision Rule

Choose by channel, not by content. Moving binary data, like an image or a key, through a text-only system: Base64. Inserting text into an HTML page, especially anything a user typed: HTML entities. Building a URL or a query string from untrusted or non-ASCII text: URL encoding. If the data crosses two channels, encode it for each boundary separately, in order.

None of the three is interchangeable with the others, and none is a substitute for proper escaping in the surrounding framework. Get the channel right and the encoding becomes invisible, which is exactly what an encoding should be.