Normalize text line endings

Choose LF or CRLF as the target, and the result preserves every visible character while making each line boundary consistent. The response includes the normalized text, the selected target, and an exact count of line terminators that required conversion, making the operation easy to verify and automate.

Why consistent line endings matter

Text can look identical in an editor while containing different byte sequences between its lines. Unix and modern macOS tools normally use a single line-feed character, represented as LF, while Windows commonly uses a carriage return followed by a line feed, represented as CRLF. Older files may also contain standalone carriage returns. Mixed endings often appear after copying between applications, combining generated and handwritten content, extracting archives, or accepting contributions from several operating systems. They can create noisy version-control diffs, confuse command-line tools, break strict importers, and make checksums differ even when the visible words match. This capability treats line boundaries as data that can be standardized deliberately. It recognizes CRLF as one terminator rather than two, also recognizes lone LF and lone CR, and converts all three forms to the requested style. Ordinary carriage returns are therefore interpreted as line endings, which is useful for legacy text but should be understood when processing unusual control-character data. No letters, spaces, tabs, or other characters are reformatted.

How conversion and counting work

Provide the complete text in the text field and select exactly LF or CRLF in the target field. The converter scans from beginning to end, matching a CRLF pair before it considers either character alone. That ordering prevents a Windows line ending from being counted twice. For an LF target, every CRLF pair and every standalone CR counts as one changed line ending, while an existing standalone LF remains unchanged. For a CRLF target, every standalone LF and standalone CR counts as one change, while an existing CRLF pair remains unchanged. The changed value reports terminators converted, not characters inserted or removed. For example, replacing one CRLF with LF is one change even though the output is one code unit shorter. Text without any line ending returns unchanged with a count of zero, as does text already using the chosen style. Empty text is valid because it is still a well-defined text value and requires no conversion. The operation is deterministic, so identical inputs always produce identical outputs.

Using the result safely in a workflow

Use the returned text directly as the canonical value for writing a file, calculating a digest, comparing revisions, feeding a parser, or sending content to another capability. Keep the changed count alongside migration logs when you need evidence that normalization occurred; a zero confirms that the input was already compliant, while a positive number tells you exactly how many boundaries were rewritten. The target field is repeated in the result so downstream steps do not need to rely on configuration stored elsewhere. This tool does not infer a preferred convention from a filename or operating system, because silent guessing makes automated pipelines harder to audit. Choose LF for repositories and Unix-oriented processing when that is your established convention, or CRLF for software and exchange formats that explicitly require Windows-style boundaries. If an unsupported target is supplied, the request fails instead of silently falling back. Normalization is limited to line terminators: it does not trim trailing spaces, change tabs, add a final newline, alter encoding, or rewrite Unicode normalization forms.