Line endings and BOM: inspect copied text carefully

Distinguish pasted text from the source file

Two files can display the same lines while containing different newline bytes or an encoding signature. A browser text field gives you the text it received, not a forensic copy of the original file. Start by deciding whether the question concerns the pasted characters or the source bytes. That distinction prevents an apparently clean paste from becoming false evidence about a file.

The browser text-field boundary

The textarea API normalizes CRLF and CR to LF. Pasting a Windows-style multiline string may therefore leave only LF values for the inspector to read. Its line-ending counts describe the current input exactly; they cannot recover whether the clipboard or original file used CRLF. A TXT download likewise represents the current result, not a byte-for-byte restoration of the source file.

first line
second line

In GlyphIndex, LF, CRLF and CR are shown separately. CRLF pairs are not double-counted as standalone CR and LF. Other separators, such as U+2028 LINE SEPARATOR, still appear in the code-point table but are not added to those three counters. Visual soft wrapping does not insert an LF into the string.

Recognize a possible BOM

name,value

A byte order mark is an encoding signature in a byte stream. In UTF-8 it is optional and does not select byte order; in other UTF encodings the byte order question differs. If a decoded U+FEFF reaches a text field, the inspector can reveal that character. It cannot tell whether a file decoder consumed a signature earlier or whether the character was inserted later.

A practical import workflow

1. Inspect the paste

   Use Unicode Inspector to identify LF, U+FEFF or other controls still present. Save the exact U+ values, not only a screenshot.

2. Return to the file

   If the problem concerns newline conventions or encoding, inspect a copy in a file editor or byte viewer that explicitly shows those details. Do not overwrite the original while investigating.

3. Follow the target format

   Check the receiving format’s encoding and newline rules before converting. The correct output for one CSV importer may differ from a plain-text note.

4. Verify the actual output

   Open or parse the exported file independently. Confirm text, encoding and newline expectations in the target application.

Do not run NFC or NFKC as a generic newline or encoding repair. Normalization answers a different question and does not reconstruct a wrongly decoded byte stream. If you compare two pastes in the inspector, remember that the textarea boundary has already folded their CRLF or CR differences.

All inspection stays in this browser and the input limit is 10,000 UTF-16 units. No file is uploaded. For exact bytes, retain the original file and use an appropriate local byte-level tool; GlyphIndex’s text input is deliberately a text workflow.