How to remove all fourteen hidden characters from ChatGPT text

A hidden character is a codepoint occupying a position within a string while producing no visual output. This is not a rendering defect: the character exists in the byte stream, and any process reading that stream, a search function, a URL parser, a JSON validator, treats it as content, independent of whether a human reader perceives it.

Text copied from ChatGPT, or any comparable chat interface, routinely contains several of these. Their presence does not require deliberate insertion as a signature; formatting preservation, cursor tracking and punctuation normalisation during the copy operation account for nearly all of it.

Rich-text rendering inserts zero-width characters at formatting boundaries so that structure survives a copy operation. Bidirectional text support requires directional control characters wherever a document mixes left-to-right and right-to-left scripts. Certain interfaces substitute space variants for the plain space character during normalisation. Each mechanism is ordinary and independently explicable; their combination is what produces the specific set of fourteen characters this article documents.

This is not an approximation. It is the exact set a hidden-character scanner checks for, grouped by function rather than presented as an unordered list.

Zero-width space, non-joiner, joiner (U+200B, U+200C, U+200D)

Each renders as nothing within or between words. The joiner additionally constructs compound emoji sequences, requiring the scanner to distinguish that function from residue.

Word joiner (U+2060)

Typically found adjacent to a dash. Produces no visual effect but reliably breaks exact-match search.

No-break, narrow no-break, hair space (U+00A0, U+202F, U+200A)

Visually indistinguishable from a normal space but distinct codepoints. Standard treatment substitutes an ordinary space rather than deleting the character outright.

Soft hyphen (U+00AD)

Invisible except at the precise point a line wraps, at which point a hyphen appears in a word never hyphenated by the writer.

Byte-order mark (U+FEFF)

Intended for the start of a file to declare its encoding. Stranded mid-document, it invalidates strict parsers.

Five directional formatting controls (U+202A to U+202E)

Constructed for mixing left-to-right and right-to-left scripts. Left in place outside that context, they can alter the display order of surrounding characters.

The procedure is identical regardless of which of the fourteen characters is present.

1. Copy using the interface's dedicated control

Manual selection can behave differently from the platform's copy function. The dedicated control produces the version most likely to carry hidden characters, which is the version requiring inspection.

2. Inspect before modification

Submit the raw text to a scanner that identifies each hidden character by name and position. An unspecified warning is materially less useful than a stated codepoint.

3. Remove in a single operation

A correctly built cleaner removes the zero-width characters and controls entirely and normalises the space variants to an ordinary space, without altering a single visible word.

A zero-width space within a heading bisects the keyword, so the visible title and the parsed slug diverge despite appearing identical. A non-breaking space within a shell command or a YAML file produces an error whose cause is not visually apparent.

A byte-order mark positioned mid-document invalidates a JSON file under strict parsing. Directional controls left within a filename or a URL can alter the displayed character order, a security consideration in addition to a cosmetic one. None of these failures presents as a Unicode issue; each presents simply as an unexplained defect.

Manual removal is possible: an editor exposing invisible characters, or fourteen sequential find-and-replace operations, one per codepoint. It is also error-prone, since omitting one of the fourteen leaves the underlying defect unresolved.

A dedicated scanner performs the equivalent search in a single operation and reports its findings prior to any modification, which matters when verification, rather than blind trust in an automated correction, is the objective.

The zero-width non-joiner performs a required function in Persian and several Indic scripts. Removing it indiscriminately from text in those languages alters how a word displays, rather than merely removing residue. Any scanner's findings should be reviewed against this exception before a bulk removal is accepted.

No, and it establishes nothing about the converse either. These characters appear in text sourced from PDFs, word processors, translation software and ordinary web pages unconnected to a language model. Their presence is evidence of how text was produced or handled, not evidence of authorship.

Removing them resolves a specific, verifiable category of formatting and parsing defect. It has no bearing on how a detector evaluates the writing itself, which depends on sentence-level statistical properties rather than byte-level content.