Replace Em Dash and En Dash

They look similar at a glance, but these are three distinct characters with different Unicode code points, different typographic roles, and different behavior across platforms.

• Hyphen (-). The basic hyphen sitting on your keyboard next to the zero key. Unicode U+002D, also called a hyphen-minus. It's the universal connector: compound words like "well-known," prefixes like "pre-launch," and phone numbers like "555-867-5309." Every system, font, encoding, and platform on earth handles the plain hyphen without issue.
• En dash (–). A slightly wider dash roughly the width of the letter "N" in the current font. Unicode U+2013. Traditionally used for ranges ("pages 10–15," "Monday–Friday," "2020–2025") and to connect related terms where the relationship is more parallel than compound. Most people have never intentionally typed one because there's no dedicated key for it on standard keyboards.
• Em dash (—). The widest of the three, roughly the width of the letter "M." Unicode U+2014. Used in writing as a punctuation mark to set off parenthetical statements, introduce dramatic pauses, or replace colons and semicolons for stylistic effect. Em dashes are the most typographically expressive and the most technically problematic of the three.

The problem isn't that these characters exist. It's that they move between systems unpredictably, display inconsistently, encode differently, and break things that hyphens never would.

Plain hyphens are part of ASCII, the baseline character set that every digital system has supported since the 1960s. Em dashes and en dashes are Unicode characters that exist outside that baseline. Most modern systems handle Unicode correctly, but "most" and "correctly" both have asterisks.

• Encoding corruption. When text moves between systems with different encoding settings, typographic dashes are among the first casualties. An em dash encoded as UTF-8 and read as Windows-1252 displays as garbled characters. Plain hyphens survive every encoding because they're in the ASCII range that all encodings share.
• Email rendering. Different email clients, webmail interfaces, and mobile apps render Unicode with varying levels of support. An em dash that looks correct in Gmail's web interface might render as a question mark in a legacy Outlook installation or as a missing character box in a client with limited font support.
• CMS and database issues. Content management systems, particularly older ones, sometimes strip or corrupt Unicode characters during save operations. A WordPress site with a misconfigured database character set can turn every em dash into a replacement character.
• Code and configuration files. An em dash in a YAML file, a JSON string, a CSS property, or a shell command breaks things in ways that produce cryptic error messages. The character is visually similar enough to a hyphen that a quick scan won't catch it.
• Copy-paste contamination. Word processors, design tools, and some text editors automatically convert hyphens to em or en dashes as you type. When you copy text from these applications and paste it into a system that expects plain ASCII, the typographic dashes come along silently.

Not every context calls for replacing em and en dashes. They're legitimate typographic characters with real purposes. The question is whether the destination system and audience will handle them correctly.

• Always replace for code and data. Configuration files, code strings, URLs, API payloads, CSV exports, database fields, and any context where text is processed programmatically should use only plain hyphens. Typographic dashes in these contexts are bugs, not style choices.
• Replace for cross-platform content. If your content will be displayed across email clients, legacy systems, third-party platforms, RSS feeds, or any distribution channel where you don't control the rendering environment, replacing typographic dashes with hyphens eliminates an entire category of display issues.
• Replace for plain-text contexts. SMS messages, chat platforms, plain-text email fallbacks, commit messages, terminal output, and log files should use plain hyphens.
• Consider keeping for polished editorial content. A magazine article, a professionally typeset report, or a brand's website where you control the rendering can benefit from proper typographic dashes.
• Consider keeping for print. If the text is destined for print production, typographic dashes are expected and should be preserved.

Most people don't type em dashes and en dashes on purpose. The characters infiltrate text through autocorrection, copy-paste, and platform-specific behavior.

