Git has detected a UTF-8 Byte Order Mark at the beginning of a file. While valid UTF-8, BOMs can cause cross-platform compatibility issues with diff, merge, and patch operations.
A Byte Order Mark (BOM) is a special Unicode character (0xEF 0xBB 0xBF) that some text editors add to the beginning of UTF-8 files. While technically valid UTF-8, the BOM is unnecessary and even problematic for UTF-8 encoding because UTF-8 has a fixed byte order. Git detects these BOMs and may warn you because they can cause various issues in version control workflows. Git treats file content as byte sequences and does not strip or ignore the BOM. This means the BOM becomes part of the tracked content. When files with BOMs are used in cross-platform projects (Windows, Linux, macOS), they can cause problems with git diff, git apply, scripts with shebangs, and other tools that don't expect the invisible BOM bytes. According to RFC 3629, the UTF-8 BOM is "useless" and not recommended. Git's official documentation recommends storing all text files as UTF-8 without BOM with LF line endings for best cross-platform compatibility.
Use this command to identify all files with UTF-8 BOM in your repository:
You can also check a specific file:
VS Code:
1. Click "UTF-8 with BOM" in the bottom-right status bar
2. Select "Save with Encoding"
3. Choose "UTF-8" (without BOM)
Visual Studio:
1. Go to File → Save As
2. Click the dropdown arrow on the Save button
3. Select "Save with Encoding"
4. Choose "Unicode (UTF-8 without signature)"
Visual Studio Code (command):
For Unix/Linux systems, use sed or specialized tools:
For batch processing multiple files:
If you must work with files that require BOM in working directory (e.g., legacy Windows tools), use .gitattributes to handle encoding conversion:
Note: The UTF-8-BOM encoding in .gitattributes only works on Windows. This will break repository compatibility on Linux/macOS systems.
After removing BOMs from your files, commit the changes:
Git will detect the BOM removal as a content change and commit it.
Configure your development tools to never add BOMs:
VS Code (settings.json):
EditorConfig (.editorconfig):
Git hooks: Create a pre-commit hook to automatically strip BOMs:
Why Windows adds BOMs: Windows Notepad and some Microsoft tools add BOMs on purpose because older versions required the BOM to correctly detect UTF-8 encoding. Modern editors don't need this, but the practice persists for backward compatibility.
BOM and shebangs: If a shell script starts with a shebang () and has a BOM, the BOM becomes part of the interpreter path, causing "interpreter not found" errors on Unix systems. The kernel sees instead of .
Git's handling philosophy: Git intentionally does not strip BOMs or treat them as whitespace because Git's core principle is to preserve content exactly as authored. This makes BOM handling a repository policy decision rather than a tool decision.
Cross-platform encoding strategy: For projects that must support both Windows-only tools (requiring BOM) and Unix systems (requiring no BOM), use .gitattributes with working-tree-encoding to store files as UTF-8 without BOM in the repository, converting to BOM on Windows checkouts. However, this only works if all contributors use Windows, as Linux/macOS Git doesn't support the UTF-8-BOM encoding.
Alternative to BOMs: If you need to ensure UTF-8 encoding is detected, rely on proper Content-Type headers in web contexts, file extensions, or explicit encoding declarations in file formats that support them (like XML or HTML meta tags).
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git