PasteCleanlyFind the character that makes two identical-looking strings differ
Start by isolating the shortest failing pair
A mismatch in a search, import or filename can be caused by one character that your screen does not show clearly. Copy the shortest failing value and an example that succeeds. Keep the original values separately. If you paste an entire export first, you may see many intentional spaces and marks without knowing which one caused the error. A pair of small samples gives each reported position a meaning.
Turn on Show markers in output and inspect the changed positions. A marker is a diagnostic label, not a character that appeared in the source. If the editor displays Invoice[NBSP]042, that bracketed label represents a nonbreaking space between two visible parts. Do not copy the marked-up preview as clean text. Turn markers off before copying a result unless you intentionally want a diagnostic annotation.
The inspector reports selected whitespace and control characters. An absent marker does not prove that two strings are equivalent. A curly quote, a different hyphen or an accent represented by a combining sequence can remain visible and still be a different string. If the problem persists after checking whitespace, use the character-level text comparison to identify other differences.
Read names, code points and positions in the report
A report entry can show a Unicode code point such as U+00A0, a readable name, a total count and the first place the mark occurs in the input. Use that first location to inspect the surrounding words. A high count can be expected in text copied from an application that uses nonbreaking spaces for typography. The number is evidence about how the text was written, not a recommendation to remove every occurrence.
Column positions are based on Unicode code points rather than the visual width of a line or how a textarea wraps on your screen. A combined emoji can contain several code points even though it looks like one symbol. Compare the reported line and nearby text if the apparent visual column seems off. A long line wrapped in the editor is not automatically two source lines.
When a support report needs to name the problem, describe the smallest affected fragment and the code point found. For example, say that a copied identifier contains U+200B between Order and ID. That is easier to verify than “the app adds something invisible.” Redact any private values before sharing the fragment.
Open the inspector and compare the markersDistinguish spaces, tabs and marks that have no width
An ordinary space separates words and often provides a place for a line to wrap. A nonbreaking space can keep a number attached to a unit or keep part of a phrase together. A tab can be a layout character in plain text or a delimiter in TSV. Replacing those characters indiscriminately can make a line look similar while changing how a document or data importer behaves.
A zero-width space can be inserted by copying or can be used deliberately in languages that mark opportunities for line breaks without visible spaces. A soft hyphen can indicate a possible place to break a word. A byte-order mark can appear at the start of text after copying or exporting. The fact that those characters are not visible in a normal line is not enough to decide they are errors.
Test a small piece of the actual input and identify which mark matters. If an ID fails because it contains a nonbreaking space where the system expects an ordinary space, a targeted replacement may be appropriate. If the same character appears in explanatory prose to keep a number and unit together, it may be worth preserving there. Work on the affected field, not every occurrence in a mixed document.
Use only the cleanup switch that fits the diagnosis
Replace nonbreaking spaces converts the supported no-break and figure space characters to ordinary spaces. That can help a system that expects a regular separator. It also changes the line-breaking behavior that the original text may have intended. Inspect a sample after enabling it. If you need the original typography in one version and a normalized identifier in another, keep both versions separately.
The other cleanup setting removes selected zero-width spaces, soft hyphens and byte-order marks. It is not a general option to remove every reported invisible character. Emoji joiners, non-joiners and directional marks may be reported without being removed by these settings. This distinction matters because those characters can be necessary for spelling, text direction or a combined symbol. Do not remove them simply because a report found them.
Use Clean whitespace for a broader spacing job such as trimming line ends or removing empty rows. Use Remove characters only when you know exactly what value should be removed. Keep the inspector as the diagnostic step before either operation, so you can explain what changed rather than applying several cleanup rules in the hope of finding a match.
Recognize when the problem is not an invisible mark
If accented text comes through as café rather than café, the letters are not merely invisible. The source may have been read with the wrong encoding. Use Fix broken accents for a known sample and try to get a clean export when possible. If the earlier application replaced a character completely, an inspector can show the replacement but cannot recover the lost character.
If two letters both look like é, they can be written with different underlying code-point sequences. This is a normalization question rather than a reason to strip accents. Try Normalize Unicode with a deliberately chosen form if your application expects canonical equivalence. Verify that the result still means the same thing to the receiving system.
Some visual differences come from fonts or shaping rather than different strings. A symbol may display as a missing box on one device and correctly on another. Compare the actual characters and test in the target application before changing the source. The guide to encoding and invisible characters walks through how to distinguish these cases with a small known sample.
Test the smallest correction in the application that failed
Save a short before-and-after pair. Apply one chosen option, turn markers off and paste the candidate into the exact search or import that previously failed. If it still fails, inspect both the candidate and a known working value; the remaining difference may not be one the cleanup switches cover. Change one thing at a time so you can tell which adjustment actually solved the problem.
If the source is a table, check whether whitespace is part of the representation. A tab between fields should not be removed just because it shows up as a control character. Read or convert the record with the CSV and TSV converter before changing values inside its fields. If the issue affects one column, work on that column rather than treating the entire export as prose.
For a handoff, state which character was found, whether it was intentional and what was changed. Keep the diagnostic version with markers separate from the final plain-text result. This prevents a colleague from mistaking bracketed labels for the original values. A successful check is a working value in the intended application, not simply a report with no markers left.
Check copied text and wrapping independently
If the problem only appears on a phone, compare the value copied from desktop and mobile using the same sample. Visual wrapping can differ between screens without a character changing. If the clipboard values actually differ, check the report before assuming that the target field inserted the mark. The source may have supplied different text on each device. Keep the literal values unchanged until you know which copy reproduces the failure, then verify the corrected value in the same mobile workflow.
Keep diagnostic markers out of the final copy
When sending a support note, label the bracketed representation as a diagnostic version and include only the affected fragment. If another system should receive the cleaned value, copy the result with markers off. Check its actual content by pasting it into a fresh input and inspecting it again. This catches the common mistake of copying an annotation such as [ZWSP] as literal characters rather than sharing the underlying corrected text.