Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

Unicode Characters Inside Base64-Encoded JS Render as Garbled Text

Field Note #183
🔬 Resolved 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience

⚡ Quick Fix (TL;DR)

The Fix: 1. Identify whether the garbled characters are special Unicode (em-dash, curly quotes, accented characters).
2. Check the original source file's encoding (`utf-8` vs. `latin-1`).
3. Look for any Unicode characters outside the basic ASCII range inside JS string literals.
Replace all non-ASCII characters in JS strings with plain ASCII equivalents before encoding:

- Em-dash `–` → hyphen `-`
- Left/right single quotes `'` `'` → straight apostrophe `'`
- Left/right double quotes `"` `"` → straight quote `"`

In Python before encoding:
```python
content = content.replace('u2013', '-')
content = content.replace('u2019', "'")
Was this helpful? Thanks for the feedback!
The symptom
After base64-encoding a JavaScript block to protect it from wptexturize, certain characters in the widget’s visible output appeared as garbled sequences — specifically `Mon–Fri` rendered as `MonâFri` and `9am–4:30pm` rendered as `9amâ4:30pm`.

Initial assumption
The assumption was that base64 encoding was corrupting the text content.

Investigation
The garbled characters were Unicode em-dashes (`–`, U+2013) embedded in a JavaScript string that was then base64-encoded and decoded at runtime. The encoding itself was correct — the issue was that the original source file contained multi-byte UTF-8 characters. When the base64 string was decoded in the browser at runtime, the rendering context interpreted the bytes differently than expected, producing mojibake.

What to check
When encoded JavaScript produces garbled output at runtime:
 
1. Identify whether the garbled characters are special Unicode (em-dash, curly quotes, accented characters).
2. Check the original source file’s encoding (`utf-8` vs. `latin-1`).
3. Look for any Unicode characters outside the basic ASCII range inside JS string literals.

Resolution
Replace all non-ASCII characters in JS strings with plain ASCII equivalents before encoding:
 
– Em-dash `–` → hyphen `-`
– Left/right single quotes `’` `’` → straight apostrophe `’`
– Left/right double quotes `”` `”` → straight quote `”`
 
In Python before encoding:
“`python
content = content.replace(‘\u2013’, ‘-‘)
content = content.replace(‘\u2019’, “‘”)
“`

Troubleshooting lesson
Base64 encoding preserves bytes exactly — it does not normalize character encoding. Any multi-byte Unicode character in the original string will decode as the same bytes at runtime, but browser rendering behavior for those bytes depends on the execution context. When embedding JS strings that will be decoded via `atob()`, stick to ASCII throughout.

Tagged in :

More from the field