Em dashes, smart quotes, and the other tells of AI text

What the tells actually are

AI assistants are trained on published, professionally typeset prose, where typographic conventions differ from what a keyboard produces. The result is output using characters most people never type:

• Em dash (—, U+2014) where a keyboard user would type a comma, a colon, or a plain hyphen.
• En dash (–, U+2013) in numeric ranges, where most people type a hyphen.
• Curly quotes (" " ' ') instead of the straight " and ' a keyboard produces.
• A true ellipsis character (…, U+2026) instead of three full stops.
• Non-breaking spaces and occasionally zero-width characters carried through from rendering.

None of these are errors. They are correct typography — which is precisely why they stand out in contexts where people type rather than typeset.

Why the em dash in particular

The em dash draws attention because it is both distinctive and frequent. It is not on any standard keyboard: producing one takes a special shortcut, an OS-level replacement, or a copy-paste. Most people simply use a comma or a hyphen instead.

Assistants use it liberally, because published prose does. A paragraph with two or three em dashes in it is unusual for typed text and unremarkable for edited text, and that contrast is what people notice.

The part that is not cosmetic

Beyond appearance, these characters cause concrete failures — which is the better reason to normalise them:

• CSV and data imports can mis-parse non-ASCII punctuation, or store it mangled if the encoding is not UTF-8 end to end.
• Code and config files break outright when a curly quote replaces a straight one — every language expects " or ', not " or '.
• Search and exact matching fail, because "don't" with a curly apostrophe is a different string from "don't" with a straight one.
• Legacy systems that are not UTF-8 clean render them as mojibake such as — or ’.
• URL slugs and filenames generated from text containing them can end up malformed.

A developer pasting AI-written text into a config file and getting a parse error is meeting exactly this problem.

Normalising without flattening everything

The useful conversions are specific:

1. 1
   Em dashes to a spaced hyphen or a comma

   A spaced hyphen preserves the pause; a comma often reads more naturally in ordinary prose. Which is right depends on your house style.

2. 2
   En dashes in ranges to a plain hyphen

   And with no surrounding spaces — "12-15" rather than "12 - 15", since a range is not a clause break.

3. 3
   Curly quotes to straight quotes

   The single most valuable conversion for anything touching code, config, or data.

4. 4
   Ellipsis character to three full stops

   Safer across encodings and matches what a keyboard produces.

5. 5
   Invisible characters removed

   Zero-width and non-breaking characters, which are pure liability in plain text.

Two things should survive: emoji, which use zero-width joiners internally and break apart if those are stripped indiscriminately, and accented letters, which are ordinary content rather than typographic decoration.

A note on "AI detection"

Some tools market this cleanup as making text undetectable as AI. That framing is worth treating sceptically.

Typography is not what detection tools primarily analyse — they look at statistical properties of word choice and sentence structure, which normalising punctuation does not change. Removing em dashes does not make AI-written text read as human-written; it makes it read as AI-written text with different punctuation.

The honest reasons to normalise are the ones above: a house style that specifies straight quotes and no em dashes, a CSV import that mangles non-ASCII, a config file that will not parse, or a search that keeps missing. Those are real problems with a real fix.