• Word processor autocorrection. Microsoft Word converts two consecutive hyphens (--) into an em dash automatically. Google Docs has similar behavior. These autocorrections are enabled by default, and most users never change them.
• macOS text substitution. macOS has a system-wide text substitution feature that can convert dashes automatically across all applications, not just word processors.
• CMS rich text editors. WordPress's visual editor and other CMS rich text interfaces sometimes insert typographic dashes through their own autocorrection or through inherited browser behavior.
• Design tool exports. Copying text from Figma, Sketch, Adobe InDesign, or Canva often carries typographic dashes because these tools are designed for typographic precision.
• AI-generated content. Language models frequently output em dashes and en dashes because their training data includes properly typeset text.
• International keyboard shortcuts. On macOS, Option+Hyphen produces an en dash. Option+Shift+Hyphen produces an em dash. On Windows, Alt+0150 and Alt+0151 (numpad) produce en and em dashes respectively.

Em dashes and en dashes are the most common typographic troublemakers, but they're part of a larger family of characters that cause similar problems.

• Smart quotes (curly quotes). Left and right double quotes (U+201C, U+201D) and left and right single quotes (U+2018, U+2019) are distinct from the standard straight quotes on your keyboard. They cause the same encoding and rendering issues as typographic dashes and break code, JSON, HTML attributes, and API calls.
• Ellipsis character. The single-character ellipsis (U+2026) versus three periods (...). The Unicode ellipsis is one character that looks like three dots and can cause issues in systems expecting ASCII.
• Non-breaking hyphens. The non-breaking hyphen (U+2011) looks identical to a regular hyphen but prevents line breaks at its position and behaves differently in code and data processing.
• Fraction characters. Pre-composed fractions like one-half (U+00BD), one-quarter (U+00BC), and three-quarters (U+00BE) can replace their ASCII equivalents through autocorrection.

While this tool focuses on em dashes and en dashes specifically, the awareness should extend to the entire family of typographic substitutions. If your workflow produces em dashes, it's likely producing smart quotes and other special characters through the same autocorrection mechanisms.

Cleaning up after the fact works, but preventing contamination at the source saves time and eliminates the risk of missed characters.

• Disable autocorrect in your word processor. In Microsoft Word, go to File, Options, Proofing, AutoCorrect Options, and uncheck the options for replacing hyphens with dashes under the AutoFormat As You Type tab. In Google Docs, go to Tools, Preferences, and uncheck Smart Quotes. Each word processor has its own location for these settings.
• Use a plain text editor for technical content. When writing content destined for code, data, or cross-platform distribution, compose in a plain text editor like VS Code, Sublime Text, or Notepad++ rather than a word processor.
• Configure your CMS. WordPress's wptexturize function converts straight quotes to curly quotes and hyphens to dashes in rendered output. Disabling it with remove_filter('the_content', 'wptexturize') keeps characters as entered.
• Establish a paste-through step. Create a team habit of pasting content through a plain text intermediary (or this tool) before entering it into production systems.
• Set encoding explicitly. Configure your databases, server responses, and file encodings to use UTF-8 consistently. Encoding corruption happens when systems assume different encodings.

• Assuming all dashes are the same character. A hyphen, en dash, and em dash are three different Unicode code points. Code that checks for hyphens won't find em dashes. A search for "-" in your content won't match the other two. If you're searching for dashes programmatically, you need to target all three code points explicitly.
• Replacing dashes in content you don't control. If you're displaying user-generated content, third-party feeds, or syndicated articles, stripping their typographic dashes changes the author's text. Clean your own content. For other people's content, handle the display and encoding correctly rather than modifying the source.
• Not checking after CMS updates. CMS updates, plugin changes, and theme modifications can reintroduce typographic character handling that you previously disabled. A WordPress update that re-enables wptexturize silently converts all your plain hyphens back to typographic dashes in rendered output.
• Forgetting about existing content. Disabling autocorrect prevents new typographic dashes but doesn't fix the ones already in your database. After changing your settings, run existing content through the tool to clean up historical contamination.
• Over-replacing in typographically controlled environments. If your site renders consistently, your audience uses modern browsers, and your encoding is solid, typographic dashes serve their intended purpose and look better than hyphens. Don't strip them from a polished website just because they might cause problems in a hypothetical scenario.
• Ignoring meta tags and structured data. Typographic dashes in title tags, meta descriptions, Open Graph tags, and JSON-LD structured data can cause display issues in search results, social media previews, and data processors. Run your metadata through the tool alongside your visible content.