Last updated
Detecting Line Endings in a File
Paste text into the converter and it detects the line ending format automatically:
Input analysis:
CRLF (\r\n): 47 occurrences
LF (\n): 0 occurrences
CR (\r): 0 occurrences
Format: Windows (CRLF)
Input analysis:
CRLF (\r\n): 12 occurrences
LF (\n): 35 occurrences
CR (\r): 0 occurrences
Format: Mixed (inconsistent line endings)
Mixed line endings are the most problematic — they cause inconsistent behavior across tools and should always be normalized to a single format.
Converting Windows (CRLF) to Unix (LF)
A shell script created on Windows fails on Linux with a cryptic error:
# Error on Linux when running a Windows-created script:
bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory
# The ^M is the carriage return character (\r)
# Fix: convert CRLF to LF
Paste the script into the converter, select "Convert to LF (Unix/Linux)", and copy the output. The ^M characters are removed and the script runs correctly on Linux.
Visualizing Invisible Characters
The converter shows line endings as visible symbols:
// CRLF visualization
Hello World↵⏎
Second line↵⏎
Third line↵⏎
// LF visualization
Hello World↵
Second line↵
Third line↵
// CR visualization (classic Mac OS)
Hello World⏎
Second line⏎
Third line⏎
↵ represents LF (\n), ⏎ represents CR (\r). Seeing these invisible characters makes it immediately obvious what line endings are present.
Converting for Docker/Container Use
Files used in Docker containers must have LF line endings. A Dockerfile or entrypoint script with CRLF will fail:
# Dockerfile entrypoint script with CRLF — fails in container
#!/bin/bash\r\n
set -e\r\n
echo "Starting application..."\r\n
exec "$@"\r\n
# After converting to LF — works correctly
#!/bin/bash
set -e
echo "Starting application..."
exec "$@"
Convert all shell scripts, Dockerfiles, and configuration files to LF before building Docker images.
Git Configuration for Line Endings
Configure Git to handle line endings automatically:
# Windows developers — convert LF to CRLF on checkout, CRLF to LF on commit
git config --global core.autocrlf true
# Mac/Linux developers — convert CRLF to LF on commit, no conversion on checkout
git config --global core.autocrlf input
# Disable automatic conversion (handle manually)
git config --global core.autocrlf false
# .gitattributes — fine-grained control per file type
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.ps1 text eol=crlf
*.png binary
*.jpg binary
Batch Converting Multiple Files
Normalize line endings across an entire project:
# Using the converter's batch mode — paste multiple files
# Or use command-line tools:
# Convert all .sh files to LF (Linux/Mac)
find . -name "*.sh" -exec sed -i 's/\r//' {} \;
# Convert all .sh files to LF (Windows PowerShell)
Get-ChildItem -Recurse -Filter "*.sh" | ForEach-Object {
(Get-Content $_.FullName -Raw) -replace "`r`n", "`n" |
Set-Content $_.FullName -NoNewline
}
Final Newline Handling
Many tools expect files to end with a newline. The converter handles this:
Options:
● Keep existing final newline behavior
○ Ensure file ends with newline (POSIX standard)
○ Remove trailing newline
POSIX standard: text files should end with a newline.
Git shows a warning "No newline at end of file" when this is missing.
Some compilers and tools behave differently with files missing the final newline.
BOM (Byte Order Mark) Handling
Some Windows tools add a BOM at the start of UTF-8 files, which causes issues on Linux:
File with UTF-8 BOM:
Bytes: EF BB BF 48 65 6C 6C 6F ...
Visible as: Hello World
Options:
● Remove BOM (recommended for Linux/Mac compatibility)
○ Keep BOM
○ Add BOM (for Windows compatibility)
Remove the BOM when files will be used on Linux systems or processed by tools that don't handle BOM correctly. The BOM is invisible in most editors but causes issues in scripts and parsers.
Editor Configuration to Prevent Issues
Configure your editor to use consistent line endings:
// VS Code settings.json
{
"files.eol": "\n", // Use LF for all new files
"files.insertFinalNewline": true,
"files.trimTrailingWhitespace": true
}
# .editorconfig — works across editors
root = true
[*]
end_of_line = lf
insert_final_newline = true
charset = utf-8
[*.bat]
end_of_line = crlf
[*.ps1]
end_of_line = crlf
Line Ending Reference
Quick reference for line ending formats:
- LF (
\n, 0x0A) — Unix, Linux, macOS (10+), Git default - CRLF (
\r\n, 0x0D 0x0A) — Windows, DOS, HTTP headers, email - CR (
\r, 0x0D) — Classic Mac OS (pre-OS X), some legacy systems
When in doubt, use LF. It is the universal standard for source code, shell scripts, and configuration files. Use CRLF only for Windows-specific files like batch scripts and PowerShell scripts.