Prepare files requiring CRLF
Select CRLF and download. Inspect endings with an editor that exposes them instead of inferring bytes from visual layout.
Line ending converter
Convert text between LF, CRLF and CR line endings. Processing stays local in your browser.
- Clipboard
- Export
Data not sent
Converted text
Was this tool useful?
How does this tool work?
Normalize text line endings to LF, CRLF or CR for an editor, legacy application or file protocol. Conversion acts on actual line-ending characters, not the letters in a code escape such as \n. Processing stays in your browser and retains spaces, tabs and blank lines. The selected separator determines the generated file even when its preview looks identical in other modes.
The engine recognizes CRLF as one line ending before handling isolated CR and LF characters. Each recognized separation is replaced with your choice. LF is U+000A, CRLF combines U+000D with U+000A, and CR is U+000D alone. Other Unicode separators such as U+2028 are outside this normalization.
Lines are neither sorted nor cleaned. An existing final newline is retained; none is added when the source has no final separator. Consecutive line endings remain consecutive, retaining blank lines. Trailing spaces on lines are not removed.
HTML textareas normalize their value to LF, so the preview cannot directly display the chosen CRLF or CR bytes. Exact generated text is held separately for copying and downloading. Clipboard systems and destination applications may impose their own conventions afterward. Prefer downloads when exact bytes matter.
This is not character-set transcoding. Imported files are read as browser text and downloaded output is UTF-8 text. Conversion cannot repair a source decoded with the wrong encoding. Actual line breaks inside quoted fields change too: the engine does not understand CSV, SQL or other format grammars.
How to use this tool
Supply text to normalize
Paste content or import an accepted text file. Inspect accents and special characters to confirm correct source decoding.
Choose LF, CRLF or CR
Select the recipient’s required mode and convert. The appearance of lines does not identify the generated separator.
Download and inspect
Retrieve the file and check endings in your environment. Editing the source or mode hides old output to avoid a stale export.
Use cases
Normalize an excerpt before comparison
Use one separator to remove a platform-specific difference. Other text differences are not eliminated.
Produce legacy CR-separated text
Use CR only when a target application requires it. Current macOS systems normally use LF rather than legacy CR.
Examples
Normalize mixed endings to CRLF
Escaped JSON notation makes invisible characters readable. All three recognized separators become CRLF, retaining the final newline.
Input
"a\r\nb\rc\n"Result
"a\r\nb\r\nc\r\n"Retain a blank line without adding a final newline
In CR mode, two consecutive LF characters become two CR characters. The blank line remains and the final b gains no extra separator.
Input
"a\n\nb"Result
"a\r\rb"Tips and best practices
- Choose the recipient’s expected format rather than assuming the convention of your own system.
- Editors may save files using their own settings. Check the save configuration too.
- Do not process binary files as text; their structure is not merely a sequence of readable lines.
- For quoted multiline CSV cells, decide whether changing their internal line breaks is actually intended.
Sources and references
- Unicode Newline Guidelines (opens in a new tab), Unicode ConsortiumPage in English
Frequently asked questions
Why do LF and CRLF look the same in the preview?
An HTML textarea shows lines but normalizes its DOM value to LF. Downloads use separately retained exact output to honor the selected mode.
Does conversion add a newline after the last line?
No. It retains whether a final separator exists, along with blank lines. It does not automatically trim line spaces.
Why does literal \n text stay unchanged?
A backslash followed by n is two written characters, not LF. The tool changes real line endings and does not decode language escape sequences.
Does this also convert UTF-8 to Windows-1252?
No. It normalizes endings in already decoded text. Character encodings need separate handling; downloaded output is UTF-8 text.
Related tools
Keep going with these tools
Tools similar or complementary to this one.
Similar tools
Compare two texts line by line and quickly spot additions, deletions and changes.
DevelopmentFeaturedUse this tool
Remove extra spaces, repeated tabs and empty lines from copied text.
DevelopmentFeaturedUse this tool
Validate CSV structure and quickly identify problematic rows or columns in your data.
DevelopmentFeaturedUse this tool
Read next
GuideConcepts and technologiesIntermediate
ISO week, Unix timestamp and dates in computing: understanding time representations
Understand ISO 8601 week numbers, Unix timestamps in seconds or milliseconds, and the difference between human-readable dates and technical time values.
28 August 20264 min