Em dash remover, one deletion

This em dash remover performs one substitution: every occurrence of U+2014 is replaced with the empty string. There is no second pass, no surrounding context is examined, and no other codepoint is matched.

That includes U+2013, the en dash, which this route leaves in place. It also includes the hyphen-minus, the smart quote pair, the ellipsis character and every whitespace character in the input. The output differs from the input in exactly one respect: it contains no em dashes.

The route renders no controls. Competing tools in this category offer a replacement selector with hyphen, comma, space and nothing as choices. This page has no selector because it has no choice to expose. The adjacent replacer route is where a replacement string is configurable.

Computation is local to the browser. No text is transmitted, and there is no rate limit and no length ceiling.

The dominant convention in generated prose is a spaced dash: space, U+2014, space. Deleting the codepoint alone leaves the two spaces adjacent, so the output contains a doubled space at every former dash position. This is not a defect. It is what deleting a character from between two spaces produces, and it is what any tool advertising deletion rather than substitution must do.

The tight convention, no spaces on either side, produces the mirror-image result: the two words on either side are concatenated. Both outcomes are predictable from the rule, which is the argument for stating the rule rather than describing the output as tidy.

Two remedies exist and both are one step. Follow the deletion with a whitespace normalisation pass, or use the replacer route with a comma or single space so the gap is filled at substitution time rather than repaired afterwards.

The procedure is fixed because the route exposes nothing to vary.

Step 1

Paste the source text. It is held in the page and transmitted nowhere.

Step 2

Run the removal. Every U+2014 is deleted in a single pass, computed locally.

Step 3

Inspect former dash positions for doubled spaces or concatenated words, then copy the output.

The two routes implement different operations, and the correct choice is determined by the source text rather than by preference.

Remover, this route

Matches U+2014 only, substitutes the empty string, exposes no options.

Replacer, the adjacent route

Matches U+2014 and U+2013, substitutes a configurable string, defaulting to a hyphen.

Spaced dashes

Favour the replacer, since the substitution fills the gap that deletion would leave doubled.

Tight dashes

Favour the replacer as well unless concatenation is wanted, which it occasionally is in identifiers.

Mixed dash types

Only the replacer covers both. Running this route on mixed input leaves every en dash in place.

The explanation that holds up has two parts and neither involves a hidden marker. The first is distributional: academic writing, journalism and professional publishing use the long dash freely, that corpus is heavily represented in training material, and the mark is therefore learned as a correlate of serious register rather than as one option among several.

The second is the absence of a regulating mechanism. A human writer registers that a construction has appeared four times on a page and varies it, because repetition is aversive to the writer as well as the reader. Nothing in generation performs that accounting, so a defensible preference compounds into a density that no editorial process would pass.

The premise underneath most tools in this category is that the mark identifies machine text. That premise is now actively disputed in mainstream technology coverage, on two grounds worth taking seriously: the mark has always been common in competent human prose, and its reputation is now sufficiently widespread that anyone deliberately obscuring provenance removes it before anyone inspects the document.

A signal that everyone knows about and that the motivated party removes is not a signal. This does not argue against the tool, it argues for a different justification of it. Removal is a typographic decision: a style guide prohibits the character, a rendering pipeline mishandles it, a code block should not contain it, an editor prefers otherwise. Those reasons survive the argument. Concealment does not.

No. The operation modifies punctuation and leaves every other property of the text identical: sentence length distribution, lexical choice, paragraph structure, argument shape. Those properties carry the bulk of whatever pattern is being discussed, and none of them is altered by a single-character deletion.

Detection systems emit signals, not authorship proof. There is no affiliation with any of them here and no prediction is offered about any verdict they produce.

The recurring case is a mechanical typographic constraint applied to a finished document.

Style guide enforcement

Publications that prohibit the character, where compliance is mechanical and repeated.

Technical documentation

A long dash inside a command, path or configuration fragment is incorrect regardless of prose style.

Constrained rendering targets

Legacy templates, mail clients and export pipelines with incomplete font coverage.

Editorial punctuation passes

Bulk removal followed by manual reinstatement of the few instances that were load-bearing.

Data hygiene

Stray long dashes in field values that break parsers, joins or exact-match comparisons downstream.