Encoding and decoding aren't encryption — they're format conversions that make data safe to transport or display in contexts where the raw form would break. Base64 encodes binary as ASCII for email and JSON; URL encoding escapes special characters for query strings; HTML entities prevent script injection. An encoder/decoder handles all the common formats so you don't have to remember each algorithm.

This guide covers the major encodings, when each applies, and how they differ from encryption.

Encoding vs Encryption

  • Encoding — Format conversion; reversible without key; not security
  • Encryption — Security; requires key to reverse; protects confidentiality
  • Base64 is encoding, not encryption — anyone can decode it

Common Encodings

Base64

Encodes binary as ASCII using 64 characters (A-Z, a-z, 0-9, +, /). Used in email attachments (MIME), data URIs, JSON, JWT tokens.

Output is ~33% larger than input.

URL Encoding (Percent-Encoding)

Escapes characters that have special meaning in URLs. Space becomes %20 or +, & becomes %26.

HTML Entity Encoding

Converts characters like < to &lt; to display as text in HTML without being interpreted as markup. Critical for preventing XSS.

Hex

Binary represented as hexadecimal. Used for hash output, colour values, low-level data.

Unicode Escape

Characters represented as \\uXXXX. Used in JSON for non-ASCII.

Base32

Uses 32 characters (A-Z, 2-7). Case-insensitive, used in TOTP secrets.

Common Use Cases

Base64

  • Embedding small images in CSS (data: URIs)
  • Email attachments (legacy MIME)
  • Storing binary in JSON or XML
  • Basic Auth credentials (still not secure on HTTP)
  • JWT token payload

URL Encoding

  • Query string parameters with spaces or symbols
  • Form data in URL
  • API URL parameters

HTML Entity

  • Displaying user input safely
  • Showing HTML code in tutorial pages
  • Preventing XSS in dynamic content

Common Pitfalls

  • Base64 treated as encryption. Anyone can decode in seconds
  • URL encoding done twice. Double-encoded data breaks downstream
  • HTML encoding skipped. User input becomes XSS vector
  • Wrong charset assumed. UTF-8 vs Latin-1 produces different bytes
  • Padding stripped from Base64. = at end matters; some systems strip incorrectly
  • URL encoding + characters. Already URL-safe; encoding to %2B sometimes wrong context

Security Notes

  • Encoding is reversible; never use for secrets
  • Base64 in URLs (URL-safe variant) avoids + / = needing further escape
  • JWT tokens use Base64; signed but not encrypted by default — payload visible
  • HTML entity encoding is critical defence against XSS

Practical Examples

  • Embedding small icon in CSS: data:image/png;base64,iVBORw0KGgo...
  • Search URL with spaces: ?q=hello%20world
  • Display HTML safely: &lt;script&gt; shows as <script>
  • JSON with non-ASCII: {"name": "Café"} or {"name": "Caf\\u00e9"}

Quick Tips

  • Encoding is not encryption; never use for security
  • Use URL-safe Base64 when value lives in a URL
  • HTML-entity encode all user input before display
  • Be aware of double-encoding bugs
  • Verify with decoded output before submitting

Use the Encoder/Decoder on Popupnote

The Encoder / Decoder on Popupnote provides a clean tool for Base64, URL, HTML entity, and hex encoding and decoding — for developers, security analysts, and anyone working with web data formats. The tool runs in your browser without any account required.