WHMCS Emoji Compatibility Guide

Emoji that survive your client-facing content.

Some emoji render perfectly in a WHMCS product name or email template. Others turn into ????, empty boxes, or broken characters the moment they hit an older database or a mail client. This is a conservative shortlist of structurally simpler ones to start from, with a searchable copy board you can keep open while you write and test.

A static reference. Nothing you do here is tracked or sent anywhere. Works offline after your first visit.

🔍

Click any emoji to copy it. The 179-entry shortlist excludes ZWJ sequences, skin tone modifiers, regional flags, and supplementary-plane code points. Inclusion means usually safer to test, not guaranteed compatible. The full profile is available as JSON and CSV.

Curated copy groups

🧰 Useful sets for hosting, billing, support, and security.

These are small, conservative subsets of the reviewed list, grouped by the way WHMCS teams usually write product names, email subjects, and client-area labels.

Hosting

Billing

Support

Security

🧩 Why emoji break in WHMCS

An emoji is one or more Unicode code points, and every layer between your keyboard and your customer's screen has to agree on how to store and display them. In a WHMCS stack there are several layers that often disagree:

  • The database. MySQL's three-byte UTF-8 character set stores Basic Multilingual Plane code points but not supplementary-plane characters used by most modern emoji. Those characters require utf8mb4. WHMCS also documents an extended-character setting that should only be changed when the connection and table collation use utf8mb4.
  • Email. A template may render fine in the admin preview, then arrive in a mail client that substitutes a tofu box for a symbol it does not have a glyph for.
  • Age. Newer emoji from recent Unicode releases are simply unknown to older systems, which fall back to a placeholder.

The failure can be quiet: a value may save differently from how it previewed, or an email client may lack the requested glyph. This board narrows the test set by excluding supplementary-plane characters, ZWJ sequences, skin tone modifiers, and regional flags. It still includes standard variation and keycap sequences, so saving, reloading, and checking the received email remain essential.

✅ What tends to work, and what does not

✅ Usually safer

  • Basic symbols and older Unicode emoji
  • Simple single-code-point emoji
  • Emoji without skin tone modifiers
  • Emoji without gender or family combinations

⚠ī¸ Often unsupported

  • Country flags
  • New emoji from recent Unicode releases
  • Skin tone variations
  • Complex zero-width-joiner sequences

Even a safer emoji is worth a real test in your own stack before it goes into a billing-critical or support-critical message. The list here is a strong starting point, not a promise about your specific database, PHP version, and mail pipeline.

Technical references: WHMCS localisation settings, MySQL Unicode character sets, and Unicode Emoji, UTS #51.

📸 Help build the failure gallery

Real screenshots are the next thing that will make this guide more useful. If an emoji turns into question marks, an empty box, or a broken character in your WHMCS install, please share a report with enough context for someone else to learn from it.

Where it brokeProduct name, received email, knowledge base article, announcement, client-area label, or admin note.
Your stackWHMCS version, PHP version, database charset, and collation if you know them.
ProofBefore and after screenshots are ideal. Redact names, domains, invoice numbers, and customer details.

Use the emoji report form, or add screenshots to the open render-failure collection issue.

đŸ’Ŧ Frequently asked questions

Every emoji carries the official Unicode CLDR keywords (the same set that powers phone emoji keyboards) plus a curated layer of colors and concepts. So you can search by name (heart), by idea (love, danger, zodiac), or by color (red, green), and it still finds the right symbol if you make a typo like hart or chekc. It all runs in your browser, with no lookups sent anywhere.

They are drawn from older Unicode ranges and checked against a documented structural profile. Every entry uses Basic Multilingual Plane code points, and the list excludes ZWJ sequences, skin tone modifiers, regional flags, and supplementary-plane characters. That reduces common compatibility risks, but only a save-and-reload test in your own stack can establish compatibility.

Check the exact value after saving and reloading, then inspect the database connection charset and the relevant column or table collation. For supplementary-plane characters, WHMCS documents utf8mb4 requirements. If the stored value is intact but the received email differs, test a plainer symbol and compare mail clients.

Yes, and real test reports are the most valuable thing here. Open an emoji report with the emoji, your WHMCS and PHP versions, your database charset, and where you tested it.

The Unicode storage and rendering principles are broader than WHMCS, but this shortlist and its reporting fields are organized around WHMCS product names, templates, email, and client-area content.

🌱 Why I built this

Working around WHMCS, I watched an emoji ship in a product name, survive the order form, and arrive in the invoice email as question marks. Whether a character survives depends on layers most people never look at. I kept notes on what worked, and this guide is those notes, cleaned up and published.