◈ noclau

PRIVATE · FREE · IN YOUR BROWSER

Invisible Character Detector

Find invisible characters in text. Pasted text is processed in your browser.

Inspect your text

Your pasted text is processed in this browser.

0 characters · 0 special characters detected
Preview appears here

Inspection does not modify the original text. Directional and control marks are reported for manual review.

No special characters detected.

Diff preview

Run the tool to review changes.

Inspected text

Ready when you are

How to use this tool

Use the detector when a piece of text contains a gap, boundary, or copying problem that you cannot explain by looking at it. It identifies selected hidden and unusual characters and leaves the original sequence intact. The most useful approach is to bring a short sample with a known symptom, read the code points, and decide what to investigate next. Detection is a first step in a text review, not a judgment that every reported mark is unwanted.

Scroll the table sideways to see every column.

From a finding to a concrete check
FindingQuestion to askPossible next step
Hidden separator in a codeWhat is the exact expected value?Test limited removal
No-break spaceShould these words stay together?Check final wrapping
JoinerDoes it belong to an emoji or word?Preserve and review
Direction controlWhat is the intended reading order?Use a suitable editor

Begin with a small, intact sample

Copy the smallest passage that still behaves incorrectly. For an identifier mismatch, that may be one field. For a multilingual display issue, keep the surrounding words and punctuation because they influence the visible result. Save the untouched source elsewhere so an experiment cannot become your only copy. If the text is private, build an invented example with the same structure before sharing it.

Record the operation that fails. Does an exact search miss the phrase, does a form reject it, or does it wrap unexpectedly? Different destinations interpret characters differently. A report becomes more useful when you can connect a finding to one of these concrete behaviors. Without that context, deleting a mark may simply trade one unexplained result for another.

What this detector can find

The detector shares noclau's selected-character scanner. It reports U+200B, U+200C, U+200D, U+FEFF, U+2060, and U+00AD in the invisible category. It also reports selected special spaces, three em-dash variants, and selected control or directional characters. These categories help you distinguish a separator from a spacing choice or a direction-related mark.

It does not find every possible invisible Unicode character or expose hidden content stored outside plain text. A rich-text hyperlink target, CSS style, or embedded object is not part of this inspection. Some default-ignorable characters lie outside the scanner's supported set. Therefore No special characters detected should be read as a statement about these rules, not a universal assurance that nothing invisible exists.

Use the preview to distinguish ordinary whitespace

Show spaces displays ordinary spaces as dots in the input preview. Show tabs displays tabs as arrows. Those controls help identify ordinary gaps and indentation without modifying the input or output. A dot in the preview is a visual aid; it is not a new character inserted into your document. Turn the controls off to compare the normal appearance again.

The selected hidden marks are reported in badges with names, codes, and positions. An ordinary tab can be visible in the preview without appearing as a special finding. That is intentional. Standard line breaks are retained as document structure. If your problem involves extra blank lines or indentation, review them directly rather than expecting an invisible-character count to explain all whitespace.

Read the built-in demonstration

Try an example replaces the current input with a sentence containing an actual U+200B after hidden. The issue report should show that code point. Analyze text then generates an unchanged result. You can compare the input and output to learn the difference between identifying a mark and removing it. Save your own sample before loading the demonstration.

For a written bug report, describe a similar value as hidden[U+200B] followed by a space and another word. The bracket notation makes the otherwise invisible difference readable, but it is not literal tool input. Include a real short sample only when it is safe to share. A screenshot of the sentence alone may conceal exactly the difference you are trying to document.

Choose a next step based on the finding

An accidental separator inside a reference number may justify a removal experiment. A no-break space may call for a decision about wrapping. A joiner within an emoji or connected-script word should prompt a preservation check. A directional control needs contextual review in an appropriate editor. These are different paths, even if the characters are all difficult to see.

The detector itself offers no removal settings and preserves the sequence when you run it. Open the relevant cleaner only after deciding which change you want. Start from the untouched copy and review the resulting diff. For language-sensitive text, ask a knowledgeable reviewer to compare the actual words. A smaller report is not a reason to approve a change that alters meaning.

Account for positions and display limits

The report uses one-based code-point positions rather than byte offsets or visible character widths. A symbol represented by several code points changes the count accordingly. If you are comparing the report with a programming editor, check how that editor counts columns. Record the surrounding text as well as the position so another person can locate the finding reliably.

The badges show the first thirty findings. The counter may report more, and long previews can be shortened. For a long list, split the input into meaningful sections and inspect each relevant portion. Do not conclude that the end of a document is clear simply because its findings are not visible among the first badges. Use a small sample to make the review manageable.

Verify the hypothesis in the receiving application

After a targeted change, repeat the original failing operation. If a search begins to match, check that the text still has the intended words and punctuation. If a layout changes, inspect the actual saved or published page at the width where the problem occurred. A textarea does not reproduce every rendering or validation rule of your destination.

If nothing changes, retain the evidence and investigate another cause: ordinary whitespace, a different letter, a rich-text paste mode, or destination validation. The detector does not measure authorship or verify a watermark. It is useful for explaining a character sequence and testing an editing hypothesis. For support, send the minimal invented example, the reported code, and the operation you expected to succeed.

Related tools

Read the text cleaning guides