Texte
CRLF ↔ LF Converter
Convertir les fins de ligne entre Windows (CRLF), Unix/macOS (LF) et Mac classique (CR), avec détection des fins mixtes.
Le navigateur normalise lui-même en LF le texte collé dans le champ, donc les CRLF/CR d'origine ne peuvent pas être détectés ici — pour analyser ou convertir un fichier avec de vrais CRLF/CR, utilisez l'import de fichier ci-dessus.
Windows, Unix/macOS, and the old classic Mac historically use different characters to mark the end of a line — CRLF, LF, and CR respectively. Mixing these styles in one file often causes odd artifacts in diffs or editors. This tool converts line endings to one style and detects mixed ones.
How to use it
- Paste text and the tool automatically detects the current line-ending style, including a mixed one.
- Pick a target format (CRLF, LF, or CR) and the conversion happens instantly.
- If several styles are found in the same file, that's flagged with a separate warning.
Common uses
- Fixing a file where git diff shows every line as changed because of differing line endings, even though the content itself didn't actually change.
- Converting a text file to the format a specific system or script expects (a Unix script, for instance, expects LF).
- Debugging why a file opened in a Windows editor shows the entire text on one line (a sign of plain LF with no CR).
Things to keep in mind
Git can automate this conversion itself through core.autocrlf or .gitattributes — often more convenient than converting files in a repository by hand.
Mixed line endings in one file aren't always visible at a glance, but they can break parsers or scripts that expect one specific style.
Article sur cet outil: CRLF contre LF : pourquoi les caractères de fin de ligne comptent encore
Questions fréquentes
Pourquoi les fins de ligne diffèrent-elles selon le système ?
Windows utilise CRLF (\r\n), Unix et macOS utilisent LF (\n) seul, et l'ancien Mac classique utilisait CR (\r) seul ; ces conventions historiques différentes provoquent des incohérences quand un fichier passe d'un système à l'autre.
Pourquoi dois-je importer un fichier au lieu de coller le texte ?
Le navigateur normalise automatiquement en LF tout texte collé dans un champ de saisie, donc les vrais CRLF ou CR d'origine deviennent indétectables une fois collés ; seul l'import direct du fichier préserve ses fins de ligne réelles pour analyse ou conversion.
Quand ce genre de problème a-t-il vraiment de l'importance ?
Cela compte surtout avec git (diffs bruyants dus aux fins de ligne), les scripts shell qui échouent avec des CRLF résiduels, et les fichiers échangés entre systèmes Windows et Unix/macOS ; le fichier importé n'est traité que localement dans le navigateur, jamais envoyé à un serveur.
Que faire si un fichier mélange CRLF et LF ?
Un fichier édité dans plusieurs éditeurs ou sur différents systèmes d'exploitation peut contenir les deux styles à la fois. La conversion doit être appliquée à tout le fichier, pas seulement aux lignes visiblement « suspectes » — sinon une partie des fins de ligne problématiques passera inaperçue.
Peut-on automatiser la conversion via git ?
Oui, le paramètre core.autocrlf de git convertit automatiquement les fins de ligne lors du checkout et du commit, et .gitattributes permet de définir explicitement le style de fin de ligne pour certains types de fichiers dans le dépôt.