Web-Safe Encoding Explained: Base64, URL Encoding, and HTML Entities

What Base64, URL encoding, and HTML entities do, and when to use each. A clear guide explaining that encoding is not encryption, with practical examples.

#base64#url encoding#html entity#encoding#web development

Web-Safe Encoding Explained: Base64, URL Encoding, and HTML Entities

When you work with data on the web, the same problem keeps coming up: some characters simply don't belong where you're trying to put them. A raw image can't go straight into HTML, a space can't sit in the middle of a URL, and a < sign gets mistaken for a tag in the browser. Three core tools solve these problems: Base64, URL (percent) encoding, and HTML entities. All three are "encoding," so let's start with the most common mistake: encoding is not encryption.

Encoding ≠ Encryption

Encoding represents data in a different form; it doesn't hide it. There's no key, no password. Anyone who sees a Base64 string can decode it back in seconds. The goal isn't security but making data portable and valid. To protect sensitive data you need real encryption like AES, or at the very least HTTPS. Keep that in mind as we look at the three methods.

Base64: Turning Binary into Text

Base64 represents binary data using only safe text characters. Its alphabet consists of A–Z, a–z, 0–9, plus + and / — 64 characters in total — with = added as padding to fill out incomplete groups.

The logic is simple: data is split into 3-byte (24-bit) groups, each group is divided into four 6-bit chunks, and each chunk maps to one character in the alphabet.

When to use it:

Data URIs to embed small images, icons, or fonts directly into HTML/CSS: <img src="data:image/png;base64,iVBOR...">
The MIME standard that carries email attachments
Sending binary data inside text-only formats like JSON
HTTP Basic Authentication headers (but remember this is not encryption)

The key downside: Base64 doesn't compress data; it actually grows it by about 33%. That's because it expresses a byte that normally carries 8 bits using a character that holds only 6 bits of data. So embedding large files as Base64 is a bad idea; it only makes sense for small assets. To convert text quickly, use the Base64 Encoder tool.

URL Encoding (Percent Encoding): Fitting into the Address Bar

URLs allow only a limited set of characters to be used safely. Spaces, non-ASCII letters, and characters like &, ?, =, / either carry special meaning (they act as delimiters) or can't appear at all. URL encoding converts these characters into a % sign followed by a two-digit hexadecimal code.

For example, a space becomes %20, an & becomes %26, and é becomes %C3%A9. A typical example:

https://site.com/search?q=coffee%20%26%20milk

When to use it:

Putting user input into query string parameters
Making one URL a parameter of another (redirect links)
Submitting form data with application/x-www-form-urlencoded

Common mistake: encoding the entire URL at once. If the : and / inside https:// get encoded too, the link breaks. Encode only the parameter values, not the structural delimiters. For a quick conversion, the URL Encoder tool does the job.

HTML Entities: Showing Markup Without Breaking It

In HTML, characters like <, >, and & have special meaning: when the browser sees <, it assumes a tag is starting. If you actually want the page to show "a < b", you have to write the < character as an HTML entity: <. Likewise, use > for >, & for &, and " for a double quote.

When to use it:

Displaying code samples or text that contains < and > on a page
Rendering user-supplied content into the page — which is also the most important security concern

If you write user input directly onto the page, then when someone sends <script>...</script> the browser treats it as code and runs it; this is called XSS (Cross-Site Scripting). By converting (escaping) the input into HTML entities, <script> turns into harmless text and appears on screen exactly as written. To escape your text safely, use the HTML Encoder tool.

Note: entity encoding is the right fix when displaying content. When inserting data into the DOM with JavaScript, using safe methods like textContent provides the same protection.

Which One, When? (Summary Table)

Encoding	Use Case	Example
Base64	Turn binary data into text (data URIs, email, JSON)	`Hi` → `SGk=`
URL Encoding	URL parameters and reserved characters	space → `%20`, `&` → `%26`
HTML Entity	Show special characters in HTML / prevent XSS	`<` → `<`, `&` → `&`

Choosing the Right Tool

A practical rule: where you put the data determines which encoding you use.

Is the data going inside a URL? URL encoding.
Will the data appear in the body of HTML? HTML entities.
Are you pushing something binary through a text-only channel? Base64.

Mixing these three up is the most common mistake. Encoding a URL parameter with HTML entities, or running HTML output through Base64, won't work; each one solves the rules of a different context. Apply the right encoding at the right layer.

Summary

Base64, URL encoding, and HTML entities solve different problems but share a common goal: making data valid and safe in the environment it lands in. None of them is encryption; they don't hide data, they merely reshape it. When deciding which to use, ask "where is the data going?" and apply the rules of that context.