DevKit
← Back to Blog

Web Security Encoding: Base64, URL, HTML Entities Explained

7 min read

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:

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

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:

When to use

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

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

ContextCorrect Encoding
URL query parameterURL encoding (encodeURIComponent)
HTML page contentHTML entity encoding
HTML attribute valueHTML entity + attribute-safe encoding
JavaScript string literalJavaScript escape (\\x, \\u)
CSS valueCSS escape (\\HH)
Binary in JSONBase64
Binary in emailBase64 (MIME)

Common Mistakes

  1. Double encoding — encoding an already-encoded value. Results in %2520 instead of %20. Encode once, at the boundary.
  2. Wrong context encoding — URL encoding inside HTML, or HTML encoding inside URLs. Each context needs its own encoding.
  3. 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.
  4. 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: