↵ Line Endings & Encoding Converter
Convert line endings (LF / CRLF / CR), BOM, character encoding (UTF-8 / Shift-JIS / EUC-JP), indentation (tabs ↔ spaces), trailing whitespace, and duplicate blank lines all at once.
🔒 About Privacy
- ・All conversion runs in your browser via TextEncoder / TextDecoder
- ・Text and file content are never sent to any server
- ・No storage logs, no history, no database
📂 Drag & drop a file or click to select (optional)
Result
📖 Where people get stuck
Converts line endings (LF, CRLF, CR), the BOM, the character encoding, indentation and trailing whitespace in one pass. Everything runs in the browser. Line endings are invisible, so the trouble arrives not when you want to convert them but when you have not noticed they are mixed — a Git diff covering every line, a shell script that will not run, PHP raising an inexplicable error: this is usually what is behind them.
| Case | What happens | What to do |
|---|---|---|
| A Git diff covers the entire file | If you changed one line and every line shows as modified, the line endings almost certainly changed. The cause is that each person has a different core.autocrlf: the Windows default (true) converts to CRLF on checkout and back to LF on commit, while the macOS and Linux default (false) does nothing. In a mixed team the endings flip on every save and review becomes impossible. Whether your editor preserves the endings of the file it opened or always writes LF changes the outcome too. |
Put a .gitattributes in the repository saying * text=auto eol=lf — unlike a personal setting, it lives in the repository, so the same rule applies to everyone. core.autocrlf is per-environment and cannot be relied on to align a team. Files that genuinely need CRLF, such as Windows batch files, get their own line: *.bat text eol=crlf. If the mixture is already in place, run git add --renormalize . once to bring every file into line with the rule — it produces one enormous commit, so keep it separate from other changes and merge it without a line-by-line review. |
| A BOM stops things working | A BOM (byte order mark) is three invisible bytes at the start of a file. In UTF-8 it is unnecessary, but Windows Notepad and others add it by default. The classic damage: a BOM before <?php means those three bytes are output first, producing a headers already sent error; a BOM before #!/bin/bash means the shebang is not recognised and the script will not run; most JSON parsers raise a syntax error on it. In every case the cause is three bytes you cannot see, so no amount of re-reading the file reveals it. |
Do not use a BOM with UTF-8. UTF-8 has no byte-order ambiguity, so the BOM original purpose — indicating byte order — does not apply. The one exception is a CSV to be opened in Windows Excel: without a BOM, Excel in a Japanese environment reads it as Shift-JIS and garbles it. That single case is the reason to add one. Detection is quick: either file reports UTF-8 Unicode (with BOM) text, or head -c 3 file | xxd returns efbb bf. When you meet a file that inexplicably will not work, look at its first three bytes before you question its contents — it takes seconds to rule in or out. |
| Mixed tabs and spaces produce a syntax error | Languages treat indentation completely differently. Python 3 explicitly refuses a mixture of tabs and spaces and raises TabError — they look identical on screen, so a mixture introduced by copy and paste is the hardest case to spot. YAML permits no tabs at all and always fails to parse if you indent with one. Conversely, a Makefile recipe line must begin with a tab, and using spaces gives missing separator. Looking identical while meaning something different causes accidents in every direction. |
Put an .editorconfig in the repository and decide per extension — most editors honour it with no extra setup, so the same rule reaches everyone. The practical default is tabs for Makefiles and Go, spaces for everything else; Go leaves no room for debate because the official formatter uses tabs. indent_style = tab under [Makefile] and [*.go], and indent_style = space elsewhere, is enough. Convert existing mixed files in bulk with this tool, but keep the conversion in its own commit, separate from any functional change. Turning on show whitespace in your editor stops the mixture arising in the first place. |
Stripping trailing whitespace has exactly one exception: in Markdown, two trailing spaces mean a line break. Strip them in bulk and the breaks you intended disappear and paragraphs run together. If you work with Markdown, either skip that option or check the rendering afterwards — though separating paragraphs with blank lines rather than relying on trailing spaces is safer to begin with. Second: an encoding conversion is not reversible. Converting UTF-8 to Shift-JIS loses every character that Shift-JIS does not have: emoji, some enclosed numerals, Roman numerals, and characters like the wave dash that look identical but occupy a different code point. They become a replacement character or vanish. Always keep the original under a different name before converting — the converted file cannot be turned back. Everything on this page runs in your browser, so nothing you paste is transmitted.
📖 How to Use
-
1
Provide text or filePaste into the textarea or drop a file onto the dropzone.
-
2
Choose optionsPick line endings, BOM, encoding, indentation, trailing whitespace, and blank line collapse — all in one pass.
-
3
Convert, then copy or saveCopy the result to your clipboard or download it as a file.
❓ Frequently Asked Questions
Why does Shift-JIS output sometimes fail?
What is BOM? Should I add it?
Is the file uploaded?
🔗 Related Tools
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.