↵ 줄바꿈 · 인코딩 변환

텍스트의 개행 코드 (LF / CRLF / CR), BOM, 문자 인코딩 (UTF-8 / Shift-JIS / EUC-JP), 들여쓰기 (탭 ⇔ 스페이스), 행 끝 공백, 중복 빈 줄을 모두 한 번에 변환합니다.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

🔒 개인정보 보호

・모든 변환은 브라우저 내에서 처리
・텍스트와 파일은 서버로 전송되지 않습니다
・저장 로그 · 기록 · DB 없음

📂 파일 드래그 · 클릭 선택 (선택)

입력 텍스트

줄 바꿈 코드

BOM

출력 인코딩

들여쓰기

공백 너비

행말 공백 제거 중복 빈 줄 1줄로

📖 자주 걸리는 지점

개행 코드(LF / CRLF / CR) · BOM · 문자 코드 · 들여쓰기 · 행말 공백을 한꺼번에 변환합니다. 처리는 브라우저 안에서 끝납니다. 개행 코드는 눈에 보이지 않으므로 문제는 변환하고 싶을 때가 아니라 섞여 있다는 것을 알아채지 못할 때 일어납니다 — Git 의 차분이 전 행이 된다, 셸 스크립트가 동작하지 않는다, PHP 가 알 수 없는 에러를 낸다 같은 증상의 뒤에는 대개 이것이 있습니다.

사례	무슨 일이 일어나는가	어떻게 하면 되는가
Git 의 차분이 파일 전체가 된다	한 줄밖에 고치지 않았는데 전 행이 변경으로 표시된다면 거의 확실히 개행 코드가 바뀌어 있습니다. 원인은 각자의 `core.autocrlf` 설정이 다른 것으로 — Windows 의 기본값(`true`)은 체크아웃 시에 CRLF 로, 커밋 시에 LF 로 변환하지만 macOS 와 Linux 의 기본값(`false`)은 아무것도 하지 않습니다. 혼재한 팀에서는 저장할 때마다 개행이 반전되어 리뷰가 불가능해집니다. 에디터의 설정이 연 파일의 개행을 유지인지 항상 LF 인지에 따라서도 결과가 달라집니다.	*`.gitattributes` 를 저장소에 두고 ` text=auto eol=lf` 라고 쓰세요 — 이는 개인 설정과 달리 저장소에 들어가므로 전원에게 같은 규칙이 적용됩니다. `core.autocrlf` 는 각자의 환경 변수이므로 팀에서 맞추는 수단으로는 믿을 수 없습니다*. Windows 용 배치 파일 등 CRLF 가 필요한 것은 `.bat text eol=crlf` 라고 개별로 지정합니다. 이미 혼재해 버린 경우에는 `git add --renormalize .` 를 한 번만 실행해 전 파일을 규칙대로 정규화하세요 — 이는 거대한 한 커밋이 되므로 다른 변경과 섞지 말고 단독으로 커밋해 리뷰를 건너뛰는 것이 실무적입니다.
BOM 탓에 동작하지 않는다	BOM(Byte Order Mark)은 파일의 맨 앞에 붙는 3 바이트의 보이지 않는 표시입니다. UTF-8 에서는 본래 불필요하지만 Windows 의 메모장 등이 기본으로 붙입니다. 실해의 대표 예는 — PHP 파일의 맨 앞에 BOM 이 있으면 `<?php` 보다 앞에 그 3 바이트가 출력되어 `headers already sent` 에러가 됩니다. 셸 스크립트에서는 `#!/bin/bash` 앞에 BOM 이 들어가 shebang 이 인식되지 않아 실행할 수 없습니다. JSON 파서의 상당수는 BOM 으로 구문 오류가 됩니다. 어느 것이나 보이지 않는 3 바이트가 원인이므로 파일을 몇 번 다시 봐도 알 수 없습니다.	UTF-8 에서는 BOM 을 붙이지 마세요. UTF-8 은 바이트 순서의 모호함이 없는 부호화이므로 BOM 의 본래 역할(바이트 순서의 지시)이 애초에 불필요합니다. 유일한 예외는 Windows 의 Excel 로 여는 CSV — BOM 이 없으면 Excel 이 일본어 환경에서 Shift-JIS 로 읽어 글자가 깨집니다. 이 한 가지만은 BOM 을 붙일 이유가 있습니다. 판별은 간단해서 `file` 명령이 `UTF-8 Unicode (with BOM) text` 라고 표시하는지, `head -c 3 file \| xxd` 가 `efbb bf` 를 반환하는지입니다. 왜인지 동작하지 않는 파일을 만나면 내용을 의심하기 전에 맨 앞 3 바이트를 보세요 — 몇 초면 나눌 수 있습니다.
탭과 스페이스가 섞여 구문 오류가 된다	언어에 따라 들여쓰기의 취급이 완전히 다릅니다. Python 3 은 탭과 스페이스의 혼재를 명확히 거부하고 `TabError` 를 냅니다 — 화면상은 같은 너비로 보이므로 복사 붙여넣기로 섞였을 때가 가장 찾기 어렵습니다. YAML 은 탭을 일절 허용하지 않습니다 — 들여쓰기로 쓰면 반드시 파스 에러가 됩니다. 반대로 Makefile 은 레시피 행이 탭으로 시작해야 하며 스페이스로 하면 `missing separator` 가 됩니다. 겉보기가 같고 의미가 다르다는 성질은 어느 방향으로도 사고를 일으킵니다.	`.editorconfig` 를 저장소에 두고 확장자마다 정하세요 — 대부분의 에디터가 추가 설정 없이 따르므로 팀 전원에게 같은 규칙이 적용됩니다. 실무적인 기본값은 Makefile 과 Go 는 탭, 그 외는 스페이스이며 Go 는 언어의 공식 포매터가 탭을 쓰므로 논의의 여지가 없습니다. `[Makefile]` 과 `[.go]` 에 `indent_style = tab`, 그 외에 `indent_style = space` 라고 쓰면 충분합니다. 이미 혼재한 기존 파일은 이 도구로 일괄 변환하세요* — 다만 변환은 한 커밋으로 모으고 기능의 변경과 섞지 마세요. 에디터에서 공백 문자 표시를 켜 두면 애초에 섞이지 않게 됩니다.

