Why does copying text sometimes include invisible characters?

Separate what the text contains from what the app shows. In web pages, whitespace can remain in the underlying text even when CSS changes how it appears. The DOM text and rendered appearance are not always identical. That browser-specific behavior does not tell us what every copy-and-paste path transfers, but it shows why looking at the screen alone may not settle the question. [S2]

Try a small comparison:

1. Keep the original unchanged and make a separate copy for testing.
2. Paste it into a plain-text editor, if available. Look for a setting that reveals whitespace, such as spaces or line breaks.
3. Compare the original, test copy, and destination. Note the exact location where the appearance or behavior changes.
4. If the difference remains unclear, inspect the character codes at that location with a suitable tool.

If you find a character in the copied text that has no visible mark, that points to a content difference. If the text appears the same but looks different only in one app, a display or formatting difference is another possibility. Neither observation alone identifies the cause.

Look for a character with no visible mark between letters. For example, U+200C (zero-width non-joiner) and U+200D (zero-width joiner) have no visual representation but can influence how text is interpreted or rendered. U+FEFF is a byte-order mark; when it is not at the start of a script, it is also called a zero-width no-break space. [S1]

Those examples show why “invisible” does not mean “unwanted.” A character can have an effect even when you cannot see a mark for it. Finding one does not, by itself, establish that it caused your copying problem or that it is safe to delete. Record the character’s code point and position first, then consider what the text is meant to say and where it will be used.

Use a small, reversible test. Imagine the line contains AB—here, the notation represents U+200C between the letters, not the literal characters \u0000. The character has no visible mark, so the code point in this example is stated explicitly. It is an illustration, not a diagnosis of your text. U+200C is among the zero-width characters documented as having no visual representation. [S1]

1. Keep the original unchanged and make a separate test copy.
2. Compare the copied line with the original, focusing on the location of the unexpected behavior.
3. If your inspection tool can identify the character, note its code point and position. A whitespace marker may help locate a difference, but does not necessarily identify the exact character.
4. In the test copy only, replace that one character with an ordinary space and check whether the specific problem changes.
5. If the result is unclear or creates new behavior, keep the original and do not apply the change to it.

This test can help narrow down possibilities, but does not establish how every app or clipboard handles text.

Record the two apps involved, the exact location of the unexpected spacing or behavior, and whether a plain-text copy looks different. If you identify a character, include its code point and position in a redacted example rather than sharing sensitive text. Note whether changing just that character in a separate test copy changed the result.

Avoid replacing every unusual-looking character at once. That removes the comparison and may change text in ways you did not intend. A useful report is specific but does not guess: “In a test copy from [source app] to [destination app], the text at [location] behaves differently. I inspected it as [character/code point, if known]. Replacing only that character in the test copy [did/did not] change the issue.” If you do not know the code point, say so. For sensitive text, use only an inspection method permitted for that text; share a redacted example when asking for help.