Line Ending Converter
Convert UTF-8 file endings between CRLF, LF and CR, with final-newline and BOM controls.
This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.
Inspect actual CRLF/LF/CR endings in a UTF-8 file and convert them with explicit final-newline and BOM choices.
How to use it
- 1Load the original UTF-8 file for exact counts, or paste browser-normalized text.
- 2Choose CRLF, LF or CR and the final-newline/BOM settings.
- 3Review original and output counts, then download the generated bytes.
Example
- Input
- alpha\r\nbeta\ngamma\r
- Output
- alpha\nbeta\ngamma\n
LF output with Preserve final newline; notation shows bytes, not literal backslash letters.
What happens to your data
Original file content stays outside the preview textarea so its line endings are not silently normalized. Processing and downloads are local. Binary/invalid UTF-8 input is refused; no encoding guess or content upload occurs.
Last updated October 2026
A script, configuration file or data export can contain Windows CRLF, Unix LF, classic Mac CR, or a mixture of all three. They may look identical in an editor while creating noisy diffs or breaking a receiving system's expectations. Load the original UTF-8 file to inspect its actual endings, then convert them deliberately without trimming spaces, merging lines or changing character encoding.
The important word is original. A browser text box normalizes its API value to LF, so pasted text cannot prove which byte endings the source file had. This converter retains a loaded file separately from the read-only preview. Its CRLF/LF/CR counts come from that retained content, and its download is built from the requested bytes rather than copied back from the preview.
How it works
Each CR followed immediately by LF is counted as one CRLF ending. A remaining CR is counted as CR, and a remaining LF as LF. A source with more than one kind is marked mixed. The line count excludes the imaginary extra line after a final ending: alpha followed by LF is one terminated line, while alpha LF beta is two lines. Empty text has zero lines. These are disclosed text-counting conventions, not a diagnostic of the file's business meaning.
Choose LF, CRLF or CR output. The converter replaces only those three recognized ending sequences, leaving spaces, tabs, letters and the order of text intact. Unicode line separator U+2028, paragraph separator U+2029 and other Unicode characters are not treated as CR/LF endings. No Unicode normalization, punctuation cleanup or automatic indentation is performed. A text file with no line endings remains without them unless you choose to ensure a final newline.
Final-newline behavior is explicit. Preserve retains whether the source ended in a line ending and preserves all existing blank lines while converting their separators. Ensure adds one ending only when none is present; for empty input it creates one ending. Remove one deletes exactly one terminal ending, not every trailing blank line. A file ending with two newlines therefore still ends with one after Remove one. That choice protects intentional blank lines from a broad trim operation.
The leading UTF-8 byte-order mark, when present in an uploaded file, is stored separately as an encoding marker. Preserve file BOM restores it, Include BOM adds one, and Omit BOM removes that marker. A U+FEFF pasted into the text box remains text rather than being assumed to be a file marker. Consequently an explicitly added marker and a literal leading U+FEFF can coexist. Inspect that distinction rather than assuming every invisible leading character was removed.
Files must be valid UTF-8 and no larger than 1 MiB; output is capped at 4 MiB. UTF-16/UTF-32 BOMs and malformed UTF-8 are refused with no guessed conversion. NUL and selected C0/DEL control bytes also stop processing as outside this plain-text subset. This conservative check is not a universal binary detector or a claim that an accepted file is safe to execute. Use the Text Encoding Converter first when you know the source is in another supported encoding. A filename extension does not prove an encoding.
The source preview is read-only for a loaded file or the mixed-ending example. Replace with pasted text clears it and starts an editable, browser-normalized source. The result preview inserts visible CRLF, LF or CR markers for inspection; those markers are not written to the download. Previews show at most 12,000 original characters, while the generated file includes the entire accepted input. There is deliberately no result-copy shortcut: clipboard and text-box normalization are unsuitable evidence for exact output endings.
All parsing and byte generation happen locally, without source upload or browser-storage persistence. A file or setting change clears the old download, and a late file read is ignored after a newer edit or Clear. Page assets and anonymous usage events can use the network without the source text. The downloaded copy remains on your device. Match the target application's requirements, retain a backup and compare actual bytes if a version-control or import workflow is sensitive to endings.
Worked example: Normalize mixed endings without losing the last newline
- Input
- alpha\r\nbeta\ngamma\r
- Result
- alpha\nbeta\ngamma\n
Backslash notation shows the bytes: the source has one CRLF, one LF and one CR. LF output with Preserve final newline has three LF endings and no CR bytes.
Common use cases
- Repair a mixed-ending script before reviewing its version-control diff
- Prepare a known UTF-8 export for a receiver that requires CRLF
- Inspect a file's actual final-newline and BOM state
- Convert classic Mac CR text without joining or trimming its lines
Frequently asked questions
How do I convert CRLF to LF or LF to CRLF?＋
Load the original UTF-8 file, choose LF or CRLF output and convert. Inspect the original and generated ending counts, then download the file. The visible preview contains inspection markers; the file contains actual ending bytes.
Why does pasted text show LF when my file was CRLF?＋
Browser text-area values normalize line breaks. Paste is useful for text content but cannot establish original file endings. Load the original file for trustworthy CRLF/LF/CR counts; the file is retained outside the preview control.
Does Remove one final newline delete trailing blank lines?＋
It deletes exactly one final ending. It does not repeatedly trim all trailing endings. A source ending with two line endings still has one after that option; Preserve and Ensure retain existing trailing blank lines.
What happens to a UTF-8 BOM?＋
A detected leading file marker is preserved, added or omitted according to your setting. Pasted U+FEFF remains part of the text. The marker is separate from CR/LF conversion and is included in the generated byte count.
Can this repair a UTF-16 file or a Word document?＋
No. This is a strict UTF-8 plain-text operation. It does not guess encodings or convert document formats. Use the original source and an encoding converter when its actual encoding is known.
Does it remove spaces, change Unicode or process separators such as U+2028?＋
No. Only CRLF, standalone CR and standalone LF are ending sequences here. Spaces, tabs, Unicode line/paragraph separators and accepted text are retained. Final-newline and BOM changes happen only through their explicit controls.
Is there a universally correct line ending?＋
No. Choose what the receiving format, repository or application requires. LF and CRLF are conventions for different workflows; converting one does not make the content more accurate or fix unrelated parsing errors.
Related tools
Text Encoding Converter
Decode supported text encodings and save UTF-8 or UTF-16 with strict byte checks and BOM options.
Text Diff Checker
Compare two texts side by side. Highlight character, word, or line changes and download a private diff.
Unicode Normalizer
Normalize Unicode locally with code-point comparisons and clear NFC, NFD, NFKC and NFKD choices.
File Hash Checker
Get SHA-1, SHA-256 and SHA-512 checksums for a file, then paste the expected value to confirm a match.