People's Names Break Websites

Understanding Character Encoding

The root of many name-related issues lies in misunderstanding character encoding.

ASCII vs Unicode vs UTF-8

ASCII (American Standard Code for Information Interchange) defines only 128 characters: basic English letters (A-Z, a-z), digits (0-9), and common symbols. This was sufficient for early computing in America but fundamentally inadequate for global users.

Unicode is a comprehensive character set that includes over 150,000 characters covering virtually every writing system on Earth--from Latin scripts with accents, to Cyrillic, Greek, Arabic, Hebrew, Chinese, Japanese, Korean, emojis, and more.

UTF-8 (Unicode Transformation Format, 8-bit) is the variable-width encoding that maps Unicode code points to bytes. It's backward-compatible with ASCII (the first 128 characters are identical), supports all Unicode characters, and has become the standard encoding for the web. Ensuring your web applications use UTF-8 encoding is a fundamental web development best practice for serving global audiences.

The UTF-8 Solution

Using UTF-8 throughout your application stack solves most name-related problems:

// UTF-8 handles all of these correctly:
const users = [
 { name: "José García" }, // Spanish accents
 { name: "Björk Guðmundsdóttir" }, // Icelandic characters
 { name: "田中太郎" }, // Japanese kanji
 { name: "Nguyễn Văn Minh" }, // Vietnamese diacritics
 { name: "François" }, // French cedilla
 { name: "Müller" }, // German umlaut
 { name: "Ødegaard" }, // Norwegian letter
];

As noted by the W3C Internationalization Quick Tips, UTF-8 is the standard encoding for web content globally and should be used for all content, databases, and software.

ASCII Limitations in Practice

Legacy systems designed in the 1970s-1990s often still use ASCII for performance or compatibility reasons. Some systems strip non-ASCII characters without warning, transforming "Müller" into "Mller" or rejecting names entirely. This approach is fundamentally broken for any application serving a global audience, particularly for businesses looking to expand internationally.

Code Examples: What NOT to Do

// BAD: Rejects valid names with ASCII-only validation
const validateName = (name) => {
 return /^[a-zA-Z]+$/.test(name); // Rejects spaces, accents, Unicode
};

// BAD: Rejects innocent names matching keywords
const badFilter = (name) => {
 return !/^(test|null|select|drop|delete)/i.test(name); // Rejects real people!
};

// BAD: String concatenation causes both security issues AND rejects names
const query = `SELECT * FROM users WHERE name = '${name}'`;
// Fails for O'Brien AND allows SQL injection

// GOOD: Accept all valid input
const validateName = (name) => {
 return typeof name === 'string' && name.trim().length > 0;
};

// GOOD: Prepared statements handle all names safely
const query = 'SELECT * FROM users WHERE name = $1';
await db.query(query, [name]); // O'Brien works, injection prevented

Real Names That Break Systems

From CSS-Tricks' comprehensive coverage of this issue, these are actual cases documented:

• Christopher Null - Databases interpret as SQL NULL value
• William Test - Flagged as test data by booking systems
• Joan Fread - Name matches PHP function
• Luke O'Sullivan - Had to fly under a different name
• O'Donnell, O'Brien, D'Aoust - Apostrophes rejected
• Knud (with ø) - Converts to ? or rejected

These aren't hypothetical problems--they're real experiences that cause genuine frustration and exclusion. Building robust web applications that handle all names correctly is essential for user trust and accessibility.

Cultural Naming Conventions That Break Assumptions

Western naming conventions (given name first, family name last) are not universal. Designing forms based on these assumptions excludes significant portions of the global population. Internationalization in web development requires understanding these cultural differences.

Different Name Orders

As documented by the W3C's comprehensive guide to personal names around the world, systems must accommodate diverse naming practices from around the globe.

Names Without Family Names

Icelandic naming uses patronymics (Guðmundsdóttir = daughter of Guðmundur) rather than family names. Many Malay and Indonesian names consist only of a given name. Forcing these users to enter a family name results in garbage data like "." or "Mr."

Multiple Family Names

Spanish/Latino names include two family names (paternal and maternal):

• María José Carreño Quiñones (paternal: Carreño, maternal: Quiñones)

Portuguese/Brazilian names can include three or more family names from ancestors, often with connecting words like "de" or "e".

Special Characters by Culture

• Apostrophes: O'Brien (Irish), D'Angelo (Italian)
• Hyphens: Jean-Pierre (French), Müller-Schmidt (German compound)
• Spaces: van der Waals (Dutch), De la Cruz (Spanish)
• Periods: Jr., Sr. (American suffixes)
• Unicode diacritics: All European languages, plus global scripts

Implications for Form Design

Rather than asking for "first name" and "last name," use culturally neutral labels:

• "Given name(s)" and "Family name"
• Or better: a single "Full name" field when possible
• Allow users to specify which part is their family name for sorting

Security Without Breaking Names

A common misconception is that names must be sanitized or restricted to prevent security issues. This is wrong--proper security practices don't require rejecting valid names.

The Injection Attack Misconception

The fear that names like "Robert'); DROP TABLE Users;--" could cause problems leads some developers to reject special characters. But the solution isn't rejecting input--it's using parameterized queries:

// WRONG: Rejecting names (doesn't actually prevent injection)
const sanitizeName = (name) => name.replace(/['";]/g, '');

// CORRECT: Using prepared statements (actually prevents injection)
const getUser = async (name) => {
 return await db.query(
 'SELECT * FROM users WHERE name = $1',
 [name] // Name can contain anything!
 );
};

As explained in Hackaday's technical analysis, security concerns about injection are often misused to justify ASCII-only restrictions when prepared statements handle all names safely.

Content Security for Display

For public-facing displays of user-generated content (comments, forum posts, profiles), appropriate escaping and content security policies handle any edge cases without rejecting valid names:

// Escaping for HTML display
const escapeHtml = (str) => {
 return str
 .replace(/&/g, '&')
 .replace(/</g, '&lt;')
 .replace(/>/g, '&gt;')
 .replace(/"/g, '&quot;')
 .replace(/'/g, '&#039;');
};

// Names display correctly and safely
displayName.textContent = escapeHtml(user.fullName);

Input Validation vs Output Encoding

• Input validation: Check that the input is a valid format (string, reasonable length)
• Output encoding: Escape content appropriately for the context (HTML, SQL, etc.)

Validating that a name is a non-empty string is appropriate. Rejecting names because they contain apostrophes is not. Following secure web development practices ensures your applications are both secure and inclusive.