Web Security Encoding: Base64, URL, HTML Entities Explained
Encoding is one of the most misunderstood concepts in web development. Developers often confuse encoding with encryption, use the wrong encoding for a given context, or skip it entirely — creating security vulnerabilities like XSS (Cross-Site Scripting) in the process.
This guide clarifies what encoding is, when each type applies, and how it prevents common security issues.
Encoding is Not Encryption
This distinction is critical:
- Encoding transforms data into a different format for safe transport. It is reversible and has no secret key. Anyone can decode it.
- Encryption transforms data so only someone with the key can read it. It is designed to be secret.
Base64 is encoding, not encryption. Never use Base64 to "hide" passwords or sensitive data — it provides zero security.
URL Encoding (Percent Encoding)
Why it exists
URLs have reserved characters with special meaning: ? starts query strings, & separates parameters, # marks fragments, / separates path segments. If your data contains these characters, the URL breaks.
How it works
Each unsafe character is replaced with %XX where XX is the hexadecimal ASCII value. Space becomes %20, & becomes %26, = becomes %3D.
When to use
- Query parameter values:
?search=encodeURIComponent(userInput) - Path segments containing user data
- Cookie values with special characters
- Form data in application/x-www-form-urlencoded
Security implication
Without URL encoding, attackers can inject additional parameters. If redirect=http://evil.com&admin=true is not encoded, the &admin=true becomes a separate parameter. URL encoding prevents parameter injection.
HTML Entity Encoding
Why it exists
HTML uses < and > to define tags. If user-supplied text contains these characters and is rendered without encoding, the browser interprets them as HTML — enabling XSS attacks.
How it works
Special HTML characters are replaced with named or numeric entities:
<becomes<>becomes>&becomes&"becomes"'becomes'
When to use
- Any time you render user-provided text in HTML
- Inserting dynamic values into HTML attributes
- Displaying code snippets on web pages
Security implication
This is your primary defense against XSS (Cross-Site Scripting). If a user submits <script>alert('xss')</script> and you render it without encoding, their script executes in every visitor's browser. With encoding, it displays as harmless text.
Modern frameworks (React, Vue, Angular) auto-encode by default. The danger is when you bypass this with dangerouslySetInnerHTML or v-html.
Base64 Encoding
Why it exists
Some transport channels (email, JSON, URLs) only support text characters. Binary data (images, files, encrypted blobs) cannot travel through these channels directly. Base64 converts binary to a text representation using 64 safe ASCII characters.
How it works
Every 3 bytes of binary data become 4 Base64 characters. The 64-character alphabet is A-Z, a-z, 0-9, +, /. Padding (=) fills the final group if needed. This produces ~33% size overhead.
When to use
- Embedding images in CSS/HTML as data URIs:
background: url(data:image/png;base64,...) - Sending binary data in JSON API payloads
- Email attachments (MIME encoding)
- Storing binary in text-only databases or configs
- Basic HTTP authentication header:
Authorization: Basic base64(user:pass)
Security implication
Base64 is NOT security. It is trivially reversible. Never use it to hide sensitive data. The HTTP Basic auth example above sends credentials in plain text (Base64 decoded) — only use it over HTTPS.
Choosing the Right Encoding
| Context | Correct Encoding |
|---|---|
| URL query parameter | URL encoding (encodeURIComponent) |
| HTML page content | HTML entity encoding |
| HTML attribute value | HTML entity + attribute-safe encoding |
| JavaScript string literal | JavaScript escape (\\x, \\u) |
| CSS value | CSS escape (\\HH) |
| Binary in JSON | Base64 |
| Binary in email | Base64 (MIME) |
Common Mistakes
- Double encoding — encoding an already-encoded value. Results in
%2520instead of%20. Encode once, at the boundary. - Wrong context encoding — URL encoding inside HTML, or HTML encoding inside URLs. Each context needs its own encoding.
- Encoding on input instead of output — store raw data, encode when rendering. This lets you use the same data in different contexts with appropriate encoding each time.
- Trusting client-side encoding alone — always validate and encode on the server too. Client-side can be bypassed.
Summary
Encoding is context-dependent data transformation for safe transport. Use URL encoding for URLs, HTML entities for HTML output, and Base64 for binary-to-text conversion. Never confuse encoding with encryption or security. Apply encoding at the output boundary, not the input boundary.
Practice with our encoding tools: