Trusting pasted text as original byte evidence
A browser textarea exposes an API value whose line breaks are normalized to LF. Upload the original file when CRLF versus LF evidence matters.
Line Ending Detector for CRLF, LF, and Mixed Text Files
TextRuns in Your Browser (No Uploads)
Inspect a local text file's original bytes to count CRLF, LF, CR, NEL, LS, and PS line endings, locate style transitions, and check the final line terminator. The tool keeps the original byte evidence separate from decoded text, reports encoding and truncation limits, and never rewrites the uploaded file or treats one sample as proof of repository-wide consistency.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Remove a BOM from a CSV or text file without re-encoding it
Use this workflow when an invisible leading signature changes the first CSV header or script token. Work from the original bytes, distinguish UTF-32 LE from its UTF-16 LE prefix, and do not remove UTF-16 or UTF-32 byte-order evidence until the destination is known.
OpenRelated toolRemove BOM from UTF-8, UTF-16, and UTF-32 Files
Remove one supported leading BOM from exact file bytes without re-encoding the remaining content.
OpenRelated toolDetect Text File Encoding from Byte Evidence
Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
OpenRelated toolRemove Empty Lines | Remove or Collapse Blank Rows
Remove every blank row or collapse repeated gaps, with exact counts and line-ending diagnostics.
OpenHow to Use This Tool
Select the original text, script, config, CSV, or log file instead of pasting it into a textarea.
Run the inspection to read the file bytes locally without changing them.
Confirm the encoding evidence and review any binary, legacy, malformed Unicode, or BOM-less warnings first.
Compare CRLF, LF, CR, NEL, LS, and PS counts and identify the actual dominant style.
Use the transition table to locate the first lines and byte offsets where the style changes.
Check the final terminator, then choose a conversion and repository policy only if the target workflow requires one.
When to Use This Tool
Debug cross-platform scripts
Find CRLF in a shell script, Docker entrypoint, or CI command file before Linux interprets a carriage return as part of the command or interpreter path.
Explain unexpected Git diffs
Identify a small set of mixed lines before an editor or formatter rewrites the entire file and creates a noisy review.
Validate data files before import
Check CSV, logs, and exported records before an importer treats mixed record separators inconsistently.
Audit generators and build output
Verify whether a generated file ends with the required newline and whether every emitted record uses the same terminator.
Review Unicode text files
Inspect UTF-16 or UTF-32 configuration and interchange files without mistaking their NUL bytes for separate line endings.
Common Mistakes
Counting CRLF as two breaks
CRLF is one two-code-point newline sequence. Counting every CR and LF independently doubles Windows line endings and produces a false mixed result.
Ignoring a small minority style
The largest count identifies the dominant style, but even one different terminator can still break a script or create Git noise. Review the transition table.
Treating binary byte patterns as text lines
Raw 0D and 0A bytes inside binary data are not reliable text boundaries. Treat the report as unconfirmed when the encoding evidence says binary data is suspected.
Converting without checking Git policy
One cleanup pass does not define repository policy. Verify .gitattributes, editor settings, and core.autocrlf before committing a broad normalization.
Examples
Locate mixed endings in a shell script
The file begins with a Windows-style shebang line, switches to LF, and returns to CRLF. The first style change is reported on line 2 with its original byte offset.
Input
#!/bin/sh
printf 'ready'
exit 0
Output
CRLF: 2; LF: 1; consistency: mixed; first mixed line: 2; final terminator: CRLFInspect UTF-16LE line endings
A UTF-16LE BOM selects two-byte code units, so 0D 00 0A 00 is counted as one CRLF instead of separate raw bytes.
Input
FF FE 61 00 0D 00 0A 00 62 00 0A 00Output
Encoding evidence: UTF-16 LE; CRLF: 1; LF: 1; consistency: mixedHow byte-accurate line ending inspection works
CR is U+000D, LF is U+000A, and CRLF is the ordered pair U+000D U+000A. The scanner consumes CRLF together before considering lone CR or LF.
UTF-8 and ASCII-compatible files are inspected at byte boundaries. Confirmed or conservatively inferred UTF-16 and UTF-32 files are scanned using their endian-specific two- or four-byte code units.
The report also keeps NEL U+0085, LINE SEPARATOR U+2028, and PARAGRAPH SEPARATOR U+2029 separate so non-ASCII newline functions stay visible.
Each retained occurrence records a one-based line number, original zero-based byte offset, and byte length. Style transitions are bounded for stable memory use while total counts remain exact.
A final terminator is present only when the last recognized newline sequence ends at the final file byte. A trailing malformed or unrelated byte makes that check false.
The 25 MiB limit bounds browser memory and runtime. The scan is read-only and never claims an exact legacy charset or text interpretation from binary-looking bytes.
Frequently Asked Questions
Why does this detector require a file instead of pasted text?
HTML textarea API values normalize line breaks to LF, so pasted text cannot reliably preserve the source file's CRLF or CR bytes. This tool reads the selected file directly instead.
Does the detector modify or convert my file?
No. It is a read-only inspector. Use the related CRLF/LF converter only after choosing a target style and checking repository or downstream requirements.
How are UTF-16 and UTF-32 files handled?
A BOM confirms UTF-8, UTF-16, or UTF-32 byte order. Without one, UTF-16/32 recognition uses conservative NUL-lane evidence and is labelled heuristic; ambiguous legacy encodings remain undetermined.
What does an absent final terminator mean?
It means the last content line is not closed by CRLF, LF, CR, NEL, LS, or PS. Some tools accept that, while repositories and POSIX-oriented workflows often prefer a final newline.
Why is a result still shown for suspected binary data?
The scanner can show raw newline-shaped byte counts, but it warns because those bytes may belong to binary structure rather than text records. Confirm the file type before acting on them.
What are NEL, LS, and PS?
They are Unicode NEXT LINE U+0085, LINE SEPARATOR U+2028, and PARAGRAPH SEPARATOR U+2029. The tool reports them separately rather than silently folding them into LF.
Does my file stay private?
Yes. File reading and analysis run in your browser. Aggregate run metrics can include byte count and ending counts, but not the file name or file contents.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: This check paired the exact “Repair a Windows-edited deployment script” input with Line Ending Detector for CRLF, LF, and Mixed Text Files. We followed “Preserve the failing file and inspect its original bytes”, captured the result after “Choose the target from the execution and repository policy”, and compared it with the example while treating “Pasting the file into a textarea before detection” and “Removing CRLF but leaving a BOM before the shebang” as explicit boundary questions.
Expected result: The repaired script changed three CRLF sequences to LF, retained four final line terminators, and restored the byte-zero shebang without altering command text.
Open the tested workflowRelated workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Remove a BOM from a CSV or text file without re-encoding it
Use this workflow when an invisible leading signature changes the first CSV header or script token. Work from the original bytes, distinguish UTF-32 LE from its UTF-16 LE prefix, and do not remove UTF-16 or UTF-32 byte-order evidence until the destination is known.
Workflow guideDetect a text file's encoding before import
Use the original file bytes to distinguish confirmed Unicode signatures from structural evidence and conservative heuristics. Then verify a candidate decoder against known headers and multilingual values before a full import.
Workflow guideRecover garbled text from the original file bytes
Character-set detection narrows decoder candidates; it does not reverse already-corrupted text by itself. Preserve the source, identify where the wrong decode happened, compare controlled previews, and convert once only after known values round-trip correctly.
Workflow guideCompare text revisions and verify a unified diff
A useful diff workflow starts with exact input, not filters. Preserve the source files, compare line structure and final newlines, explain every raw addition and removal, use equivalence options only as a diagnostic view, and validate any exported patch against a disposable copy before it reaches a repository or deployment.
Workflow guideConvert CRLF to LF for Git and shell scripts safely
Use this incident workflow when a Windows-edited script fails on Linux, Git shows a whole-file line-ending diff, or generated text mixes CRLF and LF. Inspect first, normalize only confirmed text, then enforce the decision with repository settings.
Workflow guideRemove line numbers from copied text without deleting real values
Use this workflow when code viewers, PDFs, transcripts, legal documents, or exported notes add numbers at the start of copied lines. Keep the source, distinguish marked numbering from ambiguous plain integers, compare cleanup evidence, and validate the result before reuse.
Workflow guideRemove copied gutter numbers from a stack trace
Use the explicit Plain gutter format when an IDE, PDF, or documentation viewer copied a leading integer before every stack-trace line. Compare the result with the raw trace, preserve diagnostic values, redact secrets, and only then share it.
Workflow guideAdd fixed labels and delimiters to copied lines safely
Use this workflow for a plain list copied from a spreadsheet, report, log, or editor when every row needs the same label, marker, wrapper, or delimiter. It keeps line boundaries exact and separates bulk text insertion from JSON, CSV, SQL, shell, or HTML validation.
Workflow guideVerify text limits across Unicode counting units
A reliable text-limit check starts from the destination contract, preserves the source representation, measures several Unicode units, includes normalization and invisible-character fixtures, exercises the limit on both sides, and verifies the value after storage or transmission.
Related Tools
Continue with another maintained workflow
Remove BOM from UTF-8, UTF-16, and UTF-32 Files
Remove one supported leading BOM from exact file bytes without re-encoding the remaining content.
Text
Detect Text File Encoding from Byte Evidence
Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
Encoding
Remove Empty Lines | Remove or Collapse Blank Rows
Remove every blank row or collapse repeated gaps, with exact counts and line-ending diagnostics.
Text
Text Cleanup Workbench | Clean Lists, Logs, and Paragraphs
Number, filter, sort, split, merge, trim, and wrap text locally in one repeatable workspace.
Text
Unicode Normalizer | Compare NFC, NFD, NFKC and NFKD
Normalize Unicode with code-point evidence and explicit compatibility-loss warnings.
Encoding