행말 공백의 일괄 삭제에는 한 가지만 예외가 있습니다 — Markdown 에서는 행말의 반각 스페이스 2 개가 개행을 의미합니다. 일괄 삭제하면 의도한 개행이 사라져 단락이 이어집니다. Markdown 을 다룬다면 이 처리는 피하거나 삭제 후에 표시를 확인하세요(애초에 행말 스페이스에 기대지 않고 빈 줄로 단락을 나누는 편이 안전합니다). 한 가지 더, 문자 코드의 변환은 비가역입니다 — UTF-8 에서 Shift-JIS 로 변환하면 Shift-JIS 에 존재하지 않는 문자는 사라집니다. 이모지, 원문자의 일부, 로마 숫자, 그리고 물결표처럼 겉보기는 같지만 다른 코드 포인트인 문자가 해당하며 대체 문자가 되거나 그대로 사라집니다. 변환하기 전에 반드시 원래 파일을 다른 이름으로 남기세요 — 변환 후의 파일에서 원래대로 되돌릴 수는 없습니다. 이 페이지의 처리는 모두 브라우저 안에서 끝나므로 입력한 텍스트가 전송되는 일은 없습니다.

📖 사용법

1

텍스트 · 파일 입력

붙여넣기 또는 파일 드롭.
2

옵션 선택

줄바꿈, BOM, 인코딩, 들여쓰기를 선택.
3

변환 후 복사 · 저장

결과를 복사 또는 다운로드.

❓ 자주 묻는 질문

Shift-JIS 출력 실패 원인은?

브라우저는 UTF-8만 네이티브 지원. 매핑 외 문자는 ?로 대체.

BOM 란? 추가해야 합니까?

BOM은 UTF-8 식별 마커. Excel CSV에는 필요, Web/Linux는 보통 생략.

파일이 업로드됩니까?

아니요. 브라우저 내에서만 처리.

🔗 관련 도구

🐛 이 도구에서 문제가 발생했나요?

무